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). -- You received this bug notification because you are a member of Mudlet Makers, which is subscribed to Mudlet. https://bugs.launchpad.net/bugs/1114594 Title: setExit, setExitStub, queryRoomExits - fix inconsistency in direction parameters and returned names Status in Mudlet: In Progress Bug description: 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 To manage notifications about this bug go to: https://bugs.launchpad.net/mudlet/+bug/1114594/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~mudlet-makers Post to : mudlet-makers@lists.launchpad.net Unsubscribe : https://launchpad.net/~mudlet-makers More help : https://help.launchpad.net/ListHelp
