Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD General Discussion Goto page 1, 2  Next
MNGrizzly
Novice


Joined: 18 Dec 2006
Posts: 47

PostPosted: Mon Dec 18, 2006 4:43 am   

Trigger on Prompt?
 
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.


Last edited by MNGrizzly on Mon Dec 18, 2006 5:01 pm; edited 1 time in total
Reply with quote
Urit
Novice


Joined: 23 Jun 2005
Posts: 32

PostPosted: Mon Dec 18, 2006 3:19 pm   
 
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.)
Reply with quote
MNGrizzly
Novice


Joined: 18 Dec 2006
Posts: 47

PostPosted: Mon Dec 18, 2006 5:37 pm   
 
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.
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Mon Dec 18, 2006 5:39 pm   
 
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.
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Tue Dec 19, 2006 1:43 am   
 
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 #.
Reply with quote
Urit
Novice


Joined: 23 Jun 2005
Posts: 32

PostPosted: Tue Dec 19, 2006 3:46 am   
 
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:

Code:
Soandso pricks you twice in rapid succession with her dirk.
Bla bla asthma message.
Bla bla clumsiness message.
Prompt-
You eat a piece of kelp.
Prompt-


About 50% of the time, Z/CMud will not see that second prompt between the clumsiness and kelp messages as a prompt, but rather as a newline-terminated line. Why? Only Zugg knows. This means a lot of the time you will NEED to check both newline and prompt to get it to parse every prompt. It only happens when the prompts are coming extremely quickly, as in a combat situation when people are chaining commands. It's nothing to do with the system in use - make a blank .mud and a trigger to #SAYP {something} after the prompt using a "prompt" only trigger, do an emote 10 times with a #10 blink or #loop 10 {blink}, see how many it doesn't say the thing after the prompt.


Last edited by Urit on Tue Dec 19, 2006 3:53 am; edited 2 times in total
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Tue Dec 19, 2006 3:51 am   
 
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.
Reply with quote
Urit
Novice


Joined: 23 Jun 2005
Posts: 32

PostPosted: Tue Dec 19, 2006 3:54 am   
 
Results of my testing on a blank .mud in zmud:

Code:
3260h, 2947m, 15200e ex Vote-Promptblink
blink
blink
blink
blink
blink
blink
blink
blink
blink

You blink.
3260h, 2947m, 15200e ex Vote-Prompt
You blink.
3260h, 2947m, 15200e ex Vote-
You blink.
3260h, 2947m, 15200e ex Vote-
You blink.
3260h, 2947m, 15200e ex Vote-
You blink.
3260h, 2947m, 15200e ex Vote-
You blink.
3260h, 2947m, 15200e ex Vote-
You blink.
3260h, 2947m, 15200e ex Vote-
You blink.
3260h, 2947m, 15200e ex Vote-
You blink.
3260h, 2947m, 15200e ex Vote-
You blink.
3260h, 2947m, 15200e ex Vote-Prompt


CMUD 1.24:

Code:

3260h, 2947m, 15200e ex Vote-Promptblink
blink
blink
blink
blink
blink
blink
blink
blink
blink

You blink.
3260h, 2947m, 15200e ex Vote-Prompt
You blink.
3260h, 2947m, 15200e ex Vote-
You blink.
3260h, 2947m, 15200e ex Vote-
You blink.
3260h, 2947m, 15200e ex Vote-
You blink.
3260h, 2947m, 15200e ex Vote-
You blink.
3260h, 2947m, 15200e ex Vote-
You blink.
3260h, 2947m, 15200e ex Vote-
You blink.
3260h, 2947m, 15200e ex Vote-
You blink.
3260h, 2947m, 15200e ex Vote-
You blink.
3260h, 2947m, 15200e ex Vote-Prompt


As you can see, it does not match prompts that come quickly.

All that was in the .mud/.pkg was #regex {^\d+h, \d+m} {#sayp {Prompt}} "" {nocr|prompt}

I can't see how you'd get away with saying "improve the prompt code" in this situation. Razz
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Tue Dec 19, 2006 10:11 am   
 
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.
Reply with quote
Urit
Novice


Joined: 23 Jun 2005
Posts: 32

