Update to speedwalk()

Post Reply
chrio
Posts: 73
Joined: Mon Aug 22, 2016 11:34 am

Update to speedwalk()

Post by chrio »

I made some changes to the speedwalk function included with mudlet (3.0.0-delta) that others may find useful.

I noted that it had a problem with reversing counts greater than 9, so for example 14w gets reversed into 41e. Reversing the numbers again takes care of it.

Besides that I opted to use expandAlias() instead of send(). That way I can use an alias to detect my movement and move the map accordingly when speedwalking.

Code: Select all

walklist = {}
walkdelay = 0

function speedwalktimer()
   send(walklist[1])
   table.remove(walklist, 1)
   if #walklist>0 then
      tempTimer(walkdelay, [[speedwalktimer()]])
   end
end


function speedwalk(dirString, backwards, delay)
   local dirString   =   dirString:lower()
   walklist         =   {}
   walkdelay         =   delay
   local reversedir   =   {
                     n   = "s",
                     en   = "sw",
                     e   = "w",
                     es   = "nw",
                     s   = "n",
                     ws   = "ne",
                     w   = "e",
                     wn   = "se",
                     u   = "d",
                     d   = "u",
                     ni   = "out",
                     tuo = "in"
                     }

   if not backwards then
      for count, direction in string.gmatch(dirString, "([0-9]*)([neswudio][ewnu]?t?)") do      
           count = (count == "" and 1 or count)
          for i=1, count do
            if delay then walklist[#walklist+1] = direction 
            else expandAlias(direction)
            end
         end
      end
   else
      local returnpath=dirString:gsub("(%d+)", function(d) return d:reverse() end)
      for direction, count in string.gmatch(returnpath:reverse(), "(t?[ewnu]?[neswudio])([0-9]*)") do      
          count = (count == "" and 1 or count)
          for i=1, count do
            if delay then walklist[#walklist+1] = reversedir[direction]
            else expandAlias(reversedir[direction])
            end
         end
      end
   end

if walkdelay then speedwalktimer() end

end
original code on github / tests



This is my movement alias:

Code: Select all

^(n|ne|e|se|s|sw|w|nw|u|d|up|down|out|o|east|north|northeast|northwest|south|southeast|southwest|west)$
Which has the action:

Code: Select all

send(matches[2],false)
...together with whatever else I want to do with my movement command.


I hope that someone will find it useful.

/Chrio

User avatar
SlySven
Posts: 1022
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Update to speedwalk()

Post by SlySven »

How does this code handle a special exit - although of course the concept of a reverse path with special exits is questionable anyhow - or for that matter reversing when the exits are not bi-directional (i.e. they are one-way ones) or orthogonally reversible (i.e. the south exit from one room does not appear to enter the next room from the north, or rather the exit to get back to the first room is not the north one but, say the west one)...? ;)

chrio
Posts: 73
Joined: Mon Aug 22, 2016 11:34 am

Re: Update to speedwalk()

Post by chrio »

How does this code handle a special exit
It doesn't ;)

It is just a bugfix to the original speedwalk() already included with mudlet so it can handle reversing longer counts than 9.

For more complex routes I assume people will use the map functions instead.

User avatar
SlySven
Posts: 1022
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Update to speedwalk()

Post by SlySven »

Well actually if you look through that mentioned topic you may see that Vadi took the code and incorporated it into the lua code loaded by default for, at least some, MUDs. As it happens the users of other MUDs will have to write their own speedWalk() lua function.

For the record: recent developments in the code base has added a third global table speedWalkWeight which includes the exit weight of each step - and that has shown me that there are some, shall we say, imperfections in the route finding code. :(

Specifically, though it uses the A* algorithm, that only works well if the room placement in the area reflects actual physical proximity; also weighting is only partly effective in guiding the selected route - this is because the search routing bails and presents a result as soon as it finds a route whereas the code should really continue for either a user-tweakable time to find the best (lowest cost) so far route or it completely exhausts all the possibilities like Dijkstra's algorithm would (which is going to take more processing time, except on small maps, than the user would want). :ugeek:

chrio
Posts: 73
Joined: Mon Aug 22, 2016 11:34 am

Re: Update to speedwalk()

Post by chrio »

Not sure why you are giving me criticism here. All I wanted to do was share a small fix to a useful script included with mudlet. I didn't create the original script, and I don't claim that I did. I didn't have special exits in mind for it. Why should I when its outside the scope for the original script?
SlySven wrote:Well actually if you look through that mentioned topic you may see that Vadi took the code and incorporated it into the lua code loaded by default for, at least some, MUDs.
Ofcourse I saw that, that's why I linked to both the topic and the relevant code sections on github, since the script included with mudlet contains the bug I mentioned. My code is just that existsing script with some small changes applied to remove that bug.

Try it yourself:
lua speedwalk("14w", false) sends "w" 14 times
lua speedwalk("14w", true) sends "e" 41 times
SlySven wrote:For the record: recent developments in the code base has added a third global table speedWalkWeight which includes the exit weight...
Cool, but not relevant for this discussion. I'm not talking about doSpeedWalk() used by the mapper. Just the lua function speedwalk() that can expand simple directions like "14w,3n,5e" into a series of movement commands.

User avatar
SlySven
Posts: 1022
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Update to speedwalk()

Post by SlySven »

Sorry, no offence intended, and yes it does appear I got my wires crossed: :oops:

I see now that the lua doSpeedWalk() function is the one called by the Mudlet core when it is instructed to do so from: a lua call of gotoRoom( roomId ); a left double-click on a room in the 2D mapper or, currently a single left-click on a room in the 3D mapper. The 3k and mudlet-mapper modules included within the application contain code that also calls this. Closer inspection does indeed show that the Other.lua lua file bundled with the main codebase (what I work on) has the speedwalk(...) command you describe and I can see how it is useful to at least give multi-step moves to those MUDs that don't do it themselves (or maybe I'm recalling a feature of TinTin++ that I used to use that might have done something similar).

You spotted that there is another copy of this function in a luaGlobal.lua file, which is true - but that whole file should not be there - it is around 60-70KBytes in size and is located in the ./src directory and is an unused remnant from the past. In fact there is a different file in the ./src/mudlet-lua/lua directory of the same name and is only around 4.7KBytes - that IS used but does not contain the speedwalk(...) as of course it is in the Other.lua file. I have logged bug 1617504 to remind me to remove the offending file. It might also be worth creating a Pull-Request modifying the Other.lua file (or an Issue drawing attention to this topic) in the Mudlet-Lua repository because the lua stuff had been split-apart from the main Mudlet repository - mind you though the two sets of lua files have got slightly out of step :?

Nevertheless, thanks for bringing up this issue! :P

chrio
Posts: 73
Joined: Mon Aug 22, 2016 11:34 am

Re: Update to speedwalk()

Post by chrio »

SlySven wrote:Sorry, no offence intended, and yes it does appear I got my wires crossed: :oops:
SlySven wrote:Nevertheless, thanks for bringing up this issue! :P
No problem. I'm glad that we are on the same page again. :)

Post Reply