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

The problem is createCreep instantiates a creep on success. However, the creep doesn't have an id or an entry in runtimeData.

https://github.com/screeps/engine/blob/4af4cb81da0c796e39e15c4e488f1ba9768d1d8e/src/game/structures.js#L960

To avoid these errors the fake creep needs a fake id and an entry in runtimeData. Alternatively, we can just not create a fake creep during createCreep. I can't think of any use case requiring the fake Creep, you have to try hard to even find it.

I forget, did someone already confirm or rule out screeps profile MostlyHarmless and the associated steam profile, urhorn?

I don't have a problem that needs fixing, but I had a similar experience.

I had a graffiti that just did not want to transfer to steam: G-01090:MO:A. It would disappear from my inventory, but next time I refreshed the pixels page it would be back. I finally succeeded in transferring it a few days ago.

The 15 day hold is only for steamid not using steamguard for the last 7 days (at least that is how I read the hold notifications). So in about a week I should be able to trade on steam instantaneously.

Continual boosting has pretty tight margins. An example: saving a single CARRY part usually saves you 75 energy. But it costs 20 energy to boost. means you need to acquire 30 KH for less than the cost of 55 energy. Not impossible but tight.

Boosting your Mineral harvesters is usually a good investment, (unless you're mining Oxygen )

It think the math works out for PowerBank and Deposit farming since they're high value and require large creeps.

Otherwise most non-military boosting becomes a play to reduce intents buy being slightly less credit efficient. Which opens up a whole new layer calculations to play with (more remotes using boosts vs fewer efficient remotes, etc).