How are you detecting NCPs? If this works out it would be nice if others were set up, but I'd hate for a bug in the NCP detection to wipe out someone needlessly.

I did not find the UI nearly as confusing as SystemParadox, but I had played with the prototype quite a bit before.

I didn't notice the bars around the icon at first but effortlessly discovered it once I'd upgraded a power twice.

I was worried the dark red theme would be a color blind nightmare but I didn't have any problems.

I love the way the way the PowerCreeps change their coloring as they're upgraded. It might be cool to do something similar for the powers as well. Or maybe it would water down the effect. Either way I like it.

It did take me while to notice the locks on powers I can't enable yet. Curiously I immediately noticed them for powers I had enabled. I got on here to ask why the lock icons were not used for all blocked powers. Only then did I notice the grayed out lock icons on the higher level powers. I'd suggest making the locks more visible on the powers you don't have enabled yet. Maybe keep the locks uniformly red whether the power is enabled or not.

Putting the undo button next to the upgrade button was little nerve wracking. I wasn't comfortable with it until I'd gone through the upgrade flow (which is very pretty by the way).

I have a trick I particularly like. I track all creeps for stalls. When I detect a creep is no longer moving add that to my cost matrix with a weight of 50. Then my creeps naturally try to avoid stalled creeps. I use the same stall tracking to detect when a creep is stuck and repath.

I wanted to play with PowerCreeps on the PTR but the StructurePowerSpawn.createPowerCreep method is missing.

When defending in a siege renew vs respawn won't be a big difference. In either case if the PowerCreep or PowerSpawn is destroyed the defense is compromised. When a PC dies of old age it doesn't receive a cooldown.

Would it make sense to allow PCreeps to renew themselves via power they're carrying (consuming it)? This would allows a single operator to stay in or near the room for an entire siege.

I like the idea enabling some new anti-nuke strats.

A small change that might add a some flavor. Rather than have the nuke intent just kill the all the creeps outright. Have the nuke deal massive damage to all the creeps. Attenuate the damage like a tower starting at 15k to 5k (or whatever constants work best). That would still kill most creeps outright, but should allow for determined players to keep a few creeps alive.

This would pair well with @Davaned's proposal since the API would already introduce the idea that nukes are nearly always fatal.

If the dev's like the idea, I'd be happy to create the pull requests for the processor / constants changes. A dev would still need to update the docs.

Typo in the PTR docs.

Every shard can own raw...

should be

Every shard's own raw...

Also minor nit.

... its own segment, other shards' ...

probably should be:

.. its own segment; other shards' ...

However, no one would ever notice and it's still grammatically correct with a period.

Last item. Raw contents seems to imply something about the nature of the string used in the intershard memory. I assume that is not the case and shared memory is simply a string (no special utf encoding or value escaping). I think you should avoid the word segment to avoid confusion with the old api.

InterShardMemory.getLocal()
Returns the string contents of the current shard's memory.
.
InterShardMemory.setLocal(value)
Replace the contents of the current shard's memory with value.
.
InterShardMemory.getRemote(shard)
Returns the string contents of another shard's memory.

I'm a little unsure about using the word memory. It's a little better than just "data" but still too vague. Maybe instead of memory, InterShardMemory.

I think that was me. When I was exploring the ability to nuke arbitrarily far away I launched a few nukes against Objects before I got the hack correct.

I was also on the MMO server when I thought I was on PTR. I asked o4kapuk to clean up the errant nuke on MMO, but these might have been missed since they're through a different API.

Originally I thought that theme could just be a color because that would allows smooth transitions between them. But as I wrote my suggestion I switched from "color" to "theme".

I think themes might give the dev's (and maybe the community) more freedom to build some awesome themes. Rather just Red vs Blue you could use a Mechanical, Ice, Organic, Zerg, Tron, etc theme.

This also plays nice if (when?) the devs implement a hat economy. There could be some really nice reskins to give your creeps a unique look that also unlocked a theme you could use on your rooms. (I would shell out $20 for a good tron theme in my rooms in a heartbeat. Imagine if creeps popped into a pile of derezzed pixels when they died before their TTL. I might just start a war to watch my creeps die.).

I hadn't considered choosing the theme per room. I would also like non-controller rooms to match the dominant theme in the nearby rooms. Maybe skins/themes could be an account resource that you had buy N times. N themes to apply to N rooms, but you get them back if the controller declaims, unreserves, or changes themes.