Zugg Software :: View topic - Triggers grabbing local echo, causing pattern mismatches [solved]

Novice Joined: 16 Apr 2008 Posts: 37

So, the basic problem I have is that there are several multi-line triggers, like this:

Line 1$^Line 2$^Line 3$^Line 4$

Now what happens, is I have another trigger that will occasionally write information to the screen via #say or #echo (doesn't matter which I use), and that information is written im the middle of the MUD output, causing the trigger to not match the mud output the the pattern, and thus not fire.

So the mud sends something like this:

Line 1
Line 2
Line 3
Line 4

.. which would normally cause the aforementioned trigger to fire. However, when my #say interrupt that MUD output, what I get on screen looks like this:

Line 1
Message from #say
Line 2
Line 3
Line 4

or..

Line 1
Line 2
Line 3
Message from #say
Line 4

etc. So the #say/#echo interrupts the multiple lines of output that always come from the mud one after another, but it could interrupt it anywhere. It could come between line 1 and 2, or 3 and 4, or 2 and 3, etc. And sometimes the #say/#echo that triggers on screen can also send multiple lines of #say/#echo to the screen, like this:

Line 1
Line 2
Message from #say 1
Message from #say 2
Message from #say 3
Line 3
Line 4

So it's not like I can just make a couple new triggers in case _something_ comes between lines 1/2/3/4, as several lines of stuff could come. There doesn't seem to be any option to tell a trigger to ignore local echoes, and the only other option is to just turn off display of local echos on screen, which would defeat the purpose of displaying this information.

So, is there either:

A) A way to local echo something without it being 'grabbed' for trigger pattern matching
or..
B) A way to tell a trigger to ignore local echos

?

I consider myself a pretty competent Zmud/Cmud script writer, but this just has me perplexed.

Posted: Sat Jan 10, 2009 3:26 pm

#PRINT should echo the text locally without firing triggers. I assume that means that even if it prints in the middle of lines from the MUD that it won't prevent the matching of a multiline trigger also, but I haven't tried it myself.

Novice Joined: 16 Apr 2008 Posts: 37

Wizard Joined: 17 Jun 2006 Posts: 1201

I think this is related to some of the same problems I have been having. It only happens when you are connected to the MUD right?

Novice Joined: 16 Apr 2008 Posts: 37

Well, I can't honestly say I've tried to do it without being connected to the mud, since it depends on MUD output to actually occur.

Posted: Sat Jan 10, 2009 6:28 pm

have you thought of instead using #WIN to send all your local echos to another window so they dont get in the way?

Novice Joined: 16 Apr 2008 Posts: 37

Well, I could, but it would defeat the purpose of the local echoes. Basically, the echoes are there to show the net change in hitpoints and mana every time I see a new prompt, so I can see I gained 432 mana, and I lost 2342 hitpoints and whatnot. If I move them to another window, they lose all context.

Also, this issue isn't just related to these local echoes, it also happens on commands sent to the mud, either manual or trigger. If I have a trigger that sends "kick" to the mud every 15 seconds, stuff like this will happen:

Line 1
kick
Line 2
Line 3
Line 4

It interrupts it the same. I can type commands from the prompt and have the local echo of those commands also interrupt the trigger in the same fashion. Now for these, I _could_ disable local echoes, but to be honest, that would really suck. So, I would need to both stop my usage of the #say/#echo/#print command AND disable local echoes of commands in order to fix this problem, but if you ask me, that is more of an unacceptable workaround that any kind of actual solution.

I figure the whole local echo issue, being the most prominent, would help best explain the problem I'm having. Any solution for any aspect of this problem would probably solve the problem all together, I just don't know what that is, or if there is even a solution.

Posted: Sat Jan 10, 2009 7:11 pm

you could use #SAYPROMPT, then the next line would concatinate onto it... unless your multiline trigger is anchored to the front of the line... or #SAYADD to put yours at the end of the line instead of beginning

you could also set up a status window/line and have your settings change the value of variables therein for display purposes

Wizard Joined: 22 Mar 2007 Posts: 2320

