setExit, setExitStub, queryRoomExits - fix inconsistency in direction parameters and returned names

[Garagoth]

setExit() accepts a number or a short direction name (like "e", "ne")
setExitStub() accepts a number as direction
getRoomExits() returns a long direction name (like "east", "north")
connectExitStub() is even more bizarre, it does not work with 2 arguments as stated in manual as well
setDoor() and getDoors() requires and returns direction in short form ("e", "ne")

Also writing scripts for non-english mud is painful as I have to maintain 3 name mappings just for directions... translating in one or another way.

speedwalk also outputs short directions and I have to translate them into correct ones (and why up and down was not shortened as well?).

Is it possible to make it consistent and more friendly? Make it all english short names for example or numbers everywhere (less friendly IMHO)?

Mudlet: 2.1

[Chris (chrismudlet)]

This has been changed so any variation of direction is now accepted for exit arguments (#,short,long names)

[Stephen Lyons (slysven)]

There is a bit of a dichotomy with the way that exit directions are treated but in the long term I think we may have to split exit directions into two groups, the "normal" exits which we can represent with a (short unsigned) numeric constant internally and "special" exits with a "string" representation. We then can allow the user to specify what they want Mudlet to send to the MUD server for those "normal" exits - which will pay dividends for internationalisation if we ever embrace it.

Coding the normal exits with numbers will make the code more compact and reliable as we can then loop through all the values rather than having to repeat code blocks once for each distinct direction. The cost is that various QMap elements in the TRoom class will be split into <int, ???> ones for normal exits and <QString, ???> for the special exits and some code will have to check both. During a migration though, any "normal" exit in existing map data/code that is not in the matching form for the defined value for that direction should end up in the "special" areas and not be lost so that the user can correct it.

[Vadim Peretokin (vperetokin)]

That sounds good.

[Stephen Lyons (slysven)]

Work in progress on the above, should also act on https://bugs.launchpad.net/mudlet/+bug/1097543

[Garagoth (garagoth)]

I see this is a must have for 3.0 release. I am testing my mapper script wrote for 2.1 on 3.0-iota.
Trouble that I have is with connectExitStub(). I am passing 3 arguments to it: roomId, second roomId, direction number.
All I get is error message: <connectExitStub: Need a direction number (or room id) as 2nd argument> and script execution is stopped.
I am sure that this works in 2.1 and all roomIds exist before calling this function.
Calling it with 2 arguments, both roomIds, also produces same error.
Calling it with roomId, direction# makes it stop complaining, but connects rooms on second invocation - first does nothing.

Regards,
Garagoth.

[Stephen Lyons (slysven)]

Looking at the code in TLuaInterpreter::connectExitStub(...) in the C++ code I see that it is supposed to exist in two forms:
A) connectExitStub( (number)fromRoomId, (number OR string)direction)
B) connectExitStub( (number)fromRoomId, (number) toRoomId, (number OR string)direction)

If the "direction" is a string (case ignored) with the following values it is considered as the given "normal" direction "code" number:
"n" or "north" ==> 1
"ne" or "northeast" ==> 2
"nw" or "northwest" ==> 3
"e" or "east" ==> 4
"w" or "west" ==> 5
"s" or "south" ==> 6
"se" or "southeast" ==> 7
"sw" or "southwest" ==> 8
"u" or "up" ==> 9
"d" or "down" ==> 10
"in" ==> 11
"out" ==> 12

Any other string is not parsed, and the matching number (as a number NOT a string) can be also be used for this function. Unfortunately the code that converts the strings to the number of the direction also checks that the number form, if used instead, is also in the range 1 to 12 else the conversion returns a 0 to indicate an invalid code. This would be all well and good, except that for the three argument version, the second argument (being the toRoomId number) goes through the same conversion which will break if the toRoomId is not in the range 1 to 12!

Furthermore the Wiki also claims that if you just give a fromRoomId and a toRoomId (both numbers) and "it'll smartly use the right direction to link in" - this is NOT TRUE and is not implementable as I see it. In this case, the second argument as a number will be checked to see if it is a direction code and a hunt for a suitable room in the given direction will be sought if it is. There is no 100% valid method to determine in the two argument case where the second argument is a number whether the number represents a direction code or a roomId...

At present the only working case is for the two argument case where the second argument is a direction string or number from the above listing. In the case where the toRoomId IS known the setExitCommand(...) with the same arguments (from, to, normal exit dir) does work to make the connection one way (and will remove the corresponding stub exit if there is one in the fromRoomId).

[Garagoth (garagoth)]

1. roomId, roomId - not working and not sure how it could guess direction (by coordinate difference?)
2. roomId, roomId, direction - not working (is working fine im 2.1)
3. roomId, direction - working, but first invocation does not connect anything. Second, same, does connect. Seems very unreliable... does it scan whole map in given direction?

For me it is regression. Any chance of fixing this or should I start rewriting code to use setExit() ?
Or, if 1 and 3 are impossible to implement properly anyway and setExit() removes stubs anyway, what is the reason for this function then?

[Stephen Lyons (slysven)]

Currently:

3. should work with direction as one of the given strings OR numbers (1 to 12).

2. not working due to a coding bug that treats the second roomId as a direction number (and only accepts value of 1 to 12) before even spotting that there are three rather than two arguments.

1. Can't work as I see it as it will be mistaken for 3 since we revised it since the 2.1 release to allow direction numbers (which will be more code friendly going forward to supporting more than just English language).

3. should work by detecting the *nearest* room in the *direction given* and making a *one* way exit from the first room to the second in that direction on the basis of the x,y,z coordinates of all the rooms considered (i.e. in the same area).

setExit() will effectively do what 2 tries to, but without the code in front of me this instant I am not sure whether 2. was to make a one-way exit or to do both-directions, whereas setExit() only makes a single exit direction link and will need to be invoked with the two room ids swapped and with the opposite direction for the second call.

The mention for removing stubs is that old code (possible back as far as 2.1 would allow both a stub and an actual exit in the same direction - this is logically inconsistent, so now you are not permitted to make a stub exit exist for a direction that there is a real exit in and making a real exit in a particular direction will automagically remove a corresponding stub exit. This consistency is now also checked for and if a problem is encountered during loading a Mudlet Map file then it is automatically cleaned up but noted in the errors.txt log file and also on-screen if that option is enabled...

[Vadim Peretokin (vperetokin)]

Migrating issues to Github, please follow the new discussion here: https://github.com/Mudlet/Mudlet/issues/545

This issue needs to be closed and there is no appropriate status, so will set it to "Opinion" just for migration purposes.