Mudlet - Forum

I wasn't sure this was the right place for a feature request...but here goes:

I'm having on issue with my auto-mapper. I am hashing the rooms title and description and I use this hash to look up rooms whenever the player takes an exit they've never taken before. If I get a roomID I can connect to that room, otherwise I make a new room.

However, some rooms on the MUD are identical in title and description, which results in them having the same hash. So it is possible when taking an exit for the first time, getRoomIDbyHash() will return a roomID, but that won't actually be the room they've entered. Instead I need to create a new room. And that's fine; I've got some heuristics that identifies when this happens and adds a new room.

But once I do that I have a problem. Now I have two rooms with identical hashes. Mudlet overwrites the original hash entry with I call setRoomIDbyHash() on the new room, and now getRoomIDbyHash() will return just the newer roomID. Which brings me to my request:

Can getRoomIDbyHash(), or a new function called maybe getAllRoomIDsbyHash(), to return the array of roomIDs which setRoomIDbyHash() has been called with the same hash value?

With that change, I can iterate over all the maze rooms and figure out which (if any) are likely connection points when the player moves down a new path.

PS: Why does getExitStubs() return the roomID when there are no stubs, instead of nil? That caused some interesting grief .

Isn't the idea of hashing to get a single, unique result for a single hash, though? I'm just thinking that while this may not make sense in the general design of how this stuff is supposed to be used.

You'd also have to complicate it further: you'd also need some way of removing specific room IDs from this hash list as well.

@getExitStubs(): no idea, that doesn't make much sense. Thanks for the heads up.

I think the getRoomExitStubs() issue had been spotted and a fix wrangled - but I'm not sure where/when it did/will get into the code base. Not at my development machine right now but will up date here and on launchpad bugreport+1261536 when I find the fragment...

Ah, yes, the TLuaInterpreter::getRoomExitStubs(...) does have a fault - simple patch posted to above launchpad page. Hopefully will be pushed into next code revision...

Well, until I can convince MUD content writes not to make maze rooms, I'm afraid I'm going to get duplicate hashes . If purity of the concept of hashes is required, giving setRoomIDbyHash() a third "allowDuplicateHashes" parameter that defaults to false would mean only someone who explicitly wants duplicates would ever get them in the hash table.

So ideal implementation:

• setRoomIDbyHash(id, hash) gets a third parameter which allows multiple roomIDs to be stored with a single hash, defaults to off (current behaviour).
• getRoomIDbyHash(id) returns only a single roomID, the most recent if the hash resulted in multiple IDs, -1 if not found. Matches current behaviour.
• New function getAllRoomIDsbyHash(id) always returns a list of roomIDs if any are found, or -1 if not found.
• New function deleteRoomIDbyHash(id, hash) removes the roomID from the hash's list, deleting the hash if no IDs remain.

If it is something you'd consider, I'd be happy to code up changes.

It's both purity and backwards compatibility (we're big on the latter in Mudlet).

I imagine if a hash was created without the multiple room IDs flag, getAllRoomIDsbyHash will just return -1 or a table of list of one room, and deleteRoomIDbyHash will work just for the one room ID.

The design seems fine to me, and a fair bit of MUDs still don't transmit IDs to players so duplicate rooms with hashes is something that one is bound to run into often, so I support the idea. Lets have someone else comment on it as well.

I like this proposal and something very like it has been on my pile of things to examine when I get the chance, one additional thought I would ask about is whether we can allow for the user to define the hashing function - I'd done something similar for my pre-Mudlet hacking on a customised recent TinTin++ version and I wanted to make sure I could get the same hashes from either to allow the efficient and short transmission of near real-time location codes - room name + 4 Hex digit hash between at least those two clients in the sort of MUD where this environment exists. It probably wouldn't be an issue for me but end users might want that additional option...

(I also want to do a Mudlet MMCP (Mud Master Chat Protocol) stack for a related reason, though the current TinTin++ which appears to be the reference platform didn't support it over IPv6 the last time I checked so I wanted to fix that up as well...)

I'm currently using SHA2 on room name + description and even with bitops in pure Lua, I don't have any speed issues despite hashing every room I enter. Which reminds me, a reverse hash lookup getHashbyRoomID would be helpful in a few spots.

This request defeats the point of hashes. If you don't have unique features, don't use a hash. If you do have a way to figure out one room from the other, then you have something unique -- incorporate that into the string you pass to hash.

Hashes, by definition, are not guaranteed to be unique. Collisions happen. It appears that getRoomIDbyHash / setRoomIDbyHash were intended for use with unique values. That makes them function like unique keys rather than hashes. Which is where the request I made comes in. Give us at least the option to use them as hashes and deal with collisions ourselves.