So much wrong with this, but I understand why you think it could work.

First, Screeps is not a system where your code is running all the time. It runs in slices, but unlike a Linux program with a select loop, your access to resources is not guaranteed in the time between slices.

As such, you cannot attempt to insert a realized class into an object you place in a creep's memory. You can "do it"? But it will be a data only version... as such, you most certainly cannot execute something like:

Game.creeps[creep].memory.myObj.run(); out of a creep's memory. Oh dear gosh no. Only pure data can go in memory in this context, certainly not functions.

On a private test server (But I assume the current behavior is the same on live.) I get these errors:

[4:17:24 PM]Using StructureSpawn.renewCreep on a boosted creep is deprecated and will throw an error soon. Please remove boosts using StructureLab.unboostCreep before renewing.

Ok, sure... I'm renewing a lot of creeps in that room. I started by trying to unboostCreep() them before renewing them, but that ran into a wall pretty quick as a level 7 room has only 6 labs, even cycling through ALL the labs to use them all to absorb the unboost prior to renewing (And subsequently re-boosting.) the creeps hits that bottleneck at somewhere around 3 20 WORK part upgraders.

Am I trying to "abuse the system" or is the cooldown for the unboostCreep() command unreasonably high? I'm not even using the max boost, just the T2 Upgrade (GH2O) one. I would think I should be able to do one of those (With 20 WORK.) for each lab I dedicate to the unboosting.

Looking IN the Array, you are, when looking OF the Array you should.

IN is for objects. OF is for arrays.

Goggles (04kapuk) is correct. I looked at the replay too, and what's happening is the creep is renewing every tick, and also trying the boost. The boosts actually apply... but never show up because you're renewing in the same tick. Both the boost and the renew are applied in the inter-tick time when intents are applied, and the renew removes the boosts, but the boosts still cost you.

Yeah. Don't do that. And there's a good reason for it to be this way, if you could just renew boosted creeps, that would cheapen boosts and you would use them forever. Imagine if you could just boost a remote miner's transport and renew it forever.

There IS something you can do to mitigate boost cost in certain circumstances, though... there is the lab.unboostCreep() command that removes the boosts and recovers 50% of the originally applied boosts... if you need to renew the creep, use that FIRST.

I suspect this is him here. Creeps cannot be on the same tile at the same time. That's really their only rule in this regard.

Your first problem is the creeps that got energy from the source aren't trying to move away from the source. Make them move! If you don't use same variant of move (Like 'moveTo(destination);') it won't try to continue it's journey.

your second problem is you have way too many creeps in there. Make less creeps! With less creeps, it will be more clear why they aren't moving away from the source.

Creeps swapping places: What actually happens is each creep jumps from tile to tile, like a chess piece.They don't have a 'collision radius' and propagate from place to place. If the move was probably legit when the creep.move(dir); (It always distills down to that call.) call was made, it returns '0' and registers the 'intent' to jump to that tile. If the simulation can move the creeps when it runs, the creeps jump to the next tile. On the client, they are moved smoothly around, so it looks like they go through each other.

As far as I know, User names are cast in stone and immutable for the life of the account.

So you would need to kill off that account and start a new one from scratch.

I use the Steam client, so I don't even have a "back" button.

You also can't just use the left menu's "world" button to do back to where you were in the world, it just randomly puts you in whatever shard. You have to click the "summary" button to go to the summary screen, and click what room you actually want. It's a little annoying.

The code stopped during the attack in your room north of that one, right when a creep died and the spawn had already been killed. It probably tried to respawn, and that tried to use a null pointer. By the time the wreckin' crew got to the room shown, your code had already halted.

TRY/CATCH is your friend. During combat is usually when crashes like this happen.

The first code segment returns an array of the non-empty containers, you would need to use targets[n] to determine the one you want.

The second won't work, as "STRUCTURE_CONTAINER" isn't one of the FIND constants. You need to use "FIND_STRUCTURES" then filter for the one you want. THAT one returns a single object.

From my point of view, I like and welcome this change, it will allow me to streamline my creep states so they can exit faster (Thus saving CPU.) I am concerned that heap use may increase, but that's Artch's problem... and in reality, any heap issue impacts everyone, mostly heavy users and users past the 300 CPU limit first, so I don't have a problem with that, despite that I'm breathing down the 300 CPU limit's neck. At the end of the day, it's pretty fair.

Two potential issues. First, the obvious one: Nukers with their 5000 ghodium. Two stores? Ewww! Don't make them all the same except for this one weird bird. Applying a limit object with, for example: {G:5000,energy:250000} to it is the best solution, other structures would have null there to short circuit any checks.

Then the 800 pound Gorilla: LABS. Labs are incompatible with a Store object unless you dynamically reset the limit object on the fly. Sure, the capacity remains 5000, but it can change from (for example.) {UO:3000,energy:2000} to {energy:2000} to {KH:3000,energy:2000}. It can have only one non-energy resource as it uses that to determine what it's doing.