Zugg Software :: View topic

Novice Joined: 18 Dec 2006 Posts: 47

All right, I know just enough about MUD scripting to be dangerous, but I've been pulling my hair out tonight trying to debug some inconsistant behavior in triggers. I finally have it nailed down to my trigger that is supposed to see the prompt, and then force other things to fire.

The pattern I have set up matches the prompt, but would only actually fire once every ten or twenty times (unless I held the enter key down for some reason, then it would fire almost every time while I held it down). Then I noticed the 'Trigger on Prompt' setting, I checked that, and now it fires every time on the prompt, but it fires twice.

So, it seems to be one extreme or the other... anyone know enough about this setting in CMUD to know why it's causing such drastic differences in trigger behaviors? I can provide more detail if anyone needs it, I just thought this might be a general enough question that it might become less clear if I gave too much detail.

I did notice on another trigger I was working on earlier, that it was unpredicatable until I checked the "Trigger on Prompt" setting, but since it started working at that point, I didn't give it much thought until now, so it doesn't seem that it's anything specific to the particular pattern I'm trying to match.

Novice Joined: 23 Jun 2005 Posts: 32

Basically, trigger on prompt triggers when it sees this:

Pattern<IAC><GA> (GA is Go Ahead)

Newline triggers on:

Pattern<CRLF>

Now, why it does it twice... every time you move a line to the buffer, CRLF is appended if it's not there. So what is happening is it matches like this:

Prompt<IAC><GA> -> runs your prompt code
Next line comes, adds a newline to the end of the prompt, all your "newline" triggers fire -> runs your prompt code again.

In ZMUD, you could turn off "Trigger on Trigger" and it would stop it. I'm not sure if this still works in CMUD. Basically, though, prompt handling has been buggy forEVER. Namely because with just prompt checked, if two prompts come quickly, it won't see the prompt as a prompt. Something like this will show you what I mean...

You send: whee;dance

Prompt- Matches
"Whee!", you squeal happily.
Prompt- Doesn't match!
You sweep across the floor, twirling like a true master.
Prompt- Matches

The middle one it's not seeing as a prompt for some reason, even though if you look at the packets in something else (I.E. xpertmud), it doesn't send a newline at the end. This problem has been in ZMUD and CMUD for as long as I've used them. (Since 2001.)

Novice Joined: 18 Dec 2006 Posts: 47

Interesting. I suppose having it fire twice is the lesser of two evils... disabling Trigger on Trigger did not prevent it from firing twice.

So, this sounds then like I'm going to need to set all my triggers to Trigger on Prompt to get them to fire reliably? This seems like it will create a lot of extra overhead in the system, as well as take a fair amount of time to change each of them one by one.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

Trigger on Prompt is only for prompt triggers (makes sense, right?). If you have other triggers for any regular message, stick with the default of Newline and no Prompt.

Urit is pointing out to you that if you have both the Newline and Prompt options enabled, you may see multiple firing problems like this. It may be a bug, but try disabling the Newline option and see if that improves your script.

Wizard Joined: 14 Aug 2004 Posts: 1269

Actually Urit didn't mention turning off the "Trigger on Newline" setting, but that is exactly what you should do if you want to match a prompt when the prompt comes in and not after you have entered your command. You should not be turning off "Trigger on trigger" unless you know what you are doing.

In case you are unclear a "prompt" is when the MUD has sent you a piece of text to prompt you for input. It will often end in a > or (especially in a command shell) a #.

Novice Joined: 23 Jun 2005 Posts: 32

But the problem is that sometimes it won't recognize a prompt.

As I said:

You send: whee;dance

Prompt- Matches
"Whee!", you squeal happily.
Prompt- Doesn't match!
You sweep across the floor, twirling like a true master.
Prompt- Matches

I don't know why it doesn't match the prompt in between, but it just doesn't. It treats it as a newline instead, when the MUD (Achaea in my case) clearly sends <IAC><GA> instead of <CRLF>.

This is mostly for Larkin, but others may understand it as well.

A serpent class sends: dstab larkin;conjure illusion You eat a piece of kelp.

You see:

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I use the nocr|prompt options on my prompt triggers and I have next to no trouble with situations like this. I will admit that sometimes my prompts are smashed together in strange ways, but I think that's often attributable to the MUD itself. In my personal experience, problems with prompt recognition are usually fixed by improving the code executed on every prompt. I added #PRIORITY tags to my critical bits of code and put in flags to only execute what needed to be executed, instead of the whole thing every time a prompt fires.

Novice Joined: 23 Jun 2005 Posts: 32

Results of my testing on a blank .mud in zmud:

Wizard Joined: 14 Aug 2004 Posts: 1269

I have had issues similar to what Urit is describing but it is sufficiently rare for me not to care. I don't have issues like that when I enter two command. But I have noticed that if I have a freeze due to packetloss / lag and then a page or more of mud output come in at once, some of the mud prompts won't get substituted by my triggers. However, this doesn't worry me since those prompts are already some way up the screen.

