Zugg Software :: View topic

Novice Joined: 02 Nov 2010 Posts: 45

Hi,

I have a problem with GMCP, when the %gmcp variable is not assigned correctly by CMUD. I have no idea what could be the reason (if its mud-related, or cmud bug) - could someone help?

For example, when I move from room with exit E into room with no exits (visible or other), the exit value does not change:

For debug purposes, I made GMCP trigger:

SubAdmin Joined: 18 Nov 2001 Posts: 5182

This would appear to be a CMud bug. I would suggest making a Telnet trigger to capture the data yourself and using your own variable instead of the %gmcp predefined variable.

Sorcerer Joined: 15 Apr 2011 Posts: 809

This is actually not a bug. If a particular field is not included in a GCMP message, CMUD will retain the previous value assigned to that field. This is to allow MUDs to selectively update fields. If only a single field has changed in a message that normally contains 10 fields, the MUD can send only that single field, rather than having to send everything that did not change along with it. The recommendation for MUD implementations is to send blank data (i.e. exits: []) in situations where clearing the previous data is required.

Novice Joined: 02 Nov 2010 Posts: 45

Daern: that does not explain, why the same happens when I receive objects.nums data - I'll paste an example as soon as I'm back home from work, so you can see, but basicly:

Objects have two subpackages/messages - nums (that is an JSON array of ids) and data (that is JSON mapping of some data).

When I receive a larger package of object.nums f.e. [1000,2000] and then when I receive [1000], the %gmcp does not update accordingly and the %gmcp.object.nums is still 1000|2000, instead of just 1000. The same problem is with objects.data variable - it expands, but does not shrink. I'll post some raw data from MUD as soon as possible, but if you have some ideas why that could happen - please let me know so I can try to search for it.

It seems, that JSON message from MUD is proper - that's why I don't have an idea what can go wrong there.

Novice Joined: 02 Nov 2010 Posts: 45

GMCP trigger:

Sorcerer Joined: 15 Apr 2011 Posts: 809

The objects.data is exactly the same case that I described with exits above. The MUD did not send an updated value for the "2" field, so CMUD retained the previous value. If it did not do this, the data would be lost. I've never run into the objects.nums case as my MUD doesn't have any GMCP messages that are a single array... this one seems strange, but I assume it's a similar situation. As Vigilante suggested, your best bet might be to use telnet triggers on option 201, instead of GMCP triggers. You could use a pattern like this: ^([\w\.]+) (.+)$ to capture the module and data. The %json function can be used to parse the data into CMUD's variable format.

Edit: actually, looking at your examples more closely, it looks like %0 (the raw string value received with the message) is being set correctly. It would probably be simpler to use that, instead of a telnet trigger. You could set your own variables to the latest data using %0 in a GMCP trigger, then reference those variables in other triggers/aliases/etc instead of using %gmcp.

Novice Joined: 02 Nov 2010 Posts: 45

Daern: that's what I was thinking about, however I do have the possibility to contact the mud creators and ask them to fix something with the mud output, if the error lies there - I do not see such thing though, so I don't know what to fix.

If you cant see the error either, I guess I'll just do everything based on %0 and %json function in gmcp trigger, as you mentioned.

Sorcerer Joined: 15 Apr 2011 Posts: 809

I don't believe there is an error, just a misunderstanding of how GMCP works in CMUD. I think these two threads explain it pretty well:
http://forums.zuggsoft.com/forums/viewtopic.php?t=35695
http://forums.zuggsoft.com/forums/viewtopic.php?t=35773

As for changing the mud implementation, I would recommend sending an empty exits array in rooms with no exits (room.info {"exits":[]}) at the very least. I'll have to think more on the objects one.