Zugg Software :: View topic - Command Input Trigger Suddenly stops working

Posted: Fri Jan 20, 2006 9:03 am

I've got a rather complex trigger to activate upon typing "ih" which gets a list of enemies in the room and concludes when it sees "Number of objects". It uses states and reparses to work its way through the list.

It first activates itself upon seeing "ih". It takes the next line and reparses it to see if it is an enemy listed. If it is it sets itself back to state 1 to wait for another possible enemy line. After all the enemy lines it triggers on "Number of objects" and sets itself back to state 0. If it gets a line it doesn't recognize as either it assumes it is a blank line and uses the final reparse to catch that and set it back to state 1.

So it's a nice little state machine which works very well. The problem comes in when it suddenly stops working. It will be working for about half an hour or less and then it will suddenly stop working. If I put a print statement in the Oninput command list it doesn't even recognize the "ih" when I type it. I've even tried to manually set it to state 0 and to manually activate it. Nothing works. The two things that can make it start working again are: Exit Zmud and restart the program. Or second, copy the trigger then paste it to the same directory, then delete the original.

This seems like a bug to me, because it works, then doesn't and can be made to work again by restarting the program or copying the trigger. However, I'm open to the possibility that it may be something in the command I'm doing that isn't particurally combatible with Zmud.

Any ideas?

#ONINPUT "grabIH" {^ih$} {
#var longTargets ""
#var shortTargets ""
} "" {prompt|regex}
#COND {^.*$} {} {regex}
#COND {^"(\w+?)(\d+)"\s+} {
#if (not %ismember( %1, @listExclude)) {
#additem longTargets %concat( %1, %2)
#additem shortTargets %1
}
#state grabIH 1
} {reparse|regex}
#COND {^Number of objects:} {
#state grabIH 0
reviewTargets
} {reparse|notrig|regex}
#COND {^.*$} {#state grabIH 1} {reparse|regex}

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

I've had similar problems with complex triggers, usually multi-state ones such as this, just quitting on me. Building a new trigger with the exact same properties works, so I would classify it as a bug in zMUD. The only solution I found for this particular problem is to implement the state machine in a totally different way. I would recommend you use a class folder with one trigger to capture targets and another to disable it when you reach the 'Number of objects' line. Making an ih alias would also be more reliable than the command input trigger. (For example, your pattern wouldn't match if you first typed a space and then 'ih' as you've locked it down with ^ and $.)

Posted: Fri Jan 20, 2006 4:20 pm

If this is a known bug, does anyone know if this is planned to be fixed? I had loved the fact that I could do everything in a single trigger. From my perspective it makes it a much cleaner solution. Separating it all out seems like a step backwards.

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

I don't see how a complex five state trigger is cleaner than two triggers and an alias in two class folders, but to each his own. :)

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

The multistate trigger is officially grouped together, so you don't have to micromanage it. Written properly, the multistate trigger will take care of itself without ill effect on anything else you do.

Wanderer Joined: 17 Nov 2005 Posts: 65

Interesting. In my case a long while back, though cause it was done over time, it wasn't as easy to provide step by step of how I ran into the issue to start out with. Anyhow, I also had problems with triggers quit working on me, though it wasn't with multiple state triggers (as I didn't have any and still don't), but more so when a trigger got copied from one class and pasted to another class. That was when I deleted it from the original class and that was more or less done for organizational purposes as well as being able to group triggers based on types of characters cause of the fact that I didn't want to have to recreate so much stuff that pertain to the site for each and every single character that I used on the site. To overcome that issue, I used the same layout file, but that meant I had to group all of my stuff based on character types, and that's when I ran into triggers not working properly sporadically. There was no distinctive pattern as to when it would work and when it wouldn't work, but it was pretty evident when I took it from one class to another is when I ran into the issue.

Of course, since everyone was getting after me about providing such detailed steps and I had tried it different ways, I ended up leaving the forum for quite some time. That's cause when I first started out, I didn't expect to run into the issue and therefore other than just doing it the normal way such as go to the trigger option (prior to when the trigger button was available in the primary toolbar), click on New, Trigger, then type in the pattern, click into the editor and put in what to do when that pattern happens, and checked the other options to be sure they were set properly (most of which on the Options tab). Of course, when I do run into issue, I pay attention to details, but when you aren't expecting any, you may not remember the exact detail stuff and since that was done over time such as trigger created at one point, and then copied and pasted at another point of time and so forth, it's possible that one could think they did it one way and actually did it a different way. Of course, after that experience, the lesson from it was to pay to attention to every detailed step for every single thing you do in the program and make note of it, even if you aren't expecting problems cause if you don't, then you bound to get griped at back from the community when you do have an issue.

The sad thing about this experience, especially given that I do work with programming stuff, it's like you expected to remember everything and I don't even do such detailed stuff at times when programming. Of course, I do go through the planning phase before I program, but often times, I go ahead and program and if I do run into an issue, I then go into very detailed analytical stuff. If I did that with everything in programming before I actually did the programming, I wouldn't have made it nearly as far as I have with my programming, so by limiting it down to the ones that I have issues with, that's allowed me to get a lot more stuff programmed.

Now, when you do have things that you haven't used before and not sure how it works, of course, you have to test that stuff out, so there has to be some sort of a balance, but again, after you learn how things works, but without necessary testing for each and every single problem that you *could* run into (though I do still test quite a bit), one can get a lot more stuff programmed. For some things though, you simply use rules to avoid a lot of such issues which I have created several in my days of programming.

Sincerely,

Dodgester