|This problem will probably be devilishly hard to figure out, so I apologize in advance.|
I made a plugin to handle the GMCP subnegotiations IRE is putting out these days, and decided that instead of parsing OnPluginPacketReceived, I'd just simplify things and use the new OnPluginTelnetSubnegotiation. Works great and saved me a lot of trouble, except for one thing.
From what I can see, this is what is going on. Anytime you generate a Note, command echo, or even error message from within OnPluginTelnetSubnegotiation, the very next line output by the MUD, no matter what it is, will fail to match any trigger.
Now at this point it probably looks like I'm completely misinterpreting things. No doubt it's that out of band info behind the plugin call that's somehow messing things up, right? As far as I can see, that's not the case.
Here is the experiment I did. First, I created a simple trigger that just does a Note saying it matched. Now GMCP has a nice, simple thing where you can send it "\255\250\201 Core.Ping \255\240" and it'll send back the same (that's IAC SB GMCP and IAC SE wrapping it; just a standard subnegotiation). The nice thing is, OnPluginTelnetSubnegotiation doesn't activate until I receive an IAC GA, and the pinging alone won't generate that, so I can do things in between for my tests.
In the first case, I just set up OnPluginTelnetSubnegotiation to do a Note, sent the ping subnegotiation, and then generated the text for my simple trigger with the Test Trigger feature. As expected, it failed to match, and the colour from the Note bled onto it (another symptom I forgot to mention earlier). The same happened when replacing the Note with a command, as the command echo has the same effect.
In the second case, I let OnPluginTelnetSubnegotiation be called, but make no visible output to the world. I sent the ping, manually generated the very same Note I had OnPluginTelnetSubnegotiation do last time, and then generated the trigger text with test trigger. The trigger matched. Same result when I manually generate a command echo in between.
In both cases the out of band info was present, but only when the Note is generated by OnPluginTelnetSubnegotiation does the problem occur. This leads me to believe it's OnPluginTelnetSubnegotation itself that's bugged. Especially interesting (and weird) is that the problem Note can be anywhere, so long as it originates with OnPluginTelnetSubnegotiation. For example, I can make OnPluginTelnetSubnegotiation Execute an alias in even my world that then does a Note, or even have that alias call a script function that does a Note, and it'll still happen. But if I use the very same alias to create the same Note in the same place manually, it doesn't happen!
Anyway, thanks for reading all that. I have to say though, I'm surprised nobody's brought this up already as it's a pretty big issue.