Zugg Software :: View topic

Wanderer Joined: 27 Feb 2003 Posts: 69 Location: Australia

Is it possible to enforce sequential parsing of the MUD output on zMUD?

I seem to be getting a issues lately where zMUD seems to be attempting to parse lines in parallel (This is especially prone to happen when I #say something.)

Note that I'm not referring to loops, where #PRI would solve the problem, but normal triggers which I can see no way to prioritise.

Any ideas?

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

If you mean forcing one trigger to fire before another, nope. You can try #priority, but I don't think it's going to apply.

If you mean a specific trigger's code executing in a certain order, that's what #PRIORITY is for. With #PRIORITY, ZMud actually stops and waits for that #priority block to finish executing before continuing on. It's a lot like a wait-state condition, except designed for code instead of pattern-matching.

Wanderer Joined: 27 Feb 2003 Posts: 69 Location: Australia

Triggers fire in the order you put them into - I'm pretty sure of this as I have interdependent triggers.

My problem is that *sometimes* (not always) zMUD will start parsing a new line while it's still parsing an old one (say it's parsing line 99, and some variables get set that indicate that the parsing of line 100 has started).

While your statement regarding #PRI is correct (and it can't solve this problem) my understanding is that it only makes a difference in the case of loops. From what I've seen, zMUD pretty much executes triggers sequentially unless it encounters loops.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Nope, it definitely works on any command that has code blocks. It was annoying to figure out why a trigger of mine wasn't executing properly and it turned out that it was a #CASE command that was slowing things down.

Wanderer Joined: 27 Feb 2003 Posts: 69 Location: Australia

OK, that's different from what I thought. Might have to go through my triggers and re-organize the command order.

Did you have a problem with different triggers acting on the same line or with triggers on different lines?

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Wanderer Joined: 27 Feb 2003 Posts: 69 Location: Australia

Triggers mis-firing is not my problem. That can easily be resolved.

What I'm referring to is lines from the MUD not being processed sequentially, which is what I need for some of my triggers.

I'm now trying to prioritise the relevant parts of the code (via #PRI and moving the essential parts to the start of the trigger commands). Hopefully that will solve the problem.

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

Couldn't you introduce variables or disable/enable triggers to stop things firing when they're not supposed to, rather than relying on them firing in a specific order?
If you post a few examples of the things that need to fire in a specific order we might be able to find a way around not being able to guarantee a firing order.

Wanderer Joined: 31 Jan 2006 Posts: 55

If I understand what you are saying, then i've had the same problem you have.

Occassionally it seems that zMud does not parse things correctly, usually when there is a lot of processing to be done in the script. #PRIority does not solve the problem.

The result is i'll have a trigger firing more than once and not using the correct input it should be. It will sometimes use the previous input it received again for no apparent reason. I can't seem to reliably duplicate this problem. It just seems to happen when there is a -lot- of processing going on in the script, as if zMud hiccups and does not do it in order.

For example if I were to put a #echo in the script at the beginning, (it's a very long script with some for loops), and say that the triggers triggers on the text:
"Hello there %(randomnumber)"
And the mud sends tons of Hello there's at once with entirely different randomnumbers... SOME of those #echos will have the same number. I can't explain it nor duplicate it...

Magician Joined: 29 Nov 2005 Posts: 482

im confused. Isnt that what conditionals are for in trigger matching. Once first thing is matched the do next thing until end of conditions list?

Wanderer Joined: 27 Feb 2003 Posts: 69 Location: Australia

mo24 - I experience that too. My solution to this problem has been to simplify the way I do things (cut down debugging) and it now seems to be working.

The glitches you mention have not all disappeared, but I can live with that. I am curious, however, as to why some triggers only work like 99.9% of the time.

edb6337 - multi-state triggers cannot help in this case. The problem is that lines returned by the MUD get processed out of sync so that two lines are being processed at once. My code does not handle that very well (luckily it's only cosmetic - it spits out lines that I want gagged)

Magician Joined: 29 Nov 2005 Posts: 482

i run into that problem myself LOL things get gagged i dont want gagged and vice versa if the trigger parsing happens out of sync as well. I am not sure i completely have grasped what your problem is in reviewing this thread though as instead of having two triggers that could process lines out of sync i have one trigger with a conditional now so that it helps avoid that problem.

Im sure you have a better idea than i do of what you are trying to do so forgive me if i post something that doesnt help ya :)

Wanderer Joined: 27 Feb 2003 Posts: 69 Location: Australia

Well, I finally cheated and sorted out the specific situation that was causing me grief. It now works fine, but the problem is still there.

edb6377

This all started from the problems you mention with gagging. I have changed the way I gag in order to avoid gagging the same line twice. A simplified version of the system I use is this:

#TRI {^*} {#VAR NEWLINE 1}
#ALIAS mygag {#IF (@{NEWLINE}) {#VAR NEWLINE 0 ;#gag}}

This has been working fine (for almost 3 years now), but relies on zMUD processing just ONE line at a time. The problem is that in certain cases (well, one up to now) zMUD seems start to process the next line before I can gag the current one, so I essentially try to gag that line twice. I was able to work around it, but not fix it so that it does not happen again.