An alternative solution would be to use a multistate trigger instead of a multiline trigger. Have each line caught by a successive state of the trigger, and have every state after the first be of type 'Within Lines', say 2 or 3 lines. Then it will still match as long as not too many extraneous lines are inserted.

Novice Joined: 16 Apr 2008 Posts: 37

Hmmm, both do seem in theory to be good solution. The first solution, if I change all of my prompt based #say commands to be #sayprompt instead, would resolve the issue if I changed my triggers to NOT be anchored to the beginning of the line. (as they would be if they came as uninterrupted MUD output), but doesn't solve the problem if the local echo of a command send to the MUD interrupted that output.. since local echo of commands do always add a carriage return.

I've not used a multi-state trigger before, but as with anything, how hard can it be to figure out. I'm going to try to convert my multi-line to a multi-state trigger and see if that fixes things, although I imagine it should, as at most 3 lines of data could come between said MUD output.

Thanks for the feedback guys, here goes nothing.

Enchanter Joined: 09 Sep 2007 Posts: 605

Multistate trigger will be good solution. I even think that you'll have no need to use "within lines" option because your #SAYs will not interfere with your trigger states.

Additionaly, consider the following workarounds:
1) Dock a toolbar to the bottom of your window. Place large button there and change its caption instead of printing messages
2) Use #MESSAGE
3) Think, whether really it is necessary for you to see these messages "in place"? Wink

May be it is only a habit?

Novice Joined: 16 Apr 2008 Posts: 37

Well, the messages being in place do help for me to spot whether I saved mana on a spell, or a particular mob hit me for 3000 damage, or I spent a ton of mana on a group spell, etc. When not in place, they lose their context, as these messages are coming constantly in and out of combat.

Multi-state triggers do seem to be a good idea, except I'm now having to replace 5 different multi-line triggers with 1 single multi-state trigger, and it is turning into hell. And since the starting pattern is the same for each multiline trigger, I can't just create 5 different multi-state triggers with different pattern matching "paths".

Well, after all this trying to convert my multi-line triggers to multi-state triggers without contemplating how it shoudl work before I began to edit, I've royally screwed this particular system of triggers and have scrapped it and are starting over. :)

I think the multi-state system has merit, and I should be able to build around it, I just can't approach things how I use to with my multi-line trigger.

Enchanter Joined: 09 Sep 2007 Posts: 605

Novice Joined: 16 Apr 2008 Posts: 37

Well, one thing that complicates the equation is that of my old multi-line triggers, 1 of them was 2 lines, 2 of them were 3 lines, and 2 of them were 4 lines.

And the last line of every multi-line trigger was ^(*)$ where the value of %1 was checked to be something in particular, and if it was somethign in particular, a specifc action was taken.

So converting that to a multi-state trigger was a mess, because I essentially had the trigger sequence being able to end at state 1, 2 or 3. Also, since lines 2 and 3 (if they weren't this something in particular message) could be the same, I ended up having the pattern for state 1 and 2 being exactly the same, which as we all know, you can't have 2 triggers with the same pattern.

Currently, and this is less than what I had hoped for, my solution is just to collect all the possible responses that would be captured by the last line of the pattern.. ^(*)$ .. and replaced it with 2 states.. the first line (which is always the same) and the last line, skipping all the different possible lines in between. The only problem is, that there is not always a message associated with the last line captured by ^(*)$, so I have to omit certain events from this new trigger.

This all sounds very ambiguous now that I haven't gone into detail about what exactly these triggers do, but suffice it to say, I think with my understanding of multi-state triggers, the only feasible solution that could have equaled my old multi-line triggers in flexibility, isenabling some option for triggers to ignore local echoes. As it stands, the only functional multi-state trigger trigger doesn't have all the flexibility that my old triggers had, but I guess that's life. If Zugg adds some new functionality to triggers to be able to ignore local echoes, I'll probably go back and redo my trigger system, but for now, That is all She Wrote.

Thanks for the help guys.

Novice Joined: 01 Jan 2009 Posts: 35

the #message workaround mentioned by Arde isnt practical? it would allow you to use your old triggers...

Novice Joined: 16 Apr 2008 Posts: 37

If anyone is curious, this is what I'm trying to do... Whenever I go to cast a spell, I put the name of that spell and the target of that spell into a variable. When the spell is cast, the first line is always "Ok."

The second line could be one of five things: (we'll assume for this example I am casting the "ray of freezing" spell)
A) You managed to conserve some magical energy!
B) Your superior knowledge of magic enhances your spell.
C) Due to your masterful knowledge of the ray of freezing spell, you manage to save X mana casting it.
or
C) Due to your masterful knowledge of the ray of freezing spell, you manage to cast for greater damage than normal.
D) Icy waves spew forth from your hands and envelop Monster in a misty freezing cloud!
E) You lost your concentration!

