CPU Assignment buggy

  • I'm trying to do fully automatic cross shard expansion & cpu management.

    I managed to give negative and float cpu assignment to my shards. This may as well be caused by problems on my end, but since I'm now on a 12 hour lockdown I'm locked out of 3 of the 4 shards.

    This also triggered a cpu bug on shard 2 a while after some creeps entered:

    TypeError: `timeout` must be integer
        at Object.exports.evalCode (<runtime>:15992:76)
        at Object.exports.run (<runtime>:30483:24)

    I wasn't able to run any code on shard 2 afterwards. This error was on repeat until all my creeps died.


    This is the code that probably triggered it:

            // populate shard names (by trial and error!!)
            /**@type {String[]} */
            this._shards = [];
            try {
                let i=0;
                for(let i=0; i<1000;i++) {
                    let shardName = 'shard'+i;
                    this._shards.push (shardName);
            catch (err) {}
                // divide cpu evenly between shards
                let totalCPU = 0;
                let shardLimits = Game.cpu.shardLimits;
                for (let shard in shardLimits) {
                    totalCPU += shardLimits[shard]
                let dividedCPU = totalCPU / this._shards.length;
                for (let shard of this._shards) {
                    shardLimits[shard] = dividedCPU;

    I'm at 20 cpu, so this gives a 5/5/5/5 division.

    There's at least one bug in my code: I'm assigning my own shardLimits by reference, thereby I modify the Game.cpu.shardlimits by accident. Does this maybe break setshardlimits?

    Questions related to this bug:

    • What am I doing wrong in my setShardLimit call?
    • Setshardlimit isn't documented very well. Can I pass floats or do they need to be ints?
    • Can I pass values higher then my CPU limit?
    • How can I determine my max CPU limit (without hard coding). Is my assumption correct that I can sum all assigned shard CPU?
    • How can I safely determine all shard names? Getshardlimits only returned my current shard before I reassigned.
    • What happens if I pass values higher or lower then my total or the shard limit?
    • Can setCPUlimit get some safety checking before committing to the 12 hour countdown? like: no negative values, no floats, unspend CPU automatically allocated or not allowed. The GUI already does this.

    Because the timeout is 12 hours and I can't find the CPU stuff in the source code on github, it's very hard to experiment / find this out for myself.

  • An update: I now manually set cpu limit to 1/1/5/13 for my shards. After sending in new creeps from shard3 > shard2 I was struck by the timeout error again after 2 ticks.

    After a while it reset and stopped. I'm now logging the CPU and it is as follows: immediately


    What I'm seeing is that:

    • My bucket didn't fill up when I had no creeps there (I wasn't there for > 12 hours)
    • My bucket still has floats in it.
    • The timout error triggers if I have a bucket <500 with a float value.

    I hope it fixes itself when I get to a full bucket again.

  • Dev Team

    @jerdaz Thank you for your report! We'll try to reproduce the assignment issue. Here, some answers:

    • You supposed to use integers in setShardLimits
    • You can't pass values higher than your CPU limit. If you managed to do that, please report the bug into the official support system
    • Your max CPU limit is always 20 without a subscription or 20 + GCL*10 with a subscription. Sum of all assigned shard CPU should be the same. If it's not, please report the bug...
    • There is no safe way to get shards list currently. We'll see what we can do about it.
    • If you pass values higher or lower then your total limit, you'll get the error. If you pass a value higher than the shard limit, it will be accepted and CPU will be assigned to the shard, but excess CPU will not be used.
    • setShardLimits should check arguments and return an error if something is wrong. If it's not, please report the bug...