@arsdragonfly not like I can do something with the code you provided... well, I'll try to build the minimal reproduction code myself.

@atanner They're currently in development. We'll announce all the details when we're ready for it.

@lhocke how to reproduce it?

This post describes changes on the Public Test Realm.

• Added new method StructureLab.reverseReaction to "break down" boosts to their components (see discussion).

• Added new method Game.map.getRoomStatus to determine is the room located in Novice or Respawn Area (see discussion). This outdates Game.map.isRoomAvailable which is deprecated now. Game.map.isRoomProtected has been removed since it's been deprecated long time ago.

• Added UI option to hide the link to Steam profile (see discussion).

• Changed error codes of StructureNuker.launchNuke: now it returns ERR_INVALID_TARGET if either source room or target room is part of a Novice or Respawn Area

• Changed error codes of Room.createConstructionSite: now it returns ERR_NOT_OWNER if the room is owned or reserved by another player.

• Changed Creep.upgradeController so that controller level-up happens on the same tick when StructureController.ticksToDowngrade becomes full.

• Changed pathfinding default value of heuristicWeight from 1 to 1.2 for better performance. This affects PathFinder.search, Room.findPath, RoomPosition.findPathTo, Creep.moveTo, PowerCreep.moveTo.

• Room.name property is now immutable.

• Changed behavior or NPC invaders, now they shouldn't attack structures which are not on their way.

• Fixed some edge case inconsistencies in Store methods.

This update is deployed to ptr private server branch (version 4.1.0-beta.1) on both npm and Steam:

npm install screeps@ptr

@just-j we'll fix this tip, thanks.

5 CLAIM parts rule is no longer a thing, as well as attacking controllers with Creep.claimController. Currently, the only way to accelerate the downgrade process is Creep.attackController method. Both are documented, just like every method in the game API: https://docs.screeps.com/api/

@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.

@tgdgnu shouldn't happen again, please report if it will

@qzarstb the conclusion is that seasonal content is planned for development. More details will be announced separately when we're ready to disclose them.

@violet which shard and room?

This one?