Exit weight not being considered in pathfinding?

[tehngion]

I've been running into some problems getting setExitWeight to work.

Right now, there's a room on the map that has an exit west, as well as a special exit, both of which end up going to the same room. I want the pathfinding algorithm to effectively ignore the west exit and use only the special exit, and I figured setExitWeight would be the way to do this, but no matter how high I set the weights of either "w" or "west", it seems the pathfinder always chooses that even though the special exit is at the default weight of 0.

For kicks I even tried doing the opposite of what should work by putting "w" and "west" at 0 again and setting the special exit's command to be higher than that, and got the same result: the pathfinder always tried to go "w" instead of through the special exit.

I checked the getExitWeights() command after each change to confirm that the weight was actually changed, as well, and the weights were what they were supposed to be.

Not sure what's going on here, am I messing something up or are exit weights just kinda wonky?

This is in 3.0.0 delta.

[SlySven]

Remember that setting an exit weight to the "default" of 0 means "use the weight of the room" and that setting the "No route" or "Lock" option on an exit is the same as an an infinitely high exit weight. Nevertheless, this is something I would like to check and confirm to check for a problem...

In the example you are giving is it possible for the special exit to be any other command than "west" I wonder whether Mudlet is converting the command "west" as typed to the normal exit "w" in the same direction - it is a limitation in the current design that what a special exit is "called" is the same as what is sent to the MUD server to perform that exit.

That is okay for simple situations (e.g. "climb rope") but less helpful when you want a complex script that does something, waits for a response from the server and then does something else. I would like to see the same sort of arrangement that TinTin++ uses in that an exit has a "name", which is what you type to use that exit and a "command" which is what gets sent to the MUD server when it is used; this is the case for even "normal" exits, by default the "command" is the same as the "name" so the exit called "w" will just have the command "w" to start with but can be rewritten {or even deleted to really confuse someone else you share a map with when nothing happens when they type "w"!). This is effectively Aliaes but instead of filling up the Trigger Editor with such things they would be stored as part of the map.

[SlySven]

Oh dear - yes this is an issue I think in both current (2.1) and the current previews (up to delta). The boost AStart library finds the list of rooms that makes up the path but our subsequent code to work out what exits to use to move between those rooms fails to account for locks and weights when there is more than one exit from one room to the next - it just uses the first one it finds whether it is locked or more highly weighted than any of the others.

In most situations there won't be more than one exit from a particular room to the next one in the path (and the list of rooms produced DOES CONSIDER locks and weighting) so that this won't be an issue except in these corner cases...

I have a fix under test at the moment but have encountered an implementation detail that I'll need to clarify with other coders...

[Vadi]

Try locking the exit meanwhile?

[SlySven]

That won't work if there is an alternative exit to the SAME room that is NOT LOCKED: say you are in a room up a tower and there is a rope from a window and you can either "jump out" to get to the room at the base of the tower or "climb down rope" and the latter is better because you don't lose a load of health using it; even if you lock the "jump out", if that is the first exit that is found by the path assembling code, then it is the one that will be used - ouch!

EDIT: Ah, no, I was wrong in a detail - this only applies to normal exits: if they link to the next room that is required whether locked or with a worse weighting or not, they get used.

[SlySven]

And to further confound the OP: different bits of the data for exits are stored in different ways and some of those will cause particular issues for the particular case given here:

The code that access the data for normal exit room numbers is fairly safe, it uses a numeric code as a key to identify exit directions from north (being 1) to out (which is 12), under some cases special exits have an (un)lucky 13 value.

Information about doors is stored in a (per room) data structure that uses lower-case one or two letter initials for xy-Plane normal exits and "up", "down", "in" and "out" for the remainder or the raw special exit name - doors can be set on special exits but they and up, down, in and out doors don't (yet) show on the map.

Exit lock (no route) settings for Normal exits are stored in a (per room) data structure using the same numeric direction codes as the exit room numbers. However Special Exits have an abortion of a system (IMHO) that prefixes a '0' or '1' onto the beginning of the name (or script) that identifies whether it is locked or not.

Of course Special Exits themselves for a room are stored in a key-value structure in each room with the seemingly cart-before-the-horse setup of the exit room number as a (non-unique) key and the name/script as the value. The 0/1 prefix in the name is only used for this entity - it is taken off when considering other data items related to a Special Exit, like special exit weights and doors.

Custom Exit lines are stored in four (per room) structures that define points, line style, whether the line ends in an arrow and colour - these also use an initial for some / word for others "key" except that the key for non-Special Exits are in UPPER case.

Finally, Exit Weights have a system using the full, lower-cased, words for all normal exits.

All in all, the current exit direction "key"/"identifier" scheme across the related bits that make up room exits is a bit of a dog's dinner with some gotchas and ripe for straightening out though that will require a revisions to the map data format rendering maps so produced not work with current or other previous Mudlet versions.

tl;dr; for the case given: the normal "w" exit will search for an exit weight with "west" as its key, trouble is, the special exit will also be looking for the weight with it's name, which in, this case is also "west"...

[tehngion]

• Exits are on a numerical system 1-12, with 13+ being special exits (sometimes?)
• Exit locks use this same numerical system for normal exits but a completely different one for special exits
• Special exits are stored with the exit room being the key and the command being the value
• Some structures use lower case for special exits, some use upper case
• Special exit ends up using normal exit for its exit weight

Yep, you're right. I'm thoroughly confounded.

...Guess for now I'll have to figure out a workaround, sounds like a solution to this is a ways away.

[tehngion]

Ended up getting around it by implementing multi-command special exits and putting a special exit two rooms east of the target room as essentially "west; special command". Not ideal but it works.

Fingers crossed you figure out something for that stuff, that problem seems daunting to say the least.