Bug Report: Creeps going to wrong room through creeps.moveTo



  • I was trying to introduce some remote harvesting as this issue occured: the creeps were going into a wrong room other than specified in the creep.moveTo function. I immediately thought this might have to do something with wrong indexing as the room is exactly one coordinate off the original target room.

    Another possibility could be that the creeps pathfinding led it onto the exit field because the neighboring room has a very thin connection leading along the room exit.

    • The creep was moving to a room different to what was given in the MoveTo function
    • happened on shard 3 room W54 S48, neighbor room W54 S59
     run: function(creep) {      
            
            if (creep.room.name != creep.memory.home) {
                if (creep.pos.x == 0 || creep.pos.x == 49 || creep.pos.y == 0 || creep.pos.y == 49) {
                    creep.moveTo(new RoomPosition(25, 25, creep.room.name));
                }
                var distantSources = creep.room.find(FIND_SOURCES);
                if (distantSources.length > 0) {
                    if(creep.harvest(distantSources[0]) == ERR_NOT_IN_RANGE) {
                        creep.moveTo(distantSources[0], {visualizePathStyle: {stroke: '#ffaa00'}});
                    }
                    else {
                        creep.drop(RESOURCE_ENERGY, creep.store.getUsedCapacity(RESOURCE_ENERGY));
                        creep.say('⛏️');
                    }
                }    
            }
            else {
                creep.moveTo(new RoomPosition(25, 25, creep.memory.roomId), {visualizePathStyle: {stroke: '#ffaa00'}});        
            }
    } 
    

    0_1706026144394_screeps01.JPG



  • As a tip: It is really easier to just moveTo the target position instead of doing special cases for different rooms and border positions. But you've done is what I've done as well. The problem arises near the border because the path sometimes moves one step to the border. But the creep would end up in the wrong room and the logic would repath to the sources in that room then.

    What helped to me as a workaround was to return if I end up in the wrong room by mistake. What's the best solution is to moveTo the target directly. What I didn't know at the beginning is: You can moveTo any RoomPosition, even from rooms which you do not have sight on. So I would just store the positions of the sources in Memory and then directly move to that position. It can be multiple rooms away and PathFinder will find a way. In complex rooms you might hit a limit, then you need to increase the ops in the options.

    You could also create your own CostMatrix to wall off the borders with the value 255. Then the path will never end up at the border tile.

    So the actual bug is that the path uses border tiles without being necessary. It can also be counted as inconvenience. If you move to the target source directly using a RoomPosition then this won't be an issue.



  • Found some more cases in which this issue arises. Again I made a screenshot. This time the way was blocked by a swamp, so the creep just decided to go to the next room instead of crossing the swamp, lol. It's really tedious watching something like this happen so frequently.

    0_1706317717393_screeps_swamp.JPG



  • That makes sense as there is another opening some tiles down. It routes to the next room and a few tiles down back again. If you keep moving to the same target position and stop changing the target depending on the current room, then this works fine. If you do not want that other rooms are taken into account, then add to the options maxRooms:1



  • So basically you are saying that the path rout via the other room has cheaper movement cost? It kind of looks like the creep is unable to make a decision where to move. Ironically it just stops in the other room and doesn't move anymore, not finding any correct route. In the second case the swamp movement cost hast to be blocking the creep movement. I will try maxRooms: 1 and see if it solves the problem. I also included the fix for the creep to go back to its target room when it enters an incorrect room. Maybe a pathfinding cost matrix could be of further help..



  • If the creep stops in the other room, then maybe you don't call moveTo to the same target position anymore.



  • Another tip on performance: Trying to move to the center of the room new RoomPosition(25,25,roomName) can lead to a very high cpu usage if there are walls at and around that position, because you can never reach that position so that the search is quite exhaustive to find a route. Better moveTo the target position directly. Also don't forget to add the range option to each goal that is in the wall (like controller, source) because of the same reason. For a source range:1 is enough.