IAC EOR/GA trigger option

I think it would be quite useful to add an IAC EOR/GA checkbox option to triggers. Most prompts, I believe, end with this sequence, and such an option would limit the trigger strictly to only matching lines with IAC EOR/GA at the end. Some MUDS also have extremely customizable prompts, making it very hard to reliably match them across different users (say, in a distributed plugin).

In regards to the "Convert IAC EOR/GA to newline" option in Configure -> Output that might cause problems, why not count IAC EOR/GA as a type of newline on its own? I think that would both solve the issue and render the conversion option unneeded?

What does this achieve exactly? Are you matching the prompt or just want to know when it arrived?

Both. It's very easy and possible to encounter a "false" prompt in-game, for example in the middle of a clan newspost containing a combat log, or within other help files, etc etc. On the one hand, you can use this to capture the IAC EOR/GA it at trigger-evaluation time (to use as the "closing" trigger of a three-part sandwich set), and on the other you can use it to guarantee that what you've got is definitely your prompt.

I had been planning to make a request for something like an "OnPluginGAReceived" callback, but being able to match a GA/EOR in a trigger would be an even more powerful solution.

Actually, Nick added one in v4.50 (not released yet), under the name of OnPlugin_IAC_GA. The issue is that it's not called at trigger time, but packet parse time, as far as I know. This means that the callback is triggered before you get the chance to match any lines in that packet with triggers.

You could simply use the "packet received" callback to modify IAC EOR to something like <muahahaha>\n.

That way you are guaranteed your trigger should end in some special string (you could make it non-printable characters to avoid spoofing).

I think that's a disgusting hack, to be honest - no offense to you specifically, Nick. It causes problems in prompt triggers that would normally behave, throwing in something to the mix. It's also not portable, because multiple plugins might decide to do this but have different "unique" addendums, and furthermore only one plugin would actually get the IAC EOR/GA. It's a resource, just like ATCP or the Aardwolf tags you spoke of before.

EDIT: What I mean is, IAC GA is in itself a guaranteed special string, and I see no remotely good reason to meddle with it. There's no facility yet to match on it - it's stripped from output, obviously - so all this is asking is that there be one.

I don't understand this "match on it" talk. Triggers match at a specific time (when a newline arrives) and against specific text.

Anyway, your problem is easily solved. Add this:



Now in your trigger, which thinks it may or may not have matched on a valid prompt:



The state machine works in such a way that triggers are processed very shortly after the IAC GA is processed (because it is replaced by a newline, and the newline starts trigger processing).

I tested it, it matches reliably.

Indeed, and this is no different. An IAC EOR/GA option woukd simply toggle it so it fires when a line ends IAC EOR/GA rather than a newline.

Look, prompt triggers are almost universal. It seems wrong to require scripting for such a simple thing. And then you have triggers in the world file (outside plugins) too, and it's very possible - probable even, from experience - that there's a prompt trigger or two in there. Making plugin callbacks work in the world is more trouble than it's worth, by far.

EDIT: clarification for "world triggers" -> "triggers in the world file"

The OnPluginXXX callback suffices for my needs, since I only need to know when an IAC GA has arrived, but I can certainly see the utility of being able to match on it in a trigger. For example, an option to have the '$' character match on IAC GA instead of an EOL and then "^.*$" would always match on the prompt, no matter how the user has it configured.

Well, to change $ itself to match IAC GA would require changing things deep within the PCRE library itself. A simpler implementation of my suggestion would be to fire triggers on an IAC GA sequence as well as the newline as it is now, simply marking a flag that an IAC EOR/GA-enabled trigger would check before matching. In all other respects it would be business as usual.

EDIT: In fact, that's what Nick's example above does, except through scripting and using the line number as the flag. It also, strictly speaking, does match on non-IAC EOR/GA lines, but bails out early if the IAC EOR/GA line number doesn't match. It does the job, but it's not optimal, both for that reason and for less script-savvy users.

Well it hasn't been required for the last ten years.

However I'll save you the trouble of writing the plugin callback, and you can do this outside a plugin now:



The new GetInfo (289) call will return the last line number that happened to have an IAC/GA in it. Thus, the test above, in a trigger inside a plugin or not, will tell you if it is a "genuine" prompt.

We haven't had such an easy way to sense IAC EOR/GA until a couple weeks ago, but yes, it always required scripting to sense an IAC EOR/GA in conjunction with a trigger.



Fair enough, although I can't help but think we're more than halfway to a bona fide trigger option now. =/ You've got the sense-an-IAC-EOR/GA code in, now if the above check was in the client itself that'd be it.

I guess this'll suffice, but it still seems like more of a bother than is really necessary. Do we just not want to change the GUI resources DLL? I'd be more than happy to add this in myself, I just haven't had the time or willpower to dig into the source lately.