hmm... I could be way off but... had problems trigging off of mxp events in mush... (well... syncing those events with other output)... and I found that the event was immediate (happens when the info comes in) and would fire often well before it was even displayed... I wonder if the events are triggering when they should but happen so fast that what's in between has not been rendered yet.... (are you capturing the contents with the event or some other means... not sure any other means will work)
Like I said I could be way off... if I am... ignore me
This is not a Mudlet bug, but IRE uses GMCP in a non intended way. GMCP is all about out of band data transmission. IRE confuse GMCP with the MXP redirect command i. e. they send an *out* of band GMCP event that carries the meaning that all *in* band data should be redirected to the output window named in the event until an end redirection event is sent at some future point in time. This kind of behavior is not described by GMCP and very much contrary to its intentions. It is OK for MXP, because MXP is about in band data transmission, but not OK for GMCP because GMCP has no business with in band data. The proper handling of communcation events is to send the chat data properly as part of the GMCP data package. This is how Aardwolf is handling it and IRE should do the same.
What are we supposed to do if we get a redirect event to a non existent window? Ignore the data? Open a popup window? Do we really want to allow the MUD control over our output? As far as I'm concerned, I'm strictly against giving the server any control over the user interface and I assume - without knowing much about Mush - that Mush sees this similarly.
As a system builder, I -want- the game sending me as much data as possible. The more data it sends me, the more I have to work with. I even built my chat window system with their GMCP information in mind, and gave all of my tabs and windows data fields for what the game sends me (i go so far as to load my tabs using gmcp.Comm.Channel.list). If the redirect worked the way it's supposed to I wouldn't have to mess with triggers to parse chat commands into their respective windows, I could just listen for the gmcp events.
More information is much better, and makes my job easier as a system builder freeing me up for more complex projects.
Point is that IRE is using it the wrong way. GMCP is supposed to be self-contained, proper usage of it would be the GMCP channel message be enclosed in GMCP data - not send start and end tags that then rely on non-GMCP data.
Vadi wrote:Point is that IRE is using it the wrong way. GMCP is supposed to be self-contained, proper usage of it would be the GMCP channel message be enclosed in GMCP data - not send start and end tags that then rely on non-GMCP data.
Yeah, I realize this, and IRE needs to fix it. I was really just arguing the point that the mud telling my UI what to do is not a bad thing.