Option D is a successful casting of the spell, and option E is a failed casting. If I suceed in casting, I merely want to execute an alias I have (called shiftqueue) to clear out the #1 spell in the queue (what I'm casting now). If Option E is true however, I want to recast that spell with the information stores into variables.

However, if Option A, B or C occurs, then it needs to keep processing, and the same options are there..
A) You managed to conserve some magical energy!
B) Your superior knowledge of magic enhances your spell.
C) Due to your masterful knowledge of the ray of freezing spell, you manage to save X mana casting it.
or
C) Due to your masterful knowledge of the ray of freezing spell, you manage to cast for greater damage than normal.
D) Icy waves spew forth from your hands and envelop Monster in a misty freezing cloud!
E) You lost your concentration!

So, I can see "Ok.", then followed by "You managed to conserve some magical energy!", then followed by "Your superior knowledge of magic enhances your spell.", then followed by "Due to your masterful knowledge of the ray of freezing spell, you manage to cast for greater damage than normal." and finally followed by "Icy waves spew forth from your hands and envelop Monster in a misty freezing cloud!"

Before, my 5 multi-line trigger patterns were:
1) ^Ok.$^(*)$
2) ^Ok.$^You managed to conserve some magical energy!$^(*)$
3) ^Ok.$^You managed to conserve some magical energy!$^Your superior knowledge of magic enhances your spell.$^(*)$
4) ^Ok.$^Your superior knowledge of magic enhances your spell.$^(*)$
5) ^Ok.$^Your superior knowledge of magic enhances your spell.$^You managed to conserve some magical energy!$^(*)$

Every trigger would check to see if the value of %1 (captured from the ^(*)$ segment) was equal to "You lost your concentration!", and if so, would recast the spell. If not, it would clear the first spell in the queue and continue on.

However, you can see the complication with attempting to make a single multi-state trigger out of a situation with so many different outcomes.

Right now, the multi-state trigger is like this:

State 0 Pattern: Ok.$
State 0 Action:
State 1 Pattern: ({@spellcastlist|You lost your concentration!})
State 1 Action: if %1 = "You lost your concentration" then recast the spell and clear the first item in the queue, otherwise clear the first item in the queue.

And @spellcastlist is a string list that contains all spell message success and failure message. The one caveat here is that not all spells have successful spell cast messages, so I have to omit some spells from this system.

Magician Joined: 17 Apr 2005 Posts: 496

Why can't you keep having five separate triggers? You will have to give them unique "names", but call them foo, bar, foobar, thistrigerhasnoname, and, umsomething....

Novice Joined: 16 Apr 2008 Posts: 37

Novice Joined: 16 Apr 2008 Posts: 37

Magician Joined: 17 Apr 2005 Posts: 496

That was one of the big deal things about CMud, as long as you give them separate "names"/ids they can have the same pattern (and yes, unnamed triggers simply go by the pattern).

Novice Joined: 16 Apr 2008 Posts: 37

Just for the record, making 5 different multi-state triggers to replace my original 5 multi-line triggers did the trick. It works as it should now.

Wizard Joined: 22 Mar 2007 Posts: 2320

Actually, it sounds like you don't need to pay attention to lines A, B, or C. Just take them out of the multistate trigger entirely.

Novice Joined: 16 Apr 2008 Posts: 37

Well, that was an interim solution, except Line 4 can be blank, so without line 2 and 3, I can't make any assumptions on exactly what happened.

Not all spells have "success" messages, so all I have to go on is sometimes just Line 1, and possible Line 2.