3. Bug/Feature? Incomplete error codes for the `creep.move()` and related methods.

Bug/Feature? Incomplete error codes for the `creep.move()` and related methods.


  • I've come across this problem while making a deep dive into handling the paths my creeps follow when issued creep.move() or creep.moveTo(reusePath: x) (while the creep has a memorized path).

    From what I can gather from the API reference guide and small tests I did in simulation mode creep.move() does NOT RETURN A PROPER ERROR CODE when the creep tries to move to a tile/position that is occupied and thus blocked. It actually returns OK which is totally misleading. Shouldn't one expect successful execution of an operation when OK is returned? I assume the same holds for creep.moveTo() by association and it also explains why in my tests my creeps would "wait" the reusePath amount of ticks before trying to re-path again.

    In short there is no error code that alerts when move() failed due to the destination tile being blocked. Can a request be made to introduce an additional error code into the game/API: ERR_BLOCKED (or something in that ballpark?). It's the only way I can think of to complete the error alerts for these movement methods. None of the existing error codes make any sense for this since they already alert to other errors.

    Given the age of the game and how frequent the move methods are used by all players I'm lead to wonder whether this was intentionally left incomplete. Does anyone have an explanation or response about the matter? Any feedback is appreciated.


  • This isn't a bug - when you issue an intent, such as creep.moveTo(), you're telling the server you want the creep to move this tick, and the server makes sure it's legal, and if so, returns OK. That doesn't mean that action will 100% take place though. Blocked creeps is one example, another is if you have two creeps try to withdraw from a container that only has 100 energy. Both creeps try to withdraw, both get OKs, but only one will get the energy.

    The reason is that all intents are executed simultaneously (with tiebreaks), and so it's impossible for the server to know at the time you issue that intent if that action will actually not be doable - i.e. withdrawing from an empty container or moving to a blocked space. In other words, the position you tried to move to may be occupied by a creep this tick, but it could move or die in the next tick and allow your creep to move successfully. On the other hand, you may try to move to an empty position, but a different creep moves there first and still blocks the move even though it was to an open position when you issued the intent.

    Hope this clears it up. As an fyi there's generally a lot more discussion on Discord than these forums - you could get an answer in #worldhelp a lot quicker than you'll get a response here most likely.


  • Many thanks for the reply. Indeed, your explanation has cleared up the matter in my mind. I see now that my assumption on why the error codes are returned was incorrect. I did not even consider that it indicates the legality of an action rather than its successful execution.

    Also thanks for directing me to discord. I did join the server and had a look around. Although the discord server has a lot more traffic I still prefer to post topics similar to this on the forum. The way I see it: discord for social chatting, forum for (more formal) organized thought and discussion.