Today my included subscription expired. I am a steam user, so i should fall back on the basic 10CPU per cycle (plus buffer by bucket). Now there's some strange behaviour about this:

1. After getting the first email notification i logged in and the UI showed my i actually had a CPU limit of 30.

2. after a few minutes it dropped to 10

3. although my (hopefully correctly) self-calculated average cpu usage showed to be below 10 (~9.25), the bucket seemed to empty.

4. now it shows me a limit of 30 again. Calling Game.cpu.limit shows me even 50 (I am GLC3, so this would be the subscription value).

5. I keep getting "Urgent" emails about my CPU being limited (about 4 in the last 2 hours).

Here's the questions:

- As a non-subscriber, i should calculate with a CPU limit of 10, right?

- Is there rounding in the leftover-bucket calculation? (The bucket seems to be integer, so i could figure addnig less than 1 leftover cpu could sadly be unintended?)

- Why would the UI display 30 and the Game.cpu.limit even the 50? (not that i would be unhappy about extra cpu)

- Will i keep getting emails about the cpu limit until i subscribe again? if this is the case, i'll need to readjust my spamfilter...

The game is great fun, and although the subscription prices are a bit too steep for my taste, I totally get why you need to set them like this.Although i wish that even a steam-basic user could gain at least a bit up on his 10-limit (say maybe at leas 1CPU per GCL?) i'm up for the challenge of staying below 10 on average (still hoping that a tick with a usage of 9.25CPU will still allow me to gather cpu in the bucket)

However I would really like not to be constantly spammed by the Limit notification, so i hope that this is also just a bug.....

I think the logic is in the way the game loop works. The Memory is yours, and you can act on it. You can manipulate the same Memory object several times in a row, and the data is written instantly always. Spawning and World-affecting stuff (i guess everything they declared with the const cost of 0.2CPU) could be seen as being acted between gameticks. Your code is preparing it, telling everyone what to do, but they don't do it until your code is complete. So the spawner does not start spawning until the end of the tick (although it already got the command earlier). Until then, it leaves us with the state of the creep's Memory existing before the creep itself (kinda philosophic, isn't it?)

Edit: Another thing i stumbled upon is the cancelOrder(methodName) method of the creep. This might be a reason why things work as they work. It seems like you can gain more control by being able to cancel the Orders you gave in your code before they are executed.

"this" is actually the way to do it. i was stumped with this for some time, too, but if you do the call with this.inner('ValueToPassOn'); it should work.

From what i could observe in my rooms, Amadox got it right. I expanded to a second room, thus, i had a second spawn doing the spawn routine. This included the cleanup. So the first room gave order to spawn a creep, Memory was created, but the creep was not yet spawning. Then within the same tick Spawn2 would do the same, deleting the Memory Spawn1 set up.

My fix was to take the cleanup and put it in a seperate function which is called seperately, only once when required, before any spawns do their magic.

In the StructureSpawn description (http://support.screeps.com/hc/en-us/articles/205990342-StructureSpawn) the declaration of this functino is not requiring the resource type, but instead the amount (which is optional)

             transferEnergy(target, [amount])

Interestingly enough the function still returns -9 in case the creep is too far away, which is why it moves.

Anyway as far as i know, The constant RESOURCE_ENERGY resolves to the string "energy", so when the creep arrives at the spawn, it does not know how to transfer "energy" units of energy to the creep. You could add an else bracket to check for other error codes returning, but if you go for Game.spawns.Spawn1.transferEnergy(creep), everything should be fine.

looks like the sorting code should be working fine (tried it just with some random numbers in simulation).

Looking from the other side, for some reason transferCreeps[0] seems to be the wrong one, so how is this possible?

I would suggest to add some console.log()s in between the lines to check some things, e.g.

- the names and energy levels of both creeps,

- the decision made using transferCreeps[0],

- maybe just JSON.stringify the array itself before and after sorting.

If i had to guess i'd say for some reason findInRange does not actually find both creeps, so sorting would be irrelevant in that case, maybe also output

- transferCreeps.length, to check if the array DOES contain both creeps in range