The repair command returned OK, but repair never happened.
-
I regained control of a room that I had lost due to controller downgrade timeout. After regaining the room there were several construction sites from when I had owned the room before.
Problems:
- A builder was able to build a 'constructed wall' at controller level 1 (from an old construction site).
- the builder then repaired the wall, which returned OK, but the repair never happened. This left the builder standing there until he died. (Yes, he had energy and was within range).
Possible Solutions:
- construction of a previously placed construction site should fail if the RCL isn't high enough?
- AND/OR, the repair command should at least return an ERR_CODE so that my creep can move on to a different task.
-
@just-j said in The repair command returned OK, but repair never happened.:
construction of a previously placed construction site should fail if the RCL isn't high enough?
Bad idea. We had this behavior some time ago and faced the exact same issue as you describe now, just for another method (
.build
instead of.repair
). But it was even worse because (unlike your case) checking structures availability based on controller's level is not a trivial task.AND/OR, the repair command should at least return an ERR_CODE so that my creep can move on to a different task.
No, it should not. The
OK
result doesn't mean that the operation has been executed successfully, what it does mean is that it has been scheduled successfully (which explicitly stated in the documentation). Players supposed to write their own target selection (filtering and selecting according to their own strategies), and the documentation contains a correct sample of it. Handling edge cases is something to be done by players, not instead of players.