Mudlet

Bug #1263447
Comment #7

Comment 7 for bug 1263447

Revision history for this message

Stephen Lyons (slysven) wrote on 2015-07-18:

Investigating the provided file I find that ALL the rooms are in the -1 default area. The highest areaID used is 91 but all of them from 1 to 91 are empty.. This is not the problem.

It seems that the twp sample rooms and I think from some debug code that I added to test things that ALL the rooms are "Locked". Locked rooms are NOT put into the boost::graph data structure so they are not considered for speedwalks. The current code, although it checks for a usable exit from the starting room and bails out if there isn't one does NOT check that the DESTINATION room is unlocked.

The simple one line fix to prevent this crash is, in pseudo-diff form, in the TMap class file, at around line 836:

bool TMap::findPath( int from, int to )
{
      if( mMapGraphNeedsUpdate )
      {
         initGraph();
      }

TRoom * pFrom = mpRoomDB->getRoom( from );
TRoom * pTo = mpRoomDB->getRoom( to );

- if( !pFrom || !pTo )
+ if( !pFrom || !pTo || pTo->isLocked )
      {
          return false;
      }
... other stuff ...
}

We do need to revise the documentation slightly I think because I feel, in nit-picking, theoretic detail, it should be possible to start a route finding/speedwalk FROM a LOCKED room (a locked room is equivalent to an infinite room weighting but the room weighting is used as the cost TO ENTER a room, unless overridden by the weighting of the exit leading TO it) but in practice this would be quite tricky to code for because the room will not be included in the compiled BGL graph structure as stated above.

I will raise a PR and patch the above fix (and clean up a couple of other related locked room issue:)

* delete the unregistered TLuaInterpreter::isLockedRoom() function which is not available to users and is a duplicate of the TLuaInterpreter::lroomLocked() function that is made available!

* provide a mapper GUI context command "unlock" to reverse the "lock" command - so that a user can select a group of rooms and be able to unlock them for use in speedwalks as they can't do at the moment if they lock a wrong room.

Investigating the provided file I find that ALL the rooms are in the -1 default area.  The highest areaID used is 91 but all of them from 1 to 91 are empty..  This is not the problem.

It seems that the twp sample rooms and I think from some debug code that I added to test things that ALL the rooms are "Locked".  Locked rooms are NOT put into the boost::graph data structure so they are not considered for speedwalks.  The current code, although it checks for a usable exit from the starting room and bails out if there isn't one does NOT check that the DESTINATION room is unlocked.

The simple one line fix to prevent this crash is, in pseudo-diff form, in the TMap class file, at around line 836:

bool TMap::findPath( int from, int to )
 {
      if( mMapGraphNeedsUpdate )
      {
         initGraph();
      }
 
      TRoom * pFrom = mpRoomDB->getRoom( from );
      TRoom * pTo = mpRoomDB->getRoom( to );
 
-     if( !pFrom || !pTo )
+     if( !pFrom || !pTo || pTo->isLocked )
      {
          return false;
      }
... other stuff ...
 }

I will raise a PR and patch the above fix (and clean up a couple of other related locked room issue:)

* delete the unregistered TLuaInterpreter::isLockedRoom() function which is not available to users and is a duplicate of the TLuaInterpreter::lroomLocked() function that is made available!