Mudlet - Forum

As far as I know, there is no "map"—just a series of directions. But somehow Mudlet already knows the commands for n s e w ne se sw nw u d out and ent....but no others.


Here's the script:

pathing = pathing or{}
pathing.currentPath = pathing.currentPath or ""
pathing.currentNode = pathing.currentNode or 0
pathing.walks = pathing.walks or {}
pathing.walks.SAMPLEWALK = {
"w;n",
"3e",
}



Then, to start the path, I use

pathing.currentPath = matches[2]
pathing.currentNode = 1
speedwalk(pathing.walks[pathing.currentPath][pathing.currentNode])

This command actually starts the path: ^startPathing (\w+)$

OH... so you are basically just trying to use the speedwalk function to follow your own, custom defined paths? Well that is an entirely different beast. Sorry that I didn't actually read the rest of the thread before commenting. The short answer is that you would need to create your own version of the speedwalk function that would accept alternate directions, or other possible commands.

This is the actual code for the speedwalk function as it stands in Mudlet 3.0 alpha A slightly easier (though less flexible) approach, would be just to parse out directions using the string.split function. So, for example, you could make your list of directions like this: string.split(directions,"[,; ]"), and it would split up the string you give it using commas, semicolons, and/or spaces as separators between commands. Then you just need to get numbers in front of each to see if you need to repeat it. So, an example function could look like this: That should take any of your normal path sections and send all the required commands, and it would accept any command you put in there, including non-movement commands. It does require that you separate your directions in some way, and it doesn't provide a way to easily reverse the path you just took, but that is the downside of allowing for non-standard commands. If you need multi-word commands (like "enter house") then I recommend not allowing a space as a separator, obviously.

Thanks for such a detailed response! This is about 98% over my head. I'm using 2.1, and I looked around and couldn't find the speedwalk function you described. The built-in "speedwalking" script starts out "function mmp.gotoRoom(where, dashtype)" instead.

If you could break down more basically how to actually implement what you're suggesting (in 2.1) that would be super helpful. Thank you!

So, firstly, all of the code provided would work just fine in 2.1 (I don't even have 3.0, I just so happen to have written the revised version of the speedwalk function that is used in 3.0).

The function that I wrote as an example would be a step in the right direction. Basically, you would replace the speedwalk function calls that demonnic put in the code for the two aliases you are using (startPathing and cp).

So instead of: speedwalk(pathing.walks[pathing.currentPath][pathing.currentNode]) you would have: mywalk(pathing.walks[pathing.currentPath][pathing.currentNode])

What this would do, and how it works, is as follows:

1. You are select the set of directions you want to follow (this is already part of the alias code you have, from the first page of this thread).
2. You pass these directions, as a string, to a function which will separate them into individual commands, and send those commands (this is where the mywalk function comes in).
3. The mywalk function (or something similar) splits the incoming string into a table, using a delimiter, or a set of delimiters (in the example I included in this post, valid delimiters are commas, and semicolons).
4. The function then loops through the resulting table looking for a number at the very beginning of the entry. It does this using the string.match function, where it matches any number characters at the beginning, followed by anything else ("([0-9]*)(.*)" is the pattern for this).
5. If there is not a number, it uses "1" instead. (This is the: rep = rep == "" and 1 or rep)
6. The function sends the provided command a number of times matching the number it found. (You may want to gag this, if you have your client display commands you send, by using: send(cmd,false) instead of send(cmd), but I would recommend waiting until you know it is working as you want it to.)

mywalk function included with some changes and improvements: Does that help answer your questions?

OK, sorry for the slow reply—when I read this before it made no sense to me and I gave up. Just re-read it and was able to make it work! Now I can do any commend I need to. Thank you!!!!

Slightly an aside but if you write the first line of the stuff in that script box as a lua comment (starting with a "--") when things go wrong the error display will report the details of that comment as an identifier for where (in which item in all those boxes for each of the types: "scripts"; "timer"; "triggers"; "buttons"; "alias" or "keys" the error occurred... - Not so much of an issue if you only have one or two things but when it all "grows like topsy" as you get the hang of things it can make debugging a tiny bit easier!

To slightly confuse things I would also point out that when you double click on a room in the (2D) built-in map (or just click on a room in the 3D one) a path is worked out from the "current" room to the room so clicked upon and the details are store in the global variables speedWalkPath and speedWalkDir {and if you are working with the unreleased code in the main Git repository's development or release_30 branches, also speedWalkWeight} as a list of roomIds, exitDirections (including "Special" exits) and if you have it weight/cost of each step. Mudlet then calls a USER provided lua function called "doSpeedWalk()" - It is likely that the lua code that others are referred to is one of the two provided (as mudlet-mapper or 3k-mapper) that provides this function. Indeed, further delving suggests that it is the former (which you can find as ./src/mudlet-mapper.xml in the source code in the repositories) - superficial looking at that suggests that it is somewhat complicated as it supports some MUD specific features that you may not encounter - "dash" being one of them and relies only on features of the mature 2.x releases of Mudlet. Alternative implementations are possible and peering closely at the Other.lua file that is bundled with the application and which includes a speedWalk({string}dirString,{boolean}backward,{number}delay) function that does not process "Special" exits AFAICT suggests that improvements are possible.

Thanks, Slysven! The first paragraph made sense to me and the second did not.

I actually have done zero mapping since I've never figured out how it would work. It would be really cool to have a second window that shows the area and room I'm in but I don't even know how to start doing that.

That depends on what data A) the MUD server provides or B) what you can glean from what you or others have mapped. One useful trick if the MUD doesn't send out some "out-of-band" data (like GMCP or ATCP or MXP) which includes such useful information such as the current room name (or "VNUM" a.k.a. room number) and area - is to configure things (if you can) for the MUD to send out the Room Name and ideally Exits/Room Descriptions in different (unique) colours so you can write scripts that look for text in those particular colours in the right order and to parse what gets captured. This forms the basis of working out where you are and then by storing that as part of your map data you can then search for it in your map when you return to that room in the future...

Perhaps this, the opening part of the Manual might help.

I can't make the mud spit them out in a certain color, but here's what they appear as when I have room descriptions set to brief:

|
[X] | An alchemist's workroom
[1] | [1: s]


/[1] |
[X] | A cobbled road within a city
[ ]/ \[ ] | [3: se, sw, ne]

That said, the map DOES have some default colors—everything is white, except that the X is light blue and the line separating the map from the name/exits is green. Oh, and the numbers in the map part can be different colors depending on what kind of monster is in the adjacent room.

Ah, you get a "mini-map" automagically sent from the server. First thought is that: you might be able to capture the room name with a trigger that looks for "[X]" with potentially anything either side of it then a fixed "| " followed by a series of letters and spaces {a.k.a. words!} and that series is what you want to read as the room name - then this could switch on something similar to capture the exits. At this point I'd really like to hand over to someone who is adept at writing the "formulas" to put in the relevant places of the editor... is there anyone who would like to jump in and answer.