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.

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.