Zugg Software :: View topic

Wanderer Joined: 31 Jan 2006 Posts: 55

Hello I have a difficult question I am having trouble with.

I used %walk(room) to get the path to a room using all nearest portal. These portals are in my aliases, which determine if I am high enough level to use them, and they are also designated on the mapper. zMud sends the commands like normal (n;w;s;s;e) to get to the room, and the path is shown in the %walk function like .nwsse

My mud uses a faster speedwalker with less lag built in, which is: "run nw2se". I would like to put what %walk(room) returns into "run" format. This was simple, to replace the period with 'run', but I also want it to work with my aliases and portals. Example, in this path that %walk returns, my alias is 'gar' which is a portal which transports me to a hub with closeby areas and then does the speedwalk. At the end, it does 'enter hole' to get into the area itself.
.(gar)s2wn4w;.(enter hole)

gar can be any alias with a portal in it that mapper decides will be quickest to get there. This I could handle by command like:
%word( %word( %walk( 8920), 1, %char( 41)), 2, %char( 40))
Which takes the word in first parentheses out. But my problem is, after that, I don't know where the next words in parentheses will be, or if there will be more than one. For example, it could be any of these:
.(gar)d2s;.(enter mandala)
.(gar)u2n7;.(enter tv);.(enter ferengi)3n4w

I need a way to 'catch all' of the things in parentheses automatically, without knowing where they will be, and replacing them, I would want to turn the above example into:
gar (alias)
run u2n7
enter tv
enter ferengi
run 3n4w

But also use the same script to turn the mandala one into:
gar
run d2s
enter mandala

I hope this made sense. I would much appreciate any help, I have tried many combinations but having troubule getting it perfect.

Posted: Tue Feb 21, 2006 2:41 pm

That's part of what I had explained to you in my email.
The portals in the map.
Set the portals on there and it will pick the portals as part of the shortest walk route.
Like how I told ya about my lotus portal.

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Fortunately, there is a function that does exactly what you need: %pathexpand.

Type the following into the command-line:

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Posted: Wed Feb 22, 2006 3:14 am

Comment: Actually 2 bugs:

runp .3n;aard;.9u

run 3n
aard
u
u
u
u
u
u
u
u
u

runp .3n6p;.aard
3n6p
aard

for this one, the run isn't issued because the p is not in the runnable var, but any commands after it are still issued.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Use %subchr to clean up anything %pathexpand missed.
#FORALL %subchr(%pathexpand(%-1),".;)(","") {

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Posted: Wed Feb 22, 2006 2:48 pm

Vijilante,
Did you mean like this?

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

It's just a typo. Use %subchar in place of %subchr and it should work (if you put the whole path inside curly braces - see my previous post).

Posted: Wed Feb 22, 2006 3:57 pm

ah, sorry, hadn't noticed the whole put curly braces around it part :-)

Posted: Wed Feb 22, 2006 7:09 pm

Hrmm... ran into 2 issues.
1) runp {.d3sws;.(open south;s)wd;.3wn}

run d3sws
open south
open south
s
run wd
w
w
w
n

Seems to break. I'm thinking it's something to do with auto opening of doors on the map.

2) My position on the map is not even moving under the runs. Like something as simple as:
runp {.d3sws}
will not move me on the map. but if i copy and paste the output on the screen, run d3sws, and i move right along.

from the end of the above:
runp {.(open south;s)wd}
will move me the one s on the map after the open south and again stop. The actual commands ARE shown on my screen, but the actual map moves dont seem to happen.
I stress MAP moving because I DO move on the mud.
I have a run alias that moves me on the map with the run command, but I don't think that's a part of the issue.

~run %1
#FORALL %pathexpand( "%1") {#MOVE %i}

(On second thought maybe the extra pathexpand might be the issue....)

Edit:
Made a slight change:

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Hrm...let's see if we can get to the bottom of this.

First, the reason that you're getting double-door-opens, etc. may be that your mapper is automatically issuing door-open commands along with directions AND your paths already contain a door-open command. So you get it twice. Once for the copy in your path, and again when the 's' is sent. FYI, You can configure the mapper to NOT include door commands in paths by unchecking the "Add door commands to saved paths" option under Speedwalking in the mapper config dialog.

Alternatively, if you've put in 'open door s;s' as the Other Command for that exit, you'll get the same doubling effect.

There is definitely some weirdness here with the use of Other Commands for exits. For example, consider the sample map from the Speedwalking Tutorial

Speedwalking Tutorial wrote:

If you are in room D and double-click on room G, you will see the commands "south", "open east", "east", "enter" sent to the MUD. Notice that the Door Script is sent, and that the custom direction command from room F to room G is sent.

With a default mapper config, if you type '.sen' when in room D, you'll get the same commands - the mapper inserts the special commands. Now the fun begins. After issuing the commands above, the path-behind shows as '.s;.(open east)e;.(enter)n', which is wrong - the final 'n' should not be there.

It gets worse. Check out the following (using the same map, where room 4 is D):
input:

Code:

#tel 4
#SAY Run 1
.sen
#tel 4
#say Run 2
#show %pathexpand(.sen)
#say Run 3
#show %exec(.sen)

output:

Code:

Run 1
s
open east
e
enter
Exits: e, n
>

Exits: s, w
>

Run 2
s|e|n
Run 3
s|e|n

Note that Run 1 has the right commands, but neither %pathexpand nor %exec (?!?) generates the same list. Sigh.

Your #MOVE commands bypass all of the speedwalking confirmations used by the Slow-Walk and Safe-Walk modes - it just assumes that you completed all the moves and sends the blue spot to the end of the run. On my MUD, the run command can abort if your char is attacked en route, and can fail outright if the number of moves is greater than your constitution. I have not found a satisfactory solution to this problem yet (though I've been experimenting with #queue) - any ideas would be appreciated.
The empty run commands stump me ATM. It should only be issuing runs when rpTempPath is non-empty. Try stripping out the %delete calls in those two lines (which should just be removing the leading '.') and see what's coming out of the %pathcompress call.

Posted: Thu Feb 23, 2006 1:13 am

as i said, the empty runs are with the speedwalk that *I* use.
The reason I merged mine and yours was to get RID of those empties.
My only question is this.
Why in yours does it issue a double open d;d when there is none in the path.
And why does it NOT issue a double open when I do the speed walk in 2 (or more parts)
YOUR version works fine as is.
MY version which takes the roomid converts it into a variable called path, then adds {} around that path variable.
the problem is with MY version not yours. (other than the breaking of the speeds as i'd pointed out before):
run d3sws
open south
open south
s
run wd
w
w
w
n
ETC ETC

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Ah...I can see that I need to read more closely. You did say the empty runs were in your version. Smile

Without having a copy of your map DB, I can't directly test the cases you're talking about, but let's see how close I can get.

First, I don't know WHY it's true, but I can say that the doubled 'open door' in your first example and the fact that it doesn't aggregate the last set of directions is related to what appears to be buggy behavior in %pathexpand. Look at the following three runs, all with the same logical path, but written differently:

Posted: Thu Feb 23, 2006 5:51 pm

SLAMMING!
Worked perfectly!!
Actually, I dont get the double open at all.
I don't get ANY of the doubles either. weird.
Funny thing thos is that the rpTempPath var is left with one d in it after my example sw. Not that it matters in the least cause it clears out again on a rerun.
Thanks so much for this. It's a small thing, but the fact that there were extra runs in my script bugged the hell outta me.