I re-enabled PWR_REGEN_SOURCE on PTR and it's working now.

On PTR I've encountered this same issue: TypeError: Cannot Read property 'ops' of undefined. In my case the PowerCreep was empty and trying to use PWR_REGEN_SOURCE.

A much better tactic is to only delete order when you're near the 50 (soon to be 300) order limit and then only 10 or so. This give you maximum opportunity to reuse / extend orders to limit losses due to market fees

I'm glad that worked. Now I'm a little confused. Is it supposed to be possible to give your scripts some runtime CPU by opening the room? E.g. could I migrate through a shard by keeping a tab open on the portal room?

I've changed my mind I don't think container up sizing is worth the disruption. However, double the number of containers might allow for some new and interesting solutions, especially in SK rooms.

10 remote containers cost 5 energy per tick to upkeep, but allows for more CPU efficient hauling. I think that is an interesting tradeoff.

Currently you need 8 sources in range to feed a T3 boosted 40 CARRY. Double the number of containers means you could feed it with 4 single source rooms where each source has 8 containers. Running the hauler less often is easier but efficiently mining out a source into 8 containers as worthy trade off.

Caravans have two problems. One is buffering between trips. But I find the second to be a bigger issue. Caravans don't offer any advantages over 5 single haulers. If we tweaked the pulling mechanic to allow for single intent caravan movement that would give me a reason to use caravans.

The devs should be free to change constants.

However, it should be done carefully. Constants that have never changed have a tendency to become assumptions elsewhere in code. Imagine a creep maintaining a container, it's sized for CONTAINER_CAPACITY/2 => 20 CARRY. Suddenly the constant is 4x larger now the creep needs to be 80 CARRY and stops spawning.

I think we may want to create an official reverse shim before moving the .store to MMO.

I had focused on whether the new .store would be backward compatible with the old plain Object. As far as I can tell that is the case. However, I discovered another failure that I fear might be quite common. In my case I was using something like if(!!struct.store) to change creep behavior when distributing energy among my structures. The new .store property didn't break my code (no errors) but my creeps stopped filling extensions.

I worry that other players will get frustrated if they run into a similar issue. If we had an official snippet that might help a frustrated player quickly avoid the change to see if their problem goes away (prove to themselves that it's not the new .store at fault).

I'm imagining something like mirroring .store to .cargo and removing .store from the structures that didn't have it previously. If .cargo is the wrong color of bikeshed it's an easy find replace in the snippet to pick a new one.

Also the new name makes a clear verification path. Change all of your code to use .cargo instead of .store fixing it along the way. Once you no longer refer to .store anywhere remove the shim and Replace s/\.cargo/.store/g.

if(globals.Store) {
  for (klass of [StructureExtension, StructureStorage ...]) {
    Object.setProperty(
      klass.prototype,
      'cargo',
      Object.getOwnPropertyDescriptor(klass.prototype, 'store');
  }
  for (klass of [StructureExtension, ...]) {
    delete klass.prototype.store;
    Object.setProperty(
      klass.prototype,
      'energy',
      { get() { return this.cargo? this.cargo.energy: 0; } }
    )
  }
}

// also clean up non-energy properties in StructurePowerSpawn, StructureLab, and StructureNuker

I like this idea, but its a big deal to change a constant, inevitably someones code will break. I'd be interested if the devs could apply the change to a single shard to try it out first. PTR in theory solves this problem but PTR is sufficiently weird that most players don't use it. My first thought was to target shard3 as the only customized shard but I get the impression that most new players start there, so we should take efforts to give new blood a stable (most fun?) experience.

So rollout something like PTR, ShardX, All.

@Atanner Does anyone use boosts for ongoing tasks? Every time I run the numbers it's clear I'm better off without boosts. Always credit wise, usually intent wise, it only saves spawn time. My only ongoing boost activity is RCL8 controller upgrading.

I agree with @Davaned something would be good, defending a structure without rampart and towers is something that doesn't really exist yet in screeps.

I don't think belts are a good idea (It just trade player intent cost for equally high processor cost). It might be possible to do it efficiently with a pipes where you can't see the resources in transit.

Simplest would be some sort of remote Link.

Another idea would be 10k capacity tesseract structures that are expensive to build but can be built at any RCL. (limit the tesseracts so they only share storage with other tesseracts in the same room).

Remember that the server's goal is to maximize cool-stuff/core not minimize cores/player(1).

Highly efficient code bases have some of cool-stuff tricks. Since they consume less cores they have a great cool-stuff/core ratio. A rebate that encouraged more cool-stuff has a similarly high ratio. I don't think credits as a rebate for CPU would improve the over all cool-stuff/core ratio. Players would mostly just do less or cash in on the otherwise unused CPU and create a new credit source (bad).

Selling bucket has the potential for lots of cool-stuff. First order: active bucket market place, selling a unique resource, anchoring credit value, new credit sink. Second order: Players building 300+ cpu empires, new bucket intensive tactics, creative space for players to create cool-stuff that would be restricted by 10k bucket.

So how much cores does the new cool-stuff cost? A bit. Every core spent here is new cost, as opposed to shifting cost from some other activity. This is slightly offset by the economy effect of giving credits to players who need it to do more cool-stuff.

Subjectively, this seems like a high cost, possibly high reward feature. I've heard rumblings from other players that the disparity between newer players and established players with a 300 cpu empire, is a design problem. Selling bucket makes this disparity greater for better or worse.

Overall, I'm not opposed, but I suspect there better (less risky) features to add.

(1) If cores per player becomes a true issue the devs can always scale the value returned by Game.cpu.getUsed() so that each player consumes less server cores. Also I'm purposely ignoring the game design side of the question of balancing cool-stuff among players and encouraging player subscription.