I think it would not be much change for me, if it is correct in the game constants like "CONTROLLER_STRUCTURES".

Besides, i wonder how i can upload code there (via api), just use screeps.com and a new token?

@warinternal than there would be that constant of 500, thats what i meant; then i could directly use the magic 500. Of course some things depend on room/empire Status, but i just wanted to explain that with each aproach, changing the capacity would need some adjustments in code. I had no problem with it, as soon with the store change there is much to change nontheless.

But the only argument for now is that bigger Containers would make the game easier. Then, i am against a change. If you make everthing just easier, the game is just less a challenge and so, more boring. It would make coding good harvest/hauler code less rewarding. I know that in my lastest Code Version, i have/had problems to supply my upgraders container with energy. While bigger containers would make this easier, i totally liked the challenge.

Even when only changing the constants, it would be needed to adjust Code. For example, I use Containers as Buffers for different purpouses, and when the capacity changes, the amount of buffered energy would be inefficient, when i use 0.25 Times of Capacity for example as a Low limit, it would be to much with the value change. If i did different, i would have hardcoded numbers. Both cases, Code would work, but not optimal.

Doing Things not intended can break Code ofc. Like that memory hack for not destringify memory that i use, too. But i would not call a change breaking, cause its clear its not the documented use case.

@xenofix I had 1.6 MB of code when the RoomPosition change came, and i didn´t need to change one line because of it. All worked as before. I would not call that a breaking change. So switching boosting to Spawn would be a different thing, I totally agree with @Smokeman that changing boosting with labs would only make screeps "more boring" by making the logistics simpler.

@mrfaul said in Trying to create creeps in a more dynamic way:

@saruss nope, you would nest arrays that way. But you could do:

body.push.apply(basicBodyParts);

The apply() is part of the function object/class and feeds a array as the parameters.

@MrFaul Nope, i would not nest arrays. Please read what that three small dots make there: (eg here: https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Operators/Spread_operator )

@calfa said in Trying to create creeps in a more dynamic way:

with... for(let i in basicBodyParts){ body.push(basicBodyParts[i]; }

i would suggest body.push(...basicBodyParts);

I did not read your files, but every gamestate changing action has a cost of 0,2 CPU if "ordered". With your Code you can reduce overhead, but not overcome this. Just count your intents and log CPU used, to see if and where you can optimize.

Or better remember if there is some mineral in there too, maybe use lowdash container.storeCapacity - _.sum(container.store) for free space.

@artch looking through all Events logs where own Creeps/builings are /Filter for rooms with enemy creeps will cost a lot of parsing CPU.