@Orlet In my experience only destroying the last rampart in the room creates this graphical error, if there's still another rampart in the room the destroyed rampart disappears normally (though I haven't tested this with PWR_SHIELD).

PWR_SHIELD probably just makes the existing issue more visible.

So, having read most of what has been said about power creeps i have a few questions/comments (some may have been said before, but i feel needs reiterating or rephrasing).

Shards; How will we deal with power creeps in multi shard empires? Assuming, (as is most logical) that if we spawn a PC in one shard then we can't spawn it in another, will there be any way for us to determine this other than tracking ourselves, or will it just return OK when we try to spawn and not spawn?

Levelling; This has been talked about a bit in this forum, but I think there's a different way we need to think about this. The problem as I see it is if I want to create a PC that has lvl 5 in multiple useful, symbiotic, abilities then if there's one level that has both of these abilities then I simply cannot. The worst offender of this is OPERATE_EXTENSION and OPERATE_SPAWN where if I build one to lvl5 the best I can do for the other is lvl2. This levelling system restricts us in ways that prevent the most useful combinations and ways it doesn't prevent will quickly be found and become the most widely used. There are of course multiple ways of fixing this, but since you seem wedded to the current concept the only fix I can see is to add more levels beyond level 25 (for operator) and so if we don't use that ability we wanted at lvl 5 because another ability we wanted was on that level then we get another chance later to grab it.
Oh and while I'm on the topic; the idea that a "choose one of 3 powers per level" makes it a more streamlined experience is to completely misunderstand the player mindset, which is not "what can I do at this level?" but more "How do I get this ability to this level?" and "Is it better to just create another PC?"

ops; I second what Knightshade said about the name of this. I could get behind it if each of the PC classes use their own resource (e.g. ops for operator, execs for executor and ... coms? .. for commander), but if it's the same resource for each class, then please consider renaming this, something like "fuel" would be better (though not perfect).

How do opposing effects interact?; If I've got a tower that I've done a lvl5 OPERATE_TOWER on and someone else does a lvl5 OBSTRUCT_TOWER what's the net effect? Is it +50% -50% (additively stacked) i.e. back to normal, or is it multiplicatively stacked i.e. the tower would be 75% of it's normal effectiveness, or does one simply override the other? Same question for spawns.

hostile powers affected by ramparts; I know this has been mentioned and the response was "we're still deciding", but this is an important questioned that needs to be answered sooner rather than later. if OBSTRUCT_SPAWN, DRAIN_EXTENSION, OBSTRUCT_TOWER are blocked by ramparts then we'll be looking at the question "are these too week? can they be made better? Is it possible to balance these up to usefulness?" whereas if ramparts don't block these abilities then the questions will be "are these OP? can they be weakened? Is it possible to balance these down to not be game destroying?". OK, yes I'm exaggerating here, but my point is, it's really pointless to discuss these further until we have an answer to the rampart question.

Balancing; I know this is (as it should be) the last to be done, but I just want of point out some of the worst offenders in terms of balance. GENERATE_OPS; this has been pointed out already that the most effective way to mine ops is a farm of lvl1 PCs just generating. OPERATE_SPAWN; I think levels 2,3,4 of this feel good, but lvl1 is basically useless, and lvl5 is opaf. If we rewrite them as how much they increase spawner capacity you'll see why, as it's a 11/43/100/188/400% increase to spawner capacity, so lvl5 here is almost 40x more powerful than lvl1, obviously the numbers here need a serious rethink. OPERATE_EXTENSION; this has also been mentioned before, but, as is, there's basically no reason to use anything other than (multiple) lvl1 PCs for this, even though the second level is the same cost as a new lvl1. If I rephrase this as the number of times you can run the ability per 3k ticks it comes out as 12/15/20/30/60, so lvl2 gives an additional 3 uses per 3k ticks 1/4 as useful as lvl1 (p.s. I REALLY love this ability, it would just be a shame to have such a clear best way to use it).

This feature sounds quite interesting, the first (and most interesting imo) use I thought of for this, is for private servers with bots that would offer contracts when they come into contact with the player, as a 'quest'. Upon fulfilment the bot could then offer more contracts. Effectively creating a 'quest line'.

This would obviously require some degree of automation in creation/offering of contracts (though not in acceptance of contracts), and ideally the ability to add some text with the contract for the quest descriptions. (Note: I'm mostly think of individual, i.e. effectively single player, servers. But the concept could easily scale up for multiplayer private servers).

In terms of the contracts themselves, I see them most useful if the code simply checks the criteria for completing the contract. e.g. I might offer someone a contract that simply checks that a room has no owned structures in it, other than a controller. This is obviously a contract to destroy a room, but the contractor is free to achieve this any way they want (including bribing the current owner to respawn). But to my second point, there should be a mechanism for a contract to say "I'm done, contract completed" and award the player their credits immediately (or, more likely, next tick).

Third and final point, I was thinking of how I'd check if someone had destroyed a player with multiple rooms, one option would be require they have vision in every room I wanted taken out, but using some kind of memory would be nicer for the contractor. Would it be possible to have some kind of memory that was only modifiable by the contract code for the duration of the contract (perhaps, have an option to reserve a memory segment for a contract)?

Just my thoughts.