Zugg Software :: View topic - Achaea's "Now now, don't be so hasty!" message

Posted: Wed Jan 04, 2006 8:41 pm

In Achaea if you try to move too soon after your previous command you get the infamous "Now now, don't be so hasty!" message.

I've discovered that to walk the fastest I need to follow this sequence of events:

{walk
prompt
wait for 300ms}
{walk
prompt
wait for 300ms}
etc...

Zmud doesn't exactly have this type of functionality from what I can observe. What it does is pretty close. It has the capability to watch for key words that indicate you've made a successful walk and you can delay your commands by a certain amount. While this functionality works most of the time, it doesn't work in the following situation:

(start walk)
(Lag hits for a second or two)
(Mud receives the walk command and updates my screen)
(Zmud having already waited the specified certain amount sends a new walk)
(Achaea seeing two almost back to back walk commands issues a "Now now, don't be so hasty!" message")

So everything hinges on waiting for a certain amount of time *after* I receive the prompt:

I think this would work, I'd like to know if anyone sees anything wrong with this:

#alias {onroomenter} {#pause; #alarm (+0.3) {#step}}

If onroomenter is triggered after it receives an #OK, then this is exactly what I want. But I'm not sure exactly when onroomenter is triggered. Also I'm unsure of whether the alarm can handle as small as 300ms.

An alternative I've considered is:

#alias {onroomenter} {#pause}
#trigger {^You see} {#alarm (+0.3) {#step}}

This would cause me to continue 300ms after it sees my exit message. If any more knowledgeable people can help refine this I'd be very appreciative.

Thanks,
ReedN

Apprentice Joined: 11 Sep 2005 Posts: 124

.501ms I think is the lower limit of alarms

Posted: Wed Jan 04, 2006 9:19 pm

I'd like to get a clarification of the lower limit of #alarm because I've seen seemingly contradictory documentation:

From #ALARM Definition:

http://www.zuggsoft.com/modules/mx_kb/kb.php?page=3&mode=doc&k=241

The smallest period of time that can be matched by an alarm is half a second.

From: Timers, Alarms, and the WAIT Command

http://www.zuggsoft.com/zmud/timers.htm

#ALARM +0.5 {cast spell}

will cast the spell after a delay of only 1/2 second. Windows can only time things with a resolution of 10 ms or so, so don't try a really small delay or it probably won't work.

From this is seems that you can set it to anything but don't expect a resolution of better than 10 ms. If the #ALARM function doesn't work in this scenario, are there alternatives? How about the dreaded #wait? Is that the only other alternative?

ReedN

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

Don't even think about using #WAIT. #WAIT stops ALL of your triggers, alarms, and so on, which will throw all those things off as well. Since the game is still sending you information during the #WAIT period, that can be a lot of text and a lot of text can sometimes scroll so fast that zmud's parser won't be able to keep up, making it seem as though the trigger isn't firing.

Posted: Wed Jan 04, 2006 11:15 pm

#alias {onroomenter} {#pause}
#TRIGGER (%walkconfirm) {}
#COND {} {#STEP} {Wait|Param=300}

How about that? It will pause automatically when coming into a room. It will trigger off of the %walkconfirm meaning I've gotten an #OK, wait 300ms and then submit the #STEP. Hopefully I got the syntax correct for that trigger.

Wanderer Joined: 25 Oct 2005 Posts: 99

Have you considered setting step delay? (Mapper->Config->Configuration Settings->Speedwalking->Step Delay)
Try setting this number to at least 300 (the value is in milliseconds).
The value is designed to wait xxx milliseconds before moving.

Posted: Thu Jan 05, 2006 5:04 am

Correct me if I'm wrong, but is the "Step Delay" the time between steps or does it start counting from the time it gets an #OK? In the case of lag this difference makes all the difference.

If it is purely the time between when it sends commands, then it doesn't do me much good, if it is the time from the #OK to the next walk command, then it is what I need.

Wanderer Joined: 25 Oct 2005 Posts: 99

As far as I know, it is what you are looking for. Lag has never caused me to miss a step while using it. It should be the time from the #OK.

Posted: Thu Jan 05, 2006 7:43 pm

One problem I'm running into with using the onroomenter alias is that something is generating an #OK after the onroomenter alias. This is causing it to disregard my #PAUSE from that alias and to continue walking. So the ordering of events as I can understand them goes:

Room Name or Description generates => #OK
#OK confirms step and updates map
onroomenter alias executes => #PAUSE
(Something causeing another #OK)
Prompt causes a #STEP due to the above #OK and I continue walking disregarding the fact that I wanted it to pause.

I'm not sure where the #OK is coming from between the onroomenter alias and the prompt, but it is causing problems. I had to then put another #PAUSE in triggered off my exits to really pause it, but this causes the automapper to not update because it doesn't get an #OK.

This doesn't make sense to me because the map should update before I get to the onroomenter (according to documentation). I had to place the #PAUSE triggered off the exit because it was getting an #OK from somewhere after the onroomenter alias. The map should update before the onroomalias is executed.

If it is helpful I'll say that I #TAG my room description, exits, and prompt.

This is my confusion based on the documentation I've read. I'd welcome some clarification from someone who has access to the actual code.

Wanderer Joined: 25 Oct 2005 Posts: 99

Understanding Speedwalking in Detail (Article by Zugg)
http://www.zuggsoft.com/page.php?file=library/speedwalking.htm

Setting up the Automapper (Tutorial by Nexela)
http://forums.zuggsoft.com/modules/mx_kb/kb.php?page=3&mode=doc&k=36&highlight=configure+automapper

Quoted from the above documentation:

Posted: Thu Jan 05, 2006 8:52 pm

I had already read both of those. Neither of them address the question being posed. According to the arctile by Zugg on speedwalking, the #PAUSE should have worked as I originally had intended. Where the extra #OK was coming from after onroomenter is the question. It is that extra #OK that is causing the walk to continue instead of pause like I want.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Just write you own walker. I got mine so I can even double-click on the map it will go from there. I use a 1 second pause and that is plenty fast enough for running around on Achaea.

Posted: Fri Jan 06, 2006 6:22 pm

From what I have observed the "Step Delay" is not equivalent to what I need. The way I have it setup (from above) there can be a 10 second lag or a room that costs a lot more time to travel through and I zoom around without the slighest problem because I start counting from when I get an #ok. If I try disabling my #pause logic and set the "Step Delay" to an equivalent value I get lots of problems with "Now now, don't be so hasty!".

I still haven't answered the question about where the extra #ok is coming from, but I've worked around it by sensing the map state and either issuing an #ok or a #pause based on whether I'm mapping or not.

Magician Joined: 17 Apr 2005 Posts: 496

I play Imperian and I was able to get it to behave nicely by setting the step delay fairly high (~1 second) and setting the walk mode to "SLOW". You'll also want to make sure you have automatic step confirmation on... That's all I needed. After the actual mapping triggers, the speedwalking was anticlimactic.

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

I use the Step Delay with a setting of 650ms, and I don't get the "hasty" message. In Lusternia, I have celerity while in stagform, so I set it down to 400ms and it lets me move faster, still without the "hasty" message.

I would suggest that something in your configuration is causing you to confirm things when you shouldn't, or vice versa. With the proper triggers and the right configuration, you can speedwalk fairly well without using #OK, #PAUSE, and #STEP.

Posted: Mon Jan 09, 2006 8:29 pm

I have this working by putting the #pause in the trigger for the exits, but it really bugs me that the specified order (from Zugg's Speedwalking Explanation) doesn't correspond with what acutally happens.

According to documentation this happens:

Room Name or Description generates => #OK
#OK confirms step and updates map
onroomenter alias executes
Prompt causes a #STEP due to the above #OK

What I actually observed happening:

Room Name or Description generates => #OK
Prompt causes a #STEP due to the above #OK
#OK confirms step and updates map
onroomenter alias executes

So Zugg's documentation says that the onroomenter is executed before the prompt while in practice it executed after the prompt for me. This means that a #pause in onroomenter will never pause it because the prompt will cause it to move before it can pause it. Has anyone else ever experienced this?

My workaround was to #pause in the trigger for the exits which is the thing that executes just before the prompt. This interferes with mapping, however, so I have to detect the state of the map to determine whether I pause or give an ok.

Some insight from someone who has access to the code would be appreciated.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I have tested repeatedly on this in the past and found onroomenter to be preformed immediately as a result of the #OK trigger that is automatically generated for each room. While I have produced many different walking solutions involving the use of #PAUSE in the onroomenter alias, I still find it to be best to just write my own slow-mode speed walking script. The most likely candidate for the problem you describe is another trigger issueing an #OK between the onroomenter and your exit line. I believe #OK and #PAUSE change the state of an internal variable, that scripts do not have access to. This variable would be part of the checks done by the prompt detection to determine if another direction command should be sent. So try to locate the cause of your extra #OK.

Posted: Tue Jan 10, 2006 3:22 am

To determine the exact order in which they were running, I put a #say message at the beginning and end of each of the following sections: Title, Exits, onroomenter, prompt:

The order of the messages clearly indicated that the onroomenter alias was in all cases run after the prompt, in the following order:

Title detection
Exits detection
prompt detection
Roomenter alias

I do not understand how an extra #ok would change the order in which these occur.

I am very curious about what you mean by writing your own slow-model speed walking script. You've mentioned it a couple of times, but I'm not exactly sure what is involved in doing that?

SubAdmin Joined: 18 Nov 2001 Posts: 5182

The most basic model is establish a path queue, send 1 direction, confirm movement, check status flags, do any necessary actions, finally activate an alarm to send the next direction in the queue. More complex models can do things like searching for secret exits within the path repeatedly, or one I did which contained information in the room data that told it a certain exit required levers to be pulled in other rooms. Then when it wanted to go through that exit and found it not available it would store the current path, compute the new paths, walk them then resume to original.

The more I think on what you are having for a problem, I keep coming back to the idea that it is likely caused by the #TAGging triggers commonly used to map Achaea. If you have a working system, then you should likely use that until you learn more. Writing you own walking model is not for the faint of heart.

Posted: Tue Jan 10, 2006 3:58 pm

Yeah, that sounds fairly complex. I do have most everything worked out except for one small detail. Sending the #ok half a second later works fine for speedwalking, but when I'm just controlling it manually it can become a problem because I might take another step before it has sent the #ok. If I do take a step before it has sent the #ok, then the mapper thinks that it didn't complete the last step okay and it backs up to the previous square.

What I need to fix this problem is a variable that tells me whether it was the automapper that sent the command or if it was me from the keyboard. None of the variables seem to fit that description. Those system variables I've examined like inwalk or walkactive etc seem to always be set whether it was me moving or the automapper's speedwalker. I'm thinking I may need to set a commandinput trigger and set a variable myself unless there is a variable I missed that gives this information.

GURU Joined: 26 Jul 2001 Posts: 1958 Location: Canada

One way to overcome that is with trigger/alarm id. Have it overwrite the alarm id with something else if you move before it fires.

Posted: Tue Jan 10, 2006 4:14 pm

That's fantastic. Even better than what I was planning, I had no idea you could do that to alarms.

GURU Joined: 26 Jul 2001 Posts: 1958 Location: Canada

Also very useful if you want to re-extend the alarm.

#TRIGGER {Something that can spam we rapidly a few times} {#ALARM OverwriteThisIdIfRetriggered +1 {stop}}

That way you aren't sending stop stop stop stop stop stop stop.