As I understand it cmd will be one of "n", "ne", "e", "se", "s", "sw", "w", "nw", "up", "down", "in", "out" for the Conventional exits or it could be the command text for a Special exit (without the prefixed "0" or "1" to indicate the SpecialExitLock state of that exit). doorStatus will be 1, 2 or 3 for a door symbol of type "open", "closed" or "locked" indicated on 2D maps with symbols of green, orange or red respectively, or, if 0 is give to the method the specific entry in the Map of QString keyed int values for that key is removed - thereby saving a few bytes for every exit that does NOT have a door - which in most cases will be most of them.
The reason I ask this is that I'm attempting to overhaul the room exits dialogue - which has some already noted flaws: including that the "Lock" buttons not only set the "don't use this exit for speedwalking / automatic route calculations" option as they are supposed to but ALSO DISABLE editing of the corresponding room ID that the exit goes to!
My revamp should make it possible to adjust the "Lock" status and exit to RoomID for the conventional twelve exits but also to set/reset the Exit weight (0=clear it so the room's weight is used, 1-9999), Set/Clear a stub exit on each of them and Set (to open/closed/locked) /Clear a door on them. Note however that the 2D mapper did not draw doors on up/down/in/out exits and messed up the drawing of both stub and normal exits for in/out ones the last time I checked.
Anyhow I hope this should provide a consistent GUI for manipulation of all aspects of room exits.In reference to the data encapsulation that is going on with the room data I found a slight issue with the exit weight item. Unless the dlgRoomExit code can be made a friend of the TRoom code it is not possible to determine whether the weight that one determines for an exit has come from an explicit setting for that exit or has come from the default set for the room - in most situations this is not an issue, the only exception is if one is trying to edit the data for that exit. For that case, not wishing to mess about with "friend" functions I needed to put in an extra method into TRoom.cpp (with a declaration in the header file obviously). Also, I had to tweak the code that sets the exit weight because the current code does not allow an entry to be REMOVED, only for it to be zeroed so that the weighting on that exit reverts to the default value set for the room as a whole - the tweak removes the specific data item if the method is called with a zero exit weight - thus it changes an exit back to how it was before a weighting was added - and saves a couple of bytes for each UN-weighted exit in the process:
Code: Select all
int TRoom::getExitWeight( QString cmd )
{
if( exitWeights.contains( cmd ) )
{
return exitWeights[cmd];
}
else
return weight; // NOTE: if no exit weight has been set: exit weight = room weight
}
++bool TRoom::hasExitWeight( QString cmd )
++{
++ if ( exitWeights.contains( cmd ) )
++ return true;
++ else
++ return false; // NOTE: needed so dialogRoomExit() can tell if an exit weight has been set now that they are private!
++}
++
void TRoom::setWeight( int w )
{
if( w < 1 ) w = 1;
weight = w;
}
void TRoom::setExitWeight(QString cmd, int w)
{
++ if ( w > 0 )
-- exitWeights[cmd] = w;
++ exitWeights[cmd] = w;
++ else if ( exitWeights.contains(cmd) && w == 0 )
++ exitWeights.remove(cmd);
if( mpRoomDB )
mpRoomDB->mpMap->mMapGraphNeedsUpdate = true;
}