Meshing speedwalks in the queue

Posted by Handgimp on Sun 13 Jul 2003 06:53 PM — 5 posts, 17,776 views.

#0
When travelling between locations I'll often string speedwalk aliases together. For example, from one city to another one, and then from there to a different area. Since I key my speedwalks off the city center, there is necessarily some wasted motion. It would be nice if the speedwalk queue could strip out the unnecessary directions. For example, if one speedwalk ends 2e 8n, and the next one starts 7s e, then it could combine them into 2e n e. Would this be workable, or desirable behavior?

(edited necessary into necessarily, as intended)
Amended on Mon 14 Jul 2003 02:42 PM by Handgimp
USA #1
It *might* be doable but I can't say I see it as desirable behavior. There are ocassions when due to builder quirkiness or whatever, when 2e 8n 7s e doesn't end up in the same place as 2e n e. One way rooms, teleports, wierd builders, etc can all contribute to make this a bad idea to implement as a default feature.
Australia Forum Administrator #2
It's an interesting idea, the first time I have heard of it. :)

One potential problem - apart from quirky areas - is how to know the opposite of a direction. Currently speedwalks let you specify the inverse of any direction, except the standard ones (eg. N -> S, E -> W, up -> down).

At present MUSHclient only stores the forwards direction in the speedwalk queue, as it doesn't need the inverse direction for walking. However to merge speedwalks like you describe you would need to compare the "end" of each queue to see if the end of one was the inverse of the other, and if so, cancel them out.

Ways I can imagine are:

  1. Storing the speedwalk inverse directions in the speedwalk queue, and using that to work out whether to cancel one.
  2. Using reasonable defaults (eg. N -> S, NE -> SW and so on), stopping when it can't do it any more.
  3. Having user-configurable inverses (eg. for the world) - however I think this might be unncessarily complicated.


The problem with the first option is if you throw in some standard moves between speed walks - the inverse might not be known. I favour the second option myself.

Naturally you would have a world option as to whether or not it attempted to do this - as Meerclar says, you may not want to.
USA #3
Yes. I have taken some consideration of this myself, but short of a real mapper that works accurately and can 'know' with certainty where you are when you start... I have been a bit reluctant to design a script for my own use to handle the paths I have this way. To do so would require knowing that travelling 10 west 'in' a sub area is not the same as moving 10 west on the main map, etc. For a full mapper this would be merely an extension, trying to feed it into the client would require a way to store all walks to be used and maybe a special waypoint marker that tells it to jump from one path to the next. It isn't simple by any means.
Australia Forum Administrator #4
That wouldn't be such a big worry - for this idea to work you simply need to know that in a particular place (eg. a street) going west once can be undone by going east once. That would generally be true - not always, of course, because you have one-way exits.