3. ERR_NO_PATH when creep moveTo flag in another room

ERR_NO_PATH when creep moveTo flag in another room


  • Sometimes, not always and not so often moveTo returns ERR_NO_PATH (-2) when target is flag, located in another room, while path actually exists and is quite short.

    For example I have this bug in rooms E13S9 and E13S8. Log messages with exact coordinates samples:

    moveTo [flag scouts] [room E13S8 pos 20,47] from [room E13S9 pos 32,8]: -2
moveTo [flag scouts] [room E13S8 pos 20,47] from [room E13S9 pos 36,12]: -2

    Some notes:

    1. CPU is about 50% (as usual) during bug.

    2. If in the same moment many creeps are moving to the same flag, some of them can receive ERR_NO_PATH, while other move successfully.


  • Did you ever find a solution to this? I am getting the same result.


  • By default moveTo considers other creeps to be impassable. So if your path goes thru a choke point it may not be able to find a path around the other creeps and return ERR_NO_PATH. There is an ignoreCreeps option but using this can lead to other problems if the blocking creep doesn't move out of the way.

    HTH


  • In this case, my creep exits my room and has an unobstructed path to the flag in the other room. It then turns around and returns to its home room, then turns around and returns to the flag room. Could be a bug in my code, but I found several unsolved cases like this on the interwebs. Too bad the sim is 1 room only. I guess my next step is testing on a local server.


  • I have had this problem in a few rooms and it has always been related to having some swamp in the way. The chance for it to happen increase with the amount of swamp in the room.

    I have assumed the path logic tries to find alternative routes to avoid the swamp. If it spends too much time on this it can finally give up. It doesn't need to be a lot of swamp. Just a few tiles thick. It is equally important that it takes the logic a lot of time to find alternate routes.

    My solution up til now has been to build roads across the swamps that has introduced the issue. The plan is to build more logic around movement that can handle the situation better.

    A quick test for you might be to temporarily move the flag closer to tile where the creep enters the room.


  • I also saw this misbehavior with swamps, when I was playing the game 8-10 months ago. I never managed to pin it down, but that was before the server was open source. I hope someone can solve this soon.


  • Okay. Shard1.

    var result = creep.moveTo(new RoomPosition(23, 48, 'E49N34'));

    That's about as simple as it gets. I am given -2 for the result every time. I see my creep popping between my room (to the south) and the target room (E49N34) repeatedly.

  • Culture

    Increase maxOps and see if it still happens.


  • So using this code, my creep will exit the room in which it was spawned, and then once it's in the other room get -2 for moveTo() and an empty array [] result from findPath. I've had a ticket open with support for a couple days. No reply yet though.

      var targetPos = new RoomPosition(23, 48,'E49N34');
  var result = creep.moveTo(targetPos);
  console.log(`Result of creep.moveTo(new RoomPosition(23, 48, 'E49N34')): ${result}`);
  if(result == -2) {
    const path = creep.room.findPath(creep.pos, targetPos, { maxOps: 10000 } );
    console.log(`Path result was: ${JSON.stringify(path)}`);
  }
    1 Reply

  • That is a little weird, I agree. Try to move the target position a few tiles into the room. Just 2-3 tiles. A few tiles of swamp shouldn't matter. I have also seen issues when the target position is too close to an exit and the creep must travel along the exit tiles to avoid swamp.

    I still think this is a coding challenge and not a technical thing that support can help us with.

    1 Reply
  • Dev Team

    I don't think it's an engine issue, but I'll try to reproduce the issue. Never experienced that myself tbh, so can't promise anything. If I found a reproducible bug in pathfinding, it will be queued for fixing.


  • I had a sort of the same problem, where a creep kept going back and forth on a border. In the room the creep wanted to be in the path it found went back out to the room the creep came from, and in the room it came from it got the ERR_NO_PATH. I'm pretty sure this was caused by swamp on the border between where the creep entered the room it wanted to be in and where i wanted it to go to in that room.

    I fixed it by building roads on the swamp. I didn't really understand why i got the ERR_NO_PATH error, so i could not think of a way to fix it in code, probably because i am still pretty new to Screeps and don't really understand how moving to other rooms goes. I assumed it was not a bug and me not understanding how pathfinding works (-:


  • @sandgrainone Thank you for the suggestion. I have tried many points within the room. Tried moving to a flag position and to several hardcoded positions.


  • @stillstate It looks like you've added the maxOps option on the call to findPath after moveTo has failed but you haven't actually increased the number of operations that moveTo can perform when it's looking for a path.

    What happens if you add the maxOps option to the call to moveTo?

    2 Replies

  • This post is deleted!

  • @hyramgraff Wow. Thank you! That did it.


  • I solved the issue with this code, and I hope it costs less CPU than the method using maxOps.

        if (creep.moveTo(pos) == ERR_NO_PATH) {
      if (this.pos.x <= 1) {
        if (this.move(RIGHT) == OK) {
          return
        }
      }
      if (this.pos.x >= 48) {
        if (this.move(LEFT) == OK) {
          return
        }
      }
      if (this.pos.y <= 1) {
        if (this.move(BOTTOM) == OK) {
          return
        }
      }
      if (this.pos.y >= 48) {
        if (this.move(TOP) == OK) {
          return
        }
      }
    }

    It seems like when a creep is not on the room border, the creep can find a path.