Zugg Software :: View topic

Apprentice Joined: 18 Jan 2001 Posts: 116 Location: USA

Here I go again. This one may be a little more involved...

I'm trying to accomplish something that seems (in theory) pretty simple.

There is an exit in a room that opens after a delay when you enter a command... such as 'move trash'. You can't use the exit until the trash is finished being moved, which is indicated with a message from the mud. In the most simple case I would like to:

pause when I get to the room
issue the command to open the exit
wait for the message indicating the exit is open
resume walking down the path that was paused

In a little twist, I'd like to account for the possibility that I might not want to take that particular exit when I walk through the room. So, I wanted to do a test of %nextdir() and only take the above steps if necessary.

What I have tried is:

room script with #pause and #echo %nextdir() -> not good because %nextdir() returns the direction I moved to enter the room, not the next direction I'll take to leave the room

left room script blank, and added onRoomEnter event in the room's folder -> it also echo %nextdir() as the direction I took to get to the room

added #T+ ROOMPROMPT (which is an onPrompt event in the class folder for this room) -> echo from this event shows %nextdir() to have no value (even though I had entered further directions in the path)

If I try to #STEP at this point then nothing happens.

What am I missing here? It seems like it'd be some pretty common logic to want to stop in a room, take some actions, wait for something to happen, then continue along the predefined path.

Thanks in advance!

Wizard Joined: 22 Mar 2007 Posts: 2320

Here's an idea. Give that exit a short name. The short name should be the name of an alias within the room's folder, which executes the knock, then a #WAIT, then the movement. This solves the problem because the alias won't be executed unless you are actually trying to go through the exit.

Apprentice Joined: 18 Jan 2001 Posts: 116 Location: USA

I appreciate the help, but that seems like a work-around for what would seem to be basic functionality of slow walking... enter a room... pause... do whatever you want... then resume the slow walk. There are many other situations where this would be helpful... not just with exits that have a delay in opening. For example, whether I stop to rest might depend on the condition of me and/or my group... or what mobs show up on scan in adjacent rooms. Any clean way to get this behavior?

Thanks again!

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

In the room, set the name of the exit to the command used to start moving the trash. This will be the key that drives the rest of your room script.

In the Other Properties of said room, check the box that says something about pausing in this room for speedwalking. This will force all speedwalks into this room to automatically stop, waiting for you (ie, your room script) to give the okay to resume.

In the Room Scripts of said room, you can set up a #WAITFOR in the class's enable script tab. This command allows you to define the pattern to match, the code to execute when it matches, the timeout value in case the match-pattern never happens, and the code to run when the timeout happens. The match-pattern code would be the command to move through the now-available exit and the #OK command (might not need this, since the speedwalk might naturally resume once you actually move). The timeout code would just be the #OK command. You may wish to use #SENDRAW to send the command during the match-pattern code, since it doesn't echo the command and therefore won't interact with the mapper queue any.

Apprentice Joined: 18 Jan 2001 Posts: 116 Location: USA

Just played with this briefly... will experiment more tomorrow... but here's what I've found so far:

Checking the box to pause in the room works for speedwalking (as indicated), but not for slow walking (which is what I'd really prefer to be doing). It seems like there should be a way to pause and resume slow walking, too...

Once a speed walk is paused by the room setting, you can't issue any directional commands. They get stored and all sent at once after you use the #STEP command. #OK seems to do nothing.

In a speed walk paused by the room setting, the %nextdir() is really what you'd expect it to be... the next direction you will move with #STEP (unlike the behavior I saw with pausing a slow walk with #PAUSE).

It'd be really nice if there was a way to control pausing on the fly, instead of forcing a pause in every single room where I might ever want to do something. I recognize that you can pause in slow walking, but it doesn't seem to behave the same (correctly?). For instance, is there ever a situation in slow walking where %nextdir() is really the *next* direction you will move?

Thanks :)

Apprentice Joined: 18 Jan 2001 Posts: 116 Location: USA

Ok... tired and frustrated. :) I spent most of the day playing with this, and it's been like banging my head against the wall. Is there any place that documents in detail how the mapper works? What happens when? When exactly do events fire... and things like %nextdir() and %inwalk() get set?

I'm seeing a lot of inconsistencies in behaviors... even without changing settings. For example, I turned off auto step confirmation and sometimes %inwalk() is true after I send a direction to the mud... and sometimes it's not. I am tagging the room name, exits, description, and my prompt successfully every time. I enable an onPrompt event when I see a room name. Inside that onPrompt event I check the status of %inwalk(). If it's true (meaning I actually moved instead of typing 'look') then I do an #OK. If I get a false negative from %inwalk() then I don't issue the #OK and things get messed up.

I did try the auto-configure yesterday. It seemed to work fine except for a couple of issues that led me to the manual route. It didn't provide any way to pause a slow walk in each room, run whatever testing/commands I chose, and then resume the slow walk. onRoomEnter and onRoomWalk did not work for this. The other problem I realized this morning was that, of the 2005 rooms I mapped yesterday, only 771 actually had room descriptions saved. The rest were blank. The mud I play (the forest's edge) actually has a very simple and consistent output for rooms. The room name comes first, on its own line, in a color not used anywhere else. Then comes the exits on the very next line with nothing else, in the format [Exits: north east]. Then there is always exactly one blank line, followed by the room description which is also always followed by a blank line. The room description is always one paragraph. Seems simple? The only thing missing is the actual vNum of the rooms in the room name line. This is, however, available with a separate command and I was able to successfully grab this and update the vNum in the map to match it by using the onRoomCreate event.

