strange pathfinding result?
-
made my first inter-room creep earlier, and it seemed to be working fine until it tried to cross one particular boundary, where it repeatedly got stuck. I kept adding debug prints, and eveything seemed to be correct, except the creep was promptly moving south and crossing the wrong border back to where it came from.
Sent a test creep back tot he room later and the same thing happened to it. So hopped in the console and tried this, which is what the creeps were trying to do:
Game.rooms['W4S1'].getPositionAt(21,48).findPathTo(0,39,{serialize:true})
This returns "21495" which, as I understand serialized paths, is the start position followed by "down." Just that, no more path. Tried with PathFinder enabled and disabled, same results either way. Is this some feature I don't understand, or a very strange bug in the pathfinder?
-
it is entirely possible that the optimal path actually *does* start by going south, then going back north through the 2nd exit on the west end of the two rooms, thus avoiding a big swamp in W4S1. I can't test this because once I cross back into W4S2, I can't see W4S1 anymore, and so can't call the room's getPosition. --- pre-submit-edit-- scratch that, by calling "new RoomPosition(...)" I can create a path to a room I can't see. Using that to test now if just repeatedly calling moveTo() with the target form that position works...
if so, guess this is a misunderstood feature rather than a bug, but I have to say it's highly unexpected behavior, at least for me. I would not expect, indeed, I would often not *want* a path from A to B within a room to involve leaving that room. I suppose I could prevent it by providing "maxRooms:1" with options... meh, anyway... yeah.
-
ok, scratch that last conclusion, after using the new roomposition trick to send my guy back to 21,48 and trying repeated "moveTo(new RoomPosition(0,39,"W4S1"))" the result is him going south one... then flipping back and forth seemingly indefinitely.