Game.rooms only contains rooms visible to your code and a room is visible to your code if you have a creep or an owned structure in it (or ran observeRoom on it with an observer the previous tick).

So you'll need to add another check to your if statement to see if Game.rooms[newRoom] exists before using Game.rooms[newRoom].controller.

Additionally, some rooms don't have controllers so you should also check if the controller exists before using that too.

Construction site 'stomping' is standard behaviour.

"You can remove enemy construction sites by moving a creep on it." - Construction Site Documentation

I noticed you have towers that won't firing on the enemy creep. Are they an ally, or were you just ignoring it since it didn't have any attack parts?

If they're an ally, you may wish to ask them to first check if there's an allies construction site where they plan to move, or add it as an impassable position if they use a custom cost matrix with their path finding.

If you were just ignoring it because it had no attack parts, note that some player purposely program their creeps (especially scouts made from a single MOVE part) to 'stomp' enemy construction sites, so you should still be wary of them.

It is mentioned in the documentation, but only under the Creep section as an effect of the Claim body part in the body part table: "A creep with this body part will have a reduced life time of 600 ticks and cannot be renewed."

It should probably also be mentioned in the StructureSpawn.renewCreep section though, and return an appropriate error code.

@semperrabbit Yeah, they should probably make it a required field when making a topic.

You should probably add a topic title so people can just click it to get here.

I just noticed my code repeatedly failing to sell to an NPC order for O on Shard0 (Order ID: 59ff60f15846c661d592b6c8). When I took a look at the room the only objects there were a Power Bank and an Inter-Shard Portal, but no NPC Terminal.

It doesn't look like reset storms are happening every six hours like they did before Shard1 went live.

I only seem to have recorded one reset storm since Shard1 went live which happened from about 13:55 to 14:20 UTC on Aug 6.

I didn't record any of the standard 1000 CPU gains to my bucket during the period of this reset storm.

There may have been one or two other reset storms, but they didn't look quite right to be called as such from my graphs, plus they didn't refill my bucket either.

P.S. My data is just collected by my in-game script on Shard0.

From the API: "A fully upgraded level 8 controller can't be upgraded over 15 energy units per tick regardless of creeps abilities."

Since the game doesn't know how much energy you're putting into the controller yet when you run upgradeController, it just returns OK (if all the checks it actually can return errors for pass).

Only when your code has finished running for a given tick is it able to check how much energy you're trying to put in and caps it at 15.

I monitor when require.timestamp changes to keep track of how long it's been since my last code commit.

I found out about it when looking through the engine code recently. You can see where it's set here:

https://github.com/screeps/engine/blob/master/src/game/game.js#L484

I haven't seen it mentioned in these forums or on the Screeps Slack, so I don't think many people know about it.

I'd love to have Dissi's suggestion implemented though, since I don't know the actual commit number I'm up to.

While that PR does look necessary for constancy sake between what the client returns to the player code and what intent is actually registered, it doesn't doesn't address this problem.

The problem is coming from the sole reliance of C.OBSTACLE_OBJECT_TYPES to check for non-walkable objects in second part of the if statement (taken from here, although it also occurs here in a similar fashion):

if(_.contains(C.OBSTACLE_OBJECT_TYPES, target.structureType) &&
    (_.any(roomObjects, (i) => i.x == target.x && i.y == target.y && _.contains(C.OBSTACLE_OBJECT_TYPES, i.type)))) {
    return;
}

Earlier in Screeps development everything of a type listed in the C.OBSTACLE_OBJECT_TYPES constant was always non-walkable and thus an obstacle, but that's not true anymore.

Now you need an additional check to see if a creep (one of the types listed in C.OBSTACLE_OBJECT_TYPES) is walkable or not, because a creep can be walkable when it's a hostile creep in a room you've activated safe mode in.