Speedwalk doesn't expandAlias?

All and any discussion and development of the Mudlet Mapper.
Post Reply
Nyyrazzilyss
Posts: 334
Joined: Thu Mar 05, 2015 2:53 am

Speedwalk doesn't expandAlias?

Post by Nyyrazzilyss »

I'm not sure if would call it a bug or not, however:

In both of the below functions,

function speedwalktimer(walklist, walkdelay)
function speedwalk(dirString, backwards, delay)

It executes the movement with a send command. not expandAlias. This means that while I can capture/pre-process movement with an alias ^[nsewud]$, the alias won't get called if I use the speedwalk function. I'll switch to my own code for the nearterm. Is that something that should be considered to be changed?

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

Re: Speedwalk doesn't expandAlias?

Post by SlySven »

Off the top of my head I'm not sure that is a Mudlet application issue, from what I remember of the code when a speedwalk is requested (by Lua command or from 2/3D mapper clicks) a specific user/package provided function/script is called {"doSpeedWalk" if my memory is correct} I am guessing you are using a package that provides the functions you list which are triggered from this...

Nyyrazzilyss
Posts: 334
Joined: Thu Mar 05, 2015 2:53 am

Re: Speedwalk doesn't expandAlias?

Post by Nyyrazzilyss »

The doSpeedWalk script is written by the user. The speedwalk function, on the other had, is provided by mudlet.

It's in /src/mudlet-lua/lua/Other.lua, around lines 410-452. I've copied it from the mudlet code into my own package, and changed it myself from send to expandAlias - One of the next things I need to start looking at is getting doors opened properly during speedwalks, which probably would have needed the same thing (expandAlias used).

It very much has the potential for recursion though - Enough that I shouldn't fork it back into the code?

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

Re: Speedwalk doesn't expandAlias?

Post by SlySven »

Ah, must confess I don't personally go delving much into the Lua stuff - my bad for not spotting it. :oops:
As such your modifications could go into the main Github repository - up to doing a Pull Request to it? I note now that that code seems useless for special exits and as someone, possibly you, pointed out: uses a different string for the non-XY plane normal exits ( "u", "d", "in", "out" ) than the Mudlet C++ codebase ( "up", "down", "in", "out" ) uses and puts into the lua global speedWalkDir table ... :roll:

If you have code that opens/closes/locks doors you might wish to include stuff with calls of the lua commands:
  • setExitDoor(<room Id, number>, <exit name, string - one of: "n","ne","e","se","s","sw","w","nw","up","down","in","out" or a lower-case ASCII special exit>, <door type, number - 0 =no door, 1 =open door, 2 =closed door 3 =locked door>)
  • getDoors(<room Id, number>)
to use the "door" symbols on the (2D) mapper as you go - though, as they are "shared" between all the user's of a MUD, you could only really indicate which doors can be opened freely ("open" - green colour); doors that need you to do something to open them ("closed" - orange) or doors that are unusable by your current character ("locked" - red). You could use the presence of the above type of door - at least the open and closed types - as part of a scripting system to look for stored door names in the room's user data store and to activate generic door opening code - and know not to try on locked doors.

The current code (3.0.0 previews at least) allows you to do this via lua scripts for all normal exits using the above exit direction "names" (and special exits if they only use lower case ASCII - I'm gonna have to fix THAT somehow) though the mapper does not (yet) show doors on any exit that is not a normal one on the XY-plane {or on stub-exits or ANY exit with a custom exit line} - I have plans/prototype code in that area but it ain't ready yet. On a two way route there is a door in each direction but current 2D mapper code draws them as coloured squares one on top of the other so if they are different (or only present in one direction) you can't tell visually.

One related consideration I'm pondering about - Special Exits! Currently they have a single string which is used when the built-in speedwalk/route finding code wants to use that route; it can contain a script as I understand it (there is something about prefixing the entry with the string "script: " - but I'm not sure how/if that is implemented.) It strikes me that really a user would want both a "name" - something that they could type at the keyboard to use a particular exit route and a "command", something, possibly different, to either send as plain text(s) or to execute as a local script whilst interacting with the MUD server. Effectively this would be an alias, but it would be specific to THAT room, more importantly it is the "name" that is used to refer/display the special exit but it is the "command" that gets used when interacting with the lua subsystem and the MUD server. From previous exposure to TinTin++ I know that that client uses this sort of system for ALL exits - it is just that "normal" ones have predefined "commands" that initially are identical to the "names" - though you can really get confused if you delete an exit's command completely {the exit "stops" working, or, in recovering from something like that you get things wrong and say put "e" in for the west exit and "w" for the east and then you go in completely the wrong direction.} :lol: Anyhow, I suspect that this would increase the functionality of Mudlet, but I wonder what others think :?:

Nyyrazzilyss
Posts: 334
Joined: Thu Mar 05, 2015 2:53 am

Re: Speedwalk doesn't expandAlias?

Post by Nyyrazzilyss »

While the mudlet package i'm using is 3.0-delta (Everything i'm writing to my package needs to work with a pre-compiled posted version of mudlet), I have forked and will try setting up a dev enviroment to run that version in parallel. Haven't had a huge amount of time to try setting it up, but I do have a couple quick questions in regards to it:

Are the instructions (windows 7) at http://wiki.mudlet.org/w/Compiling_Mudlet still accurate? It mentions Qt 5.3.1, is that version required? I have Qt 5.5 installed. Will I need to downgrade to 5.3.1?

I'm running Windows 10, not 7 - Instructions still the same?

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

Re: Speedwalk doesn't expandAlias?

Post by SlySven »

The Qt stuff should be OK - we now target Qt5 but I don't think we use anything specific to a particular 5.x version (there are some changes in the Qt libraries as 5.x has evolved but I can't think of anything that directly impacts on our usage - mind you I'm just gazing at the 3D mapper and that is using classes that are now described as obsolete but I don't feel up to writing code for OpenGL shaders just yet which I think we'll need to migrate away from OpenGl 1.x stuff...) :shock:

One thing that might cause some people grief is that we have started to use C++11 features which will need to have a fairly modern compiler to hand - though I'm using old-stable Debian Linux and haven't had any major issues so I guess current Linux packages for compilers are OK. Note that the instructions for Windows are for 32-bit builds - I'm not sure if anyone has got a Windows 64-bit build platform for Qt setup as Qt doesn't offer pre-build binaries for it's IDE. (If someone has managed to build the Qt libs and Creator{IDE}, using the minGW64 environment I love to hear from them...)

I personally haven't yet got Win10 in place - haven't booted into Win7 to check for the upgrade for a couple of weeks, but I don't see any obvious reasons why the instructions would be different - but I'm probably not the best informed to offer advice on that.

Post Reply