It strikes me when I search the forums for help and it is very common to find people who gave up without ever getting the mapper configured. I've not found anyone on my mud that uses it. Whenever I ask, people say they "never got it to work". And again, the output on this mud seems like it was designed with mapper auto-configuration in mind.... very simple and consistent.

This wasn't meant to be a rant... sorry. I'm just wondering if I'm wasting my time with this. Are there plans to improve and/or work the bugs out of the mapper and provide some documentation so people have a fighting chance? If this worked it would make an enormous difference in the game for me and my friends there.

Thanks again :)

Wizard Joined: 22 Mar 2007 Posts: 2320

If you use the mapper in SLOW mode, it will always wait for a #STEP command to execute the next step. If you were using #PAUSE to stop motion temporarily, that was your problem. PAUSE will confirm the last step but will abort all further motion, i.e. it will clear the movement queue. So don't use #PAUSE, just use #STEP when you are ready to take the next step.

Apprentice Joined: 18 Jan 2001 Posts: 116 Location: USA

That's not the behavior I was seeing. With auto-config and auto step confirmation...

#slow .5e

would move me 5 rooms east, one room at a time, but without any #STEP intervention on my part.

That seems to be what the help file would indicate, too:

#PAUSE
Pauses the current Slow Walk. Typically used in triggers. It confirms the last step, but aborts the slow walk in progress. Continue walking with the #STEP command.

#SLOW
Executes the specified path in Slow Walking mode. In this mode, a single direction is sent to the MUD, then CMUD waits for confirmation before sending the next direction. Directions are confirmed with the #OK command, and aborted with #STOP. If a Slow Walk was aborted, it can be resumed with the #STEP command.

The auto-confirmation for walking that is enabled by default using auto-config is sending #OK automatically each time I take a step in the path. I had to turn that off in order to pause, and that meant I had to issue all the #OK commands in my script... unless I'm totally lost (I know I am).

Thanks :)

Wizard Joined: 22 Mar 2007 Posts: 2320

That documentation you quote describes the #SLOW command as executing a path in Slow Walking mode, but the description of the effects is that of SAFE mode, not SLOW mode.

To use SLOW mode, go the mapper. Click on the SLOW mode there. Then execute your paths as normal paths (not using #SLOW). The difference between SAFE and SLOW mode is that SAFE mode automatically executes the next step after the #OK, but SLOW mode only executes the next step after a #STEP command.

The documentation you cite is out of date.

Apprentice Joined: 18 Jan 2001 Posts: 116 Location: USA

Thanks again for the help. I'll start over again tomorrow and go back to using auto-configure and try using normal paths (not with #SLOW) and see if I have more luck. This issue illustrates my point about documentation, though. It's hard for people to get a handle on how all this stuff works when the documentation is out of date. I updated my help files a couple of days ago, so the stuff I cited is current... and apparently out of date. :) It's also conceptually confusing that #SLOW walking behaves differently than slow-mode walking... at the very least this distinction should be made more clear (if not emphasized) in the help files.

Thanks again :)

Wizard Joined: 22 Mar 2007 Posts: 2320

The #SLOW command is an old relic from early Zmud, unchanged for compatibility reasons. Actually, only thing wrong with the documentation is a confusion in terminology. In the documentation, "slow walking" usually refers to SAFE mode rather than SLOW mode. I'm not sure, but perhaps this goes back to an early Zmud period when there was only Slow and Fast. At this point, it would be a pain to go through the documentation finding all the confusing references, but would certainly be worthwhile. You can help by adding comments to the online documentation any place where you see a problem. I'm not sure how to deal with the confusion of the #SLOW command actually using SAFE mode, though. Changing the behavior (and maybe making a #SAFE command) would break lots of existing scripts. Something to think about, though.

Apprentice Joined: 18 Jan 2001 Posts: 116 Location: USA

Thanks again for the clarification. I made a new configuration, used auto-configure, and things seemed to be working great and (almost) like you said they would. Regular walking with the mapper in slow mode sent each direction one at a time, but did not pause in each room. It did, however, pause in any room for which I'd selected "pause when speedwalking" in room options. This seemed to be an acceptable solution... until it stopped working. About 20 minutes into playing around with it, regular walking reverted the safe mode behavior. I verified that my config still said to use slow mode... and clicked safe mode and then went back to slow mode... yet nothing seems to get the behavior back like it should be. Now, if I type .eee then cmud sends 'e' 3x in a row without waiting for anything... and tracks the map as the mud catches up.

Any ideas on this? I will say that in playing with all this stuff I've encountered some violations where I needed to choose between continuing and exiting the application, and my settings file got messed up so I had to revert to a backup. Maybe something is corrupted?

Apprentice Joined: 18 Jan 2001 Posts: 116 Location: USA

The weirdness continues...

I have my map set to slow walking mode.

If I use the #WALK command to get to a room with a short name, then cmud sends one command at a time... slow walking like you'd expect.

If I use .3nw type of moves, then cmud sends them all at once and tracks updates on the map as the mud catches up... safe walking behavior.

Shouldn't these two methods of moving behave the same way? Any idea how to fix the "regular" walking so it uses the mode specified in the mapper?

Thanks :)

Wanderer Joined: 13 Aug 2011 Posts: 74