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

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » zMUD General Discussion
Juran
Newbie


Joined: 11 Aug 2006
Posts: 7

PostPosted: Thu Aug 24, 2006 6:54 am   

Minor Irritation - Trigger States (bug?)
 
Minorly complicated example, but I'll break it down.

Code:
#TRIGGER {^You quickly eat a galingale flower.$} {#IF ((@illusion == 1) OR (@canEat != 1) OR (%if( @lastEat =~ "galingale", 1, 0) = 0)) {#STATE 0} // Pre-illusion check} "Combat" {case}

#COND {^<%d/%dh %d/%dm} {#IF (%line2 =~ "~*~* Illusion ~*~*") {} {#STATE canEatTimer 1;canEat = 0;failedEat = 0}} {within|param=2|nocr|prompt}


The first trigger, once it fires, checks a few variables and resets the state if they don't match. Nothing is actually processed here, other than a few checks to make sure that it's possible for the above line to be received legitimately (not an illusion). This part works absolutely fine.

The second trigger happens on the next prompt. In a legitimate (not illusionary) case, the prompt will be between 1 and 2 lines after the above triggered message. If it comes immediately there's no problem, but it's possible that the prompt will be preceded by the ** Illusion ** warning text. This isn't guaranteed, and only happens during 50% of illusions.

So here's the problem:
- If I set the conditional to fire on 'newline', the variable %line2 becomes.. random. It occassionally picks the right line, but will more often than not skip down a few by the time it processes. This makes the secondary ** Illusion ** detection nonfunctional. No matter what comes between the first line and the prompt, it will almost always fire.

- If I set the conditional to fire on 'prompt'. the conditional completely ignores the within|param=2 trigger type. It properly identifies illusion messages appearing after, but the prompt can come four lines below the original trigger and it will still fire normally.

So is there anything I can do to compensate for this rather unusual and difficult trigger conditional behavior?
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Thu Aug 24, 2006 2:15 pm   
 
It's not a bug, but it's an undocumented feature. Using within|param=# with nocr|prompt may not work as you intended, and my guess is that it's because there is no CR/LF to make it a complete line. Are you using GA/EOR emulation? That may or may not help.

I take care of the ** Illusion ** detection in two ways:
1. If it precedes the illusion message, you simply disable the class folder with the tracking triggers in it.
2. Queue up actions in your triggers in a string list. If you see the illusion marker, you clear the string list. On each prompt, you execute all commands stored on the string list, clear the string list, and then do your curing.
Reply with quote
Juran
Newbie


Joined: 11 Aug 2006
Posts: 7

PostPosted: Thu Aug 24, 2006 2:40 pm   
 
Thanks for the ideas.

The first one is easy, a very simple trigger and if-check guarantees that any illusion received with the first warning is ignored without the speed reduction problems of disabling an entire class. The variable @illusion is reset to 0 on the prompt.

Your second mechanism is certainly an option, if I can't find a way to make what I have work. It loses secondary, non-Lifevision based, detection ability; because it couldn't efficiently count lines to verify that the prompt comes when it should. It also requires dumping and processing everything from a list on every prompt, instead of only doing such things when necessary. But it's better than what I'm currently working with, given the fickle nature of the problem.
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Fri Aug 25, 2006 9:52 pm   
 
You don't use multiple states. You just use simple triggers, aliases and variables.

Alias to add things to the queue.
Alias to execute the queue.
Prompt trigger that executes the queue.
** Illusion ** trigger to turn off tracking until the next prompt and also clear the queue.
Any tracking triggers you have will use the queueing alias to setup their commands instead of doing it directly.

In some specific cases, it's a little trickier than that, but that's the basic principle.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » zMUD General Discussion All times are GMT
Page 1 of 1

 
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