PostPosted: Tue Dec 19, 2006 2:59 pm   
 
Rolling Eyes 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.
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Tue Dec 19, 2006 3:28 pm   
 
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).
Reply with quote
Urit
Novice


Joined: 23 Jun 2005
Posts: 32

PostPosted: Tue Dec 19, 2006 5:12 pm   
 
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.
Reply with quote
MNGrizzly
Novice


Joined: 18 Dec 2006
Posts: 47

PostPosted: Tue Dec 19, 2006 7:09 pm   
 
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.
Reply with quote
Caled
Sorcerer


Joined: 21 Oct 2000
Posts: 821
Location: Australia

PostPosted: Tue Dec 19, 2006 8:10 pm   
 
Urit wrote:
Results of my testing on a blank .mud in zmud:

As you can see, it does not match prompts that come quickly.

All that was in the .mud/.pkg was #regex {^\d+h, \d+m} {#sayp {Prompt}} "" {nocr|prompt}

I can't see how you'd get away with saying "improve the prompt code" in this situation. Razz

Thats a bug with #SAYP, so far as I can tell. I went through this ages ago when I was writing a timestamp for my prompt. I fixed it by using #subs instead of #sayp. Or maybe its just a weirdness with #subs where it is the workaround. Dunno.

The double firing problem is the trig on newline option, but if you don't check it, the trig wotn fire on every prompt. Only way to prevent the double fire is #subs.

Here is the thread where I first asked the question and eventually nutted out the answer:
http://forums.zuggsoft.com/phpbb/viewtopic.php?t=20890&start=0&postdays=0&postorder=asc&highlight=%23sayp
Reply with quote
Urit
Novice


Joined: 23 Jun 2005
Posts: 32

PostPosted: Tue Dec 19, 2006 8:35 pm   
 
It is very much not a bug in SAYP. Try this:

Code:
#regex {^\d+h, \d+m} {#add Prompts 1} "" {nocr|prompt}
#variable Prompts 0
#10 blink


After the spam, #echo @prompts. I got 2. Not 10, 2. The entire trigger is not firing. In addition, it is not an IRE problem. Every other client - Xpertmud, Mush, KMuddy, Wintin++, Tinyfuge, etc - operates properly on prompts. ONLY the Z/CMUD products do this. I know this is the Zuggsoft forum, but please stop defending code that is obviously not working correctly.

Secondly, I CANNOT sub in timestamps. #PSUB is broken in CMUD. Instead of putting the sub where it should go, it randomly puts it wayyyy out with about 40 spaces between the last prompt character and the "sub". Example:

I have the EX part of the prompt psub'd to be a timestamp and the EX.

I see:
Code:
3260h, 3260m, 15200e ex-                                                               ex 15:21:35.352


This should be: 3260h, 3260m, 15200e ex 15:21:35.352-

Again, it is not a problem with my code. It works fine in ZMUD. Heck, it works fine about half the time in CMUD, it just randomly pushes it way far away.
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Tue Dec 19, 2006 10:34 pm   
 
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.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Wed Dec 20, 2006 4:44 am   
 
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).
Reply with quote
Guinn
Wizard


Joined: 03 Mar 2001
Posts: 1127
Location: London

PostPosted: Wed Dec 20, 2006 12:34 pm   
 
Not read the entire thread, but if we're talking about CMUD then #PRIORITY has been deprecated and does nothing in CMUD.
_________________
CMUD Pro, Windows Vista x64
Core2 Q6600, 4GB RAM, GeForce 8800GT
Because you need it for text... ;)
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Wed Dec 20, 2006 12:49 pm   
 
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.
Reply with quote
Urit
Novice


Joined: 23 Jun 2005
Posts: 32

PostPosted: Wed Dec 20, 2006 4:17 pm   
 
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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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?
Reply with quote
MNGrizzly
Novice


Joined: 18 Dec 2006
Posts: 47

PostPosted: Fri Jan 19, 2007 8:16 pm   
 
Just doubled-checked my settings, and the EOR/GA option is enabled.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: 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?
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Mon Jun 04, 2007 5:24 pm   
 
This is still an outstanding bug and is still on the bug list. Sorry.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net