Zugg Software :: View topic

Newbie Joined: 28 Feb 2004 Posts: 2 Location: USA

I'm a long time (9+ yrs) tintin++ user who is thinking of switching over to zMUD. However, the one thing I can not get my fingers to do is to prepend a . ahead of my speedwalking dirs.

I know it's a little thing, but it would certainly help make my decision easier.

Is there a reasonable way to force zMUD to allow me to do speedwalking dirs without a prepended .?

Obviously it's rather simple to build a RegEx that matches a speedwalking route, but I just don't know zMUD well enough to know the best way of going about doing it. I'd be willing to write any type of object (COM, script, etc) to help me with this problem, but again, I'm still on the bubble on whether to switch at all, so the easier the solution, the more likely I am to adopt zMUD.

Thank you

GURU Joined: 10 Oct 2000 Posts: 4379 Location: USA

No, zMUD needs something to know that you want to execute a speedwalk and not just send it to the MUD. It could be done, like you said with a RegEx trigger that fires on your input. If you have such a pattern that recognizes a speedwalk string, then you can put it in the pattern of an #ONINPUT trigger and just #SUB it with .%1

GURU Joined: 28 Sep 2000 Posts: 434 Location: USA

Using an #ONINPUT trigger, you could do something like this:

#ONINPUT {^(?<!.)[dneswud]+$} {#IF (%numitems(%pathexpand(%0))>1) {#GAG;#FORALL %pathexpand(%0) {#SEND {%i};#SHOW %i}}} "" {regex}

Fortunately for us, %pathexpand is intelligent enough to know when something is not a path.

EDIT: There are still some problems with this. For example, if your MUD has a news command, then... that would be the same as .news

GURU Joined: 28 Sep 2000 Posts: 434 Location: USA

quote:
Originally posted by Kjata
If you have such a pattern that recognizes a speedwalk string, then you can put it in the pattern of an #ONINPUT trigger and just #SUB it with .%1

Actually, I don't believe that would work either (didn't really try it, just assumed it wouldn't), because the .path would be sent to the MUD without expanding it.

Newbie Joined: 28 Feb 2004 Posts: 2 Location: USA

That seems to work quite well, thank you. If I had realized that there was an #ONINPUT I would have been on the right track. However, I noticed an issue with %pathexpand(). Admittedly this goes into the "why would anybody do that?" column of bugs, but if you have a speedpath that has a 1 in front of a direction, %pathexpand() expands that out to 2 dirs. So if you have 2n1ess it expands out to:
nneess

Nothing I'm concerned about of course, it isn't an issue with 11, or 21, or etc, just with 1. Certainly not something I'm going to make my own %pathexpand() function to fix :-).

Thanks for the help.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

That is quite funny. It is one of those bugs that no one ever thought to test out during the beta that introduced %pathexpand. Having been a programmer for about 20 years I know exactly how that happens too.