Another way to view the API is there are no live game objects, only a snapshot of what internal game object looked like at the start of the tick.
This means using a stale object is totally a thing. A stale StructureController is nearly identical, a stale Creep however is much less forgiving.
The good news is Game.getObjectById is really really fast. So just store game ids and create an object for them when needed.
I love the long lived ruins left over from an abandoned room. It gives an archeology vibe. I'd like to see some even longer back. How cool would it be to find some ruins for Dissi or Atavus.
However, I totally understand about the need to clear ruins out of a claimed room.
How about an API to dismiss a Ruins that only works in claimed rooms. Like how remove() works for ConstructionSites.
The alpha map is worse for colorblind folks as well. On the current map I often can't tell player colors apart. Not a huge issue. The alpha map is worse as I can't tell if a room even has player activity.
I have multiple times thought one of Eiskalt's rooms got wiped. I could only see the roads. The player colors seem deterministic. I think it'd make the players easier to see (for everyone) if the saturation was bumped.
Sorry for breaking the regex thing. I was really hoping they'd keep the regexes and use RE2 to do it safely.
The actual implementation is done completely client side, so RE2 isn't an option.
I hope losing the regexes means we avoid a troll, as opposed to nerfing a feature because of a corner case that will likely never arise (looking at you Intel and Spectre). It would have been a great part of Screeps lore if someone used this offensively, though I could imagine a rage quit over a wipe and no way to view the effected rooms.
How would it cost to import all of a player's market history into BigQuery or RedShift? It'd be cool if the devs supported it directly, maybe charge and access token per year (6 months?).
Another aspect I hadn't considered. Resources all spawn based on ticks rather than time.
Sources:
This could never change. The regen time is too tightly integrated and optimized in creep builds.
Minerals:
Regen every 55 hours instead of 50K ticks. Player harvesting would be completely unimpacted, especially since they already have to adjust to different regen amounts. The sticky part is the ticksToRegeneration property, but I don't think a fuzzy value would break anything.
Deposits and PowerBanks:
From the player's point of view there is no change. It'd be a bit more work on the backend to convert from ticks to time.
It's all a little complicated and the result is not perfectly fair. I'd suggest it isn't worth it unless deliberately differing tick rates was going to be a feature of the shards.
The idea of CPU Unlock fairness brings up a good point. Shard0 is an obvious bad choice for players.
How about fairly refilling buckets based on time instead of ticks. E.g. every 4 seconds add a player's CPU level to their bucket. Now the Devs target tickrate means something in game.
This would balance the slow vs fast shards a bit. It would allow shard0 to deliberately remain slow, or possibly slower (does anyone want 8s ticks with ~double available cpu?). This might enable new play styles, without the disadvantage of losing 33% of your CPU Unlock. (E.g. a player on average would pay for Memory serialization less often on a slow shard).
This would also enable a FAST shard (1 tick/s) without making it cost tremendously more to run for the server. (Per player over head increases, but time executing players' code does not).
Best of all a change like this is nearly imperceptible to the players' bots. Any bot with enough CPU control to notice will also have enough cpu control to cope; it would appear that Memory serialization is taking more or less cpu.
My work around. Loop over all spawns, if they're spawning a creep next tick, hack the creep to disable the notifications. An alternative I considered is disabling notifications whenever a creep has 1499 ttl, but that has slight problems with regenerated creeps and claim creeps.
My point is not that we have a work around instead that my two options are kinda convoluted.
To Tigga's point.
I have twice (I forgot why I decided it was a bad idea) implemented Claim+downgrade instead of reserve for remote harvesting. It's a cool tradeoff (varied solutions, game breadth, etc). But the controller downgrade email spam was too much. There is no in game way to work around the problem. I suppose if I really cared I could craft an email filter to just delete the controller downgrade spam, but yuck.
@silentium_noxe Looping over Game.screeps after calling Spawn.createCreep and accessing any proprety defined here would cause that error. So even simple stuff like .hits would cause the error.
As for the code: nothing wrong with it, I do it all the time. I recommend running your spawning logic after your creep logic (this helps avoid running out of cpu as well, if you have too many creeps you run out of cpu before you can run your spawning logic, which will intern cause you to spawn fewer creeps).
You can also iterate over rooms then iterate over Room.find(FIND_MY_CREEPS), rather than all of your creeps all at once.
Finally if you want to iterate over creeps that are spawning. I personally iterate over my spawns and check the spawning property and access the Creep that way, since there a fewer Spawns than Creeps.
I'd prefer an extra parameter on the runReaction, StructureLab.runReaction(lab1, lab2, amount=5).
That way smaller amounts can be used while players are debugging / writing their lab code, and larger amounts can be used once they've got a handle on it and are ready to spend intents elsewhere.
Large cooldowns might allow players to come up with creative shuffling that'd be harder to pull off with short cooldowns. This might be a disadvantage (put all your labs in cooldown once a day then use them exclusively for boosting after that). It might also be an advantage in that it gives the players another area to optimized and experiment with different approaches (no single best solution).