Zugg Software :: View topic - Trouble with a #SLOW path and #ALARM triggers

Beginner Joined: 15 Dec 2012 Posts: 11

I have a #PATH set up that will walk me through approx 25 rooms in a circle (the path starts in one room and makes a big loop essentially, ending up back in the first room)

It is saved as "loop"

I then also have 2 classes of triggers one with one trigger in it and a second with 2 triggers and an alias that will start the path.

Alias: lgems
#SLOW loop
#PAUSE

Class: walk
Trigger: Pattern = Hot Tunnels
#ALARM "a1" +2 {
#STEP
#PAUSE
}

Class: searchtrig
Trigger1: Pattern = * is here.
#T- walk
#SUSPEND a1
ss

Trigger2: Pattern = You begin to search around *.
#WAIT 6000
get gems
#T+ walk
#ALARM +2
#RESUME a1

The intent is that I walk through these rooms and when I encounter something in the room I will begin to search the room. This process takes a few seconds so I am trying to use #WAIT 6000 to wait for it to complete. Then reenable the walk class and the alarm to keep things moving.

I am seeing some odd behavior. First, I notice I end up with a few new triggers in my settings, they appear to be alarm triggers and continue to grow in number. This could just be related to my second issue and my continued fiddling around. When I begin to walk my path I will often attempt a NW after successfully traveling SE, this messes up the remainder of the path and thats that. I have to disable everything and try again. It sometimes manages to get 10-15 rooms into the path and sometimes only 2 (the first encounter of rooms with nw, se, etc)

Any suggestions?

Thanks

Wizard Joined: 22 Mar 2007 Posts: 2320

One problem I see is that your Trigger 2 has an alarm without any commands. What is the purpose of that alarm? That is probably the source of your growing number of alarms.

Technically the timepattern should be in curly braces: {+2}. But it sounds like it is working without that?

Do you ever get multiple statements of "* is here"? If you do, that could cause multiple threads running the trigger2 script.

Could you explain a bit more about this NW after SE? It's not clear whether there is supposed to be an NW or not.

Beginner Joined: 15 Dec 2012 Posts: 11

Rahab

I thought trigger 2 Alarm was setting the alarm to 2, which is the time delay between moving rooms. Perhaps I can remove it and only rely on #RESUME a1 to continue my movement.

It appears it is working without the curly braces, but I will use them if that is proper syntax, cant hurt!

No multiple statements of * is here.

The NW after SE thing completely baffles me. I am thinking it is some sort of left over stored queued commands which occurs because something messes up, I try to #STOP the slow walk, return to the start and start it over. Is there a way to really cancel a slowalk so it doesn't try to pick back up again? What will happen is I will #STOP it and try to move and sometimes the direction will never send to the MUD. I'll have to hit enter twice. This is why I am thinking it is still storing the commands and that is what is interefering with my movement/sending bogus directions when I dont want it to.

I'll start with cleaning up trigger 2 to remove the ALARM +2 and will implement the curly braces and go from there.

Thanks

Wizard Joined: 22 Mar 2007 Posts: 2320

The Trigger 2 alarm is creating a new alarm, because it doesn't specified a name. If you want to reset the time on the existing alarm, you have to specify the name of the existing alarm.

You are correct that #STOP will not clear the slowwalk queue--a new #STEP will resume where it left off. The difference between #STOP and #PAUSE is that #PAUSE confirms the last step, and #STOP does not. I believe to reset the slowwalk queue you have to specify a new slowwalk path with #SLOW.

Beginner Joined: 15 Dec 2012 Posts: 11

Rahab

Those minor changes worked. I set trigger alarm 2 to the named alarm. I also put the timepattern within the { } as you mentioned.

No more weird behavior with the walking. I think I just had myself in an endless loop of slow walking that I thought I was canceling by using #STOP. Sure would be nice if there was some sort of #ABORT or something. Actually, #ABORT does abort processing the current program block. I may try it if I find myself in that situation again, maybe it will work to abort the slow walking path.

Thanks for your help

Wizard Joined: 22 Mar 2007 Posts: 2320

I wonder what happens if you do #SLOW with an empty path.

Sorcerer Joined: 15 Apr 2011 Posts: 809

Does #slow manage its own queue, or does it use the mapper's built-in speedwalking queue? #queue 0 or #nodir 1 will both clear that.

Beginner Joined: 15 Dec 2012 Posts: 11

I have tried #SLOW 1-2 directions and #queue 0 and neither seemed to clear the queue. If I end it prematurely it still continues to try to slow walk me, throwing out bad directions.

I'll continue to poke around to see if I can find something that immediately ends a path for good.

Thanks for the suggestions

Sorcerer Joined: 15 Apr 2011 Posts: 809

Did you try Rahab's solution? I would imagine that would work, unless #slow just appends to the previous path...