Zugg Software :: View topic - [3.31 pro] GMCP being sent after normal data packet/Mapper panic

Novice Joined: 23 Jun 2005 Posts: 32

My mapper is freaking out and I figured out why. I'm playing Midkemia Online and Achaea. Same problem exists in both places. (IRE codebase.)

GMCP data is being sent AFTER the normal data packet. CMUD seems to expect it BEFORE the packet, thus causing huge problems.

Take a look at the example below:

Posted: Wed Oct 20, 2010 5:17 pm

When CMUD receives a packet from the MUD, it does process any telnet options, including GMCP immediately before the rest of the data is parsed and sent to the screen. So yes, CMUD expects GMCP to be executed before the regular text is processed.

However, network packet boundaries can change depending upon your specific network configuration or ISP configuration. The MUD itself *is* sending the data as a single packet, and whey I play Achaea here, I see it all in a single packet and it works fine. Some something (probably out of your control) is splitting the packets from Achaea on your specific network connection.

Now, this normally shouldn't be a problem unless you are running some other triggers or something. So you'll need to explain more about exactly what problem this is causing for you. Because unfortunately there is probably little that you can do to fix the network packet issue, so we'll need to find a different work around for what you are trying to do.

Novice Joined: 23 Jun 2005 Posts: 32

I think I may have found the problem.

MCCP was enabled on the default session (I recreated my pkg file for testing purposes) when I had GMCP turned on. GMCP + MCCP seems to = screwed up packet ordering. (Why is MCCP enabled at all on IRE MUDs? It leads to ANGUISH!)

I know it wasn't enabled on my original package file though, which doesn't really explain the issue, but I'll test it more when I get home.

Posted: Wed Oct 20, 2010 11:07 pm

Hmm, that sounds more like a IRE game issue. I remember that IRE used to have problems if ATCP and MCCP were turned on at the same time. I wonder if that same problem happened with GMCP. I know that it was an issue with synchronizing the main data with the ATCP data, but they had fixed the ATCP problem.

MCCP is enabled all the time by default because when it works, it speeds up both the client and the server (less network data transfer).

I'll check with my contacts at IRE and see if this is something they can resolve, or if there is something different I need to do in CMUD. For now just turn off MCCP and see if that helps.

Novice Joined: 23 Jun 2005 Posts: 32

MCCP off = happy days at the fun time ranch. I think one of the default packages got corrupted too somehow. The secondary issue was that the directions "n" and "s" had no reversedir. If I looked at the Direction in English Directions they were specified, but if I did %reversedir(s) or (n) I got a null result. This is used in an autoconnect script I have for the rooms and, well, %roomlink(%roomvnum,null,target) fails pretty hard. I had no other directions and had never created any in this package, so it wasn't a case of my terrible code overriding the default.

I reinstalled CMUD totally and imported all my settings using Copy/Paste and everything seems to be cool.

Edit: Check out http://dl.dropbox.com/u/663476/IREStuff/debug.txt for what I mean. I did #debug with MCCP off, walked a couple rooms, echoed "MCCP ON" a few times, turned on MCCP, walked a few more rooms, turned it back off.

Posted: Tue Oct 26, 2010 8:09 pm

Could you repeat your test and turn on the Raw Input/Output message in the Script Debugger and then repeat your capture of the debug.txt file with MCCP off and MCCP on so I can see the real raw packet data? Your debug.txt post above doesn't have the "i" message (raw input/output) included. Thanks.

Novice Joined: 23 Jun 2005 Posts: 32

This appears to be a bug in the MUD. They fixed it and all is happy now. Close as resolved please.

Posted: Fri Oct 29, 2010 5:15 pm

Hmm, that's interesting. I've been in discussion with the IRE MUD coders about this and when they looked into it, they couldn't find a problem. Not sure how it got magically fixed.