I completely glossed over the multiple room exits from a single room. I'll fix it to rectify that.

I'm not sure that is needed. Mudlet pathfinding isn't going to be using this function anyhow - no need to slow it down with this extra data.

I think we have different ideas of why this would be useful. To me, if I wanted to use getAreaExits I want to know the source/exit information at minimal. It's also free information, to get the keys we already do the work to get the exit information.

I already use getAreaExits() and I'm just interested in the room IDs. If
the information is free and doesn't cost much, okay. It should be returned
in the same format as getRoomExits() in each key to be consistent (and thus
make scripting easier).

On Tue, Dec 16, 2014 at 8:35 AM, Chris Mitchell notifications@github.com
wrote:

I think we have different ideas of why this would be useful. To me, if I
wanted to use getAreaExits I want to know the source/exit information at
minimal. It's also free information, to get the keys we already do the work
to get the exit information.

—
Reply to this email directly or view it on GitHub
#225 (comment).

🐛 Um, Houston we have a problem - specifically with special exits which are now stored in the (TArea *)->exits.value().second as DIR_OTHER (direction number 13 !) - I may have neglected to account for multiple special exits that could lead from and to the same rooms {a corner case admittedly}, though, as special exits are, I think, statistically more likely to be out of area ones (wormholes, transports etc..) Anyhow, is an "other" direction value in the lua table going to be enough?

May I posit the requirement for a second lua command getAreaExitNames() where the 1st value is the translatable lower case full word, hyphenated if, required normal exit (DIR_NORTH to DIR_OUT) or the untouched special exit name (DIR_OTHER) though that will have to be deduced from extra C++ code in the TLuaInterpreter class method checking through the from-room's special exit data; the 2nd value being the to-room id?

For the backend, the fact it's other is sufficient. We don't care what the path is, only that there is one. For the actual table, we have <from <to, dir_type> >.

I don't think it's worth complicating it as well with a new function. We also have to address the issue that the structure is QMap<int, QPair<int, int> >.

An alternative that would not bring additional overhead is to change the mapping to:
QMap<int, QPair<int, QString> >. That would allow the table to return:
{123: {room_1: north, room_2: in, room_3: enter some wormhole}}

We don't use exits anywhere so it's not beyond making whatever we want.

Edited by SlySven: to escape the < so they show up!

This is getting complicated, scrap the exits idea and leave it to getRoomExits() to handle it properly. I just want the room IDs here and from there the user can pull what they need.

You are proposing:
getAreaExits -- for the ids,
getRoomExits -- to get all the exits from each of those rooms,
getRoomArea(or whatever it is) for each of those exits.

That's complicated and inefficient as can be.

On Wed, Dec 17, 2014 at 2:57 PM, Vadim Peretokin notifications@github.com
wrote:

This is getting complicated, scrap the exits idea and leave it to
getRoomExits() to handle it properly. I just want the room IDs here and
from there the user can pull what they need.

—
Reply to this email directly or view it on GitHub
#225 (comment).

I disagree, that's a clean, modular design that doesn't duplicate functionality of other functions and gives you the choice of getting data you want. I don't want the room exits and the room area when I use getAreaExits() for example.

The scope of the function is pretty clear, getAreaExits() - get me the area exits, trying to overlay a specific use case on it has gotten too messy, so I propose we scale it down to what the function actually needs to do. Small functions doing one job are the way to go.

You don't want the room area exits, I do. If you only want the rooms, you just use the table keys.

I don't find that argument to be very strong when you're designing an API.

roomid : direction won't work for the same reason that we had to introduce getSpecialExitsSwap(), the direction needs to be first for special exits in case there are multiple special exits between two rooms (and they're weighted differently / locked / etc as necessary).

Let me see if I've got it straight:

• Vadi: you want a function to return the rooms in an area that have one (or more) exits that leave the area - you are not interested in where those exits go to or the direction that is taken to use those exits.
• Chris: you want a function to return all the details of how to get out of the current area, the rooms in the area, what direction to go in and where the exit ends up.
• I think: that just returning the rooms that have at least one exit out of the area doesn't give enough information - the user of that data will still have to iterated through all the exits of the indicated room both normal and special, to get the exit rooms and then test each one to see if it is in the same area. Returning the exit direction and the exit room saves the user those steps but will not completely so because extra work for special exits will still need to be done by the user's scripts to actually work out which of a given rooms special exits gives the "other" exit value - but the user only has to check the special exits of such "from" rooms and they will already know the "to" room Id - they will just have to determine which "special" exit of the "from" room goes there...

I must confess the storing of special exits as (TRoom *)->(QMultiMap<int, QString>) other has always struck me as a bit cart before the horse, if it had been me I would have used the QString exit name as the key (which has to be unique) and the to-room as the value. Indeed I might even have restructured the whole thing to:

(TRoom *)->(QMap<QString, QPair<QString, int>)

where the key is the exit "name" or what the user wants to type to proceed via the given exit and value.second is the "to-room"; value.first, which by default would the text assigned to the key, would be editable to be the command or possible a lua script that would be used to actually use the exit. In fact all the exits could be stored in this manner and internationalized Mudlets could just have the "standard/normal" exit directions saved as specific unique values stored in a table that links the normal directions that Mudlet has with the MUD/language standards for them... 💡

Returning the room and exits doesn't solve it because you'd get exits that are not leading out of the area - if you were looking for distinct exits leading out you'd still need to iterate and see where they go. All that would currently do is save you the effort of typing in getRoomExits() but not any of the more difficult logic finding the exit(s) that lead out... I can see the return value being useful if it listed only exits leading out of the area (both normal and special).

@vadi2 The exits that actually lead out are the ones provided. Look at the getAreaExits code, if the two rooms are in separate areas, the exit linking those two rooms are added.

I think (TRoom *)->(QMap<int, QPair<QString, int>) is what should be done as well., not (TRoom *)->(QMap<QString, QPair<QString, int>), which makes the mapping:

QMap<from room, QPair<exit_name, exit_to> >

This maintains uniqueness of special exits and indexes the QMap by the room id we're interested in.

Edited by Slysven: escaped less-then characters with preceding back-slash.

Okay so swapping the exit to be the value will allow for multiple special exits in a room and I'd be happy with that. I didn't realise it was unique ones, didn't read the code carefully.

@Chris7 I think that #219 now includes everything that this would have provided. If you'd be willing to check that out {with a "lua getAreaExits(, true)" } you will have what you want I think - and leaving that second boolean out or set to false, will give the list of rooms that Vadim expected originally. If that gets the thumbs up then I suppose this one can be closed off without a merge.

Okay, closing this one as #219 has all functionality and that one should be tested and commented on.