I like this idea. There's something to fight over in unowned rooms with this - you can't just retreat and recycle the creeps and wait for me to go away; if you do that, you'll lose a structure that cost a lot of CPU and energy to build.
Burning ops is neat too - give another use besides PCs for that resource.
@wtfrank This is now fixed in the latest screepsmod-mongo build, I just deployed it to both S+ servers and confirmed it working 
As vipo said, proper inheritance has made my life easier when using the same kotlin screeps interface he mentioned. Shouldn't be a surprise to anyone that proper code structuring is a great help in many factors such as readability and reducing code duplication. However due to the nature of Javascript, as opposed to for for example kotlin since that's the example already used by Vipo, I understand it may not be as straightforward so I also understand knightshade's position. In short, I believe that if it is properly implemented it can be a great addition.
I'm very happy about this change. It brings information into the game that was previously only in the UI. Even scanning the market and keeping history data yourself couldn't tell you volume and price paid.
There's also still value in scanning and keeping some of your own history, though, so anyone who already has that code isn't sad to have it.
Also, I'm looking forward to getting the million credits or so back for my legendary energy order on shard0.
As both a mod developer and player I'm exited about this update, for modding, it was always annoying not being able to iterate over resources in a simple way. As a player, the entire store/carry/energyCapacity/carryCapacity mess was annoying, in some cases, I actually wrapped all those to make them match, very similar to how this is designed. It might seem a bit more clunky for stuff with only one resource, but simplifies more than enough other code to make it worth it.
For those wanting to keep energy/energyCapacity, they can easily do a simple prototype extension in their code. Object.defineProperty(StructureExtension.prototype, 'energy', { get() { return this.store.energy } })
Object.defineProperty(StructureExtension.prototype, 'energyCapacity', { get() { return this.store.capacity } })
This doesn't seem like something that should be allowed.
I don't think that makes much sense. Efficiency is one of the main reasons to upgrade those skills.
I do agree with the REGEN_MINERAL though, it shouldn't be inactive while the mineral is on cooldown.
It appears that if another player's power creep is "visible" to your game instance, it's being added to Game.powerCreeps. The sporadic nature is coming from my observers passively scanning the map...
I don't think other's power creeps should be in my Game.powerCreeps list.
I added a check to set .memory if it wasn't set and I get this interesting error as a result:
Power Creep Processing error Could not set other player's creep memory Error: Could not set other player's creep memory
at Object.set (:40507:23)
at Object.processPowerCreeps (main:12431:18) <-- only part of this that is my code
at Object.module.exports.loop (main:12935:8) <-- only part of this that is my code
at __module (__mainLoop:1:52)
at __mainLoop:2:3
at Object.exports.evalCode (:15990:76)
at Object.exports.run (:30481:24)
at global._init.global._start (:29710:22)Randomly, some of my power creeps will lose access to their .memory shortcut point to Memory.powerCreeps[name] and I'll receive errors saying "powercreep.memory is undefined." This is not every tick and when it happens it does not affect every power creep.