Zugg Software :: View topic

Posted: Fri Sep 10, 2010 4:40 pm

OK, I've discovered something about the GMCP implementation in CMUD that is probably responsible for some of the mapping problems people are having.

Right now, GMCP is processed by the low-level socket-read routine in CMUD that is responsible for parsing all Telnet Option stuff. This routine puts full lines of text into a buffer that is later displayed to the screen line by line.

This means that the GMCP messages are being processed and *executed* before the lines of text have been displayed. If the MUD sends a bunch of text and then the GMCP in the same network packet, the GMCP data gets executed *before* the text is displayed.

The normal mapper routines act upon the text when it is actually displayed to the screen (since the mapper is trigger based, and triggers always act upon text on the screen). So this can cause GMCP data to be processed and then the text from the *previous* room is displayed in the mapper, potentially causing the mapper to get confused.

This same situation happened with ATCP in the past (and any other telnet option protocol). This was never a problem when parsing normal telnet WILL/DO option requests since they actually need immediate handling. But for data that needs to be in sync with the normal MUD text, this is a bigger issue. I need to rewrite these routines to process the GMCP/ATCP data in the normal line queue instead of in the initial socket handling routine.

I'll try to get a new version of this out for testing late today so you can play with it over the weekend.

Posted: Fri Sep 10, 2010 5:03 pm

Bah, no, this isn't right either.

The GMCP map data *does* need to be processed before the normal mapper receives the normal room text. Otherwise the normal mapper will still try to parse the text and create a room and won't have the GMCP data to guide it or override it.

So processing GMCP immediately *is* the right thing to do.

Sorry for the confusion. Now I'm getting myself confused.