Urit, your problems may even be caused by unticking Trigger on trigger. Disabling this causes triggers not to fire when a script is being processed.

Novice Joined: 23 Jun 2005 Posts: 32

As I said, I didn't untick trigger on trigger. All I had was that EXACT trigger. It happens in every version of ZMUD and CMUD that I've used.

Again, the MUD is sending a prompt like "3260h, 3260m, 15200e cexdbk-<IAC><GA>", where IAC GA are the characters \255 and \249, I believe. Every prompt ends with IAC GA, however, Z/CMUD does not process it correctly. That is the only problem here.

While it may not worry you, Seb, some of my scripts do need to process every prompt, and I expect a client to do this correctly.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

Have you double-checked the code coming from the MUD, though? I would expect IRE to send the IAC GA EOR every prompt, but you never know if they "packetize" them and combine things with newlines instead of prompt codes (to ensure that the display comes out correct in all the spam).

Novice Joined: 23 Jun 2005 Posts: 32

Yes, I have. As I said, I used xpertmud (which does show the control codes because unless you play with it because it doesn't know how to handle them) and it ALWAYS shows <IAC><GA> at the end of the prompt, no exceptions. Same thing with mushclient. You need to replace \255\249 with a newline or it doesn't like your prompts, but it replaces EVERY LINE. It's nothing to do with IRE, only Z/CMUD.

Novice Joined: 18 Dec 2006 Posts: 47

Thanks for the help... using your suggestions (trigger on prompt, and uncheking newline) it does fire now when it should, and only once.

Also, I did confirm what Urit was seeing with his prompt trigger. Entering in 15 or so blinks in a row (in Achaea) did result in only the very first and very last prompt causing my trigger to fire.

Posted: Tue Dec 19, 2006 8:10 pm

Novice Joined: 23 Jun 2005 Posts: 32

It is very much not a bug in SAYP. Try this:

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Definitely looks like there is a bug with #PSUB. Currently CMud uses packet breaks to determine when to test for prompts. A packet that does not end with a newline indicator causes prompt checking. Perhaps in future versions Zugg can add better detection for the GoAhead as a prompt. I personally think it would be nice to be able to differentiate on my end what is going on. That is why I use 2 triggers each set to fire in the different circumstances and provide different responses. In one case more data is about to follow and in the other the mud awaits my commands; the current system actually makes a fair bit of sense, but the 'prompt' term is generally broader in usage then how CMud behaves.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

Did you try putting #PRIORITY around the #add Prompts 1 code? Just curious to know if it's a race condition issue. I know that zMUD isn't multi-threaded, but it's somehow trying to emulate it (and not wholly succeeding).

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

Not read the entire thread, but if we're talking about CMUD then #PRIORITY has been deprecated and does nothing in CMUD.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I was suggesting trying #PRIORITY in zMUD. It improved my performance quite a bit. I know it's deprecated in CMUD now (thankfully!), but there are still probably some issues with triggers like this firing reliably.

Novice Joined: 23 Jun 2005 Posts: 32

I've tried Priority, yes. It's fine for something else, but doesn't fix the issue of prompts.

Now, I downloaded a copy of Ethereal and ran it while testing. Here's what I found:

Each prompt ends properly in 0xFFEF (That's \255\239. Not sure where I got 249, sorry.) Ethereal sees that as "End of Record", which is correct. What ZMUD and CMUD are not doing correctly is processing in the MIDDLE of the packet. Achaea sends the entire thing in 1 packet, you see. It ends each prompt properly, but ZMUD/CMUD only parses the very last EoR as the prompt, causing this behavior.

If you want to analyze the packet itself, here is the binary file of the data portion.

Posted: Wed Jan 17, 2007 9:26 pm

I'll add the IAC GA issue for Prompt triggers to the bug list.

By the way, I assume you have turned on the EOR/GA option in your Emulation Preferences to enable GA support in zMUD/CMUD?

Novice Joined: 18 Dec 2006 Posts: 47

Just doubled-checked my settings, and the EOR/GA option is enabled.

Posted: Fri Jan 19, 2007 8:29 pm

Urit (or anyone else), can you do me a big favor and use the #DEBUG command in CMUD to capture this packet? In CMUD, type:

#DEBUG test.txt test.raw

Then do whatever on your MUD that causes the packet to get displayed. Then exit CMUD and send me the resulting test.txt and test.raw files as attachments in email to support@zuggsoft.com. These debug files will show me exactly what CMUD is receiving and exactly what CMUD is sending and would really help in tracking this down.

Posted: Mon Jun 04, 2007 4:42 pm

Zugg mentioned above that this was added to the bug list, I wasn't able to see it in any of the release fixes notes. Is this still an outstanding bug to be fixed or has this already been fixed in Cmud?

Posted: Mon Jun 04, 2007 5:24 pm

This is still an outstanding bug and is still on the bug list. Sorry.