It's a very good room to start in! It can give you a very good kickstart for early room development.

Later on you'll also have to take neighbors & neighboring rooms into account for external harvesting.

Or if your bot is fully automated like mine, it is not easy to select the best room in an automated way. Or to defend against the very strong players. There are also different playing styles to adopt which makes you either care more or less about rooms and their quality.

When I first started out I spawned between Muon (overmind author) and Tigga (most infamous fully automated bot out there). I choose to respawn before the newbie walls came down..

Half a year ago my bot was nicely settled in a nice quiet part of shard 0 when 'the langoleers' showed up and destroyed 80% of my bases. Had to resettle from shard 3.

My bot did find a very good cluster of rooms on shard 2, but was thrown out by a more powerful player who is now mining it (more effectively then I was BTW).

Long story short: Enjoy your great room but don't grow too attached too it. Later on you'll get bigger or other ambitions and/or will be attacked by more powerful players who like your room as well.

It's in this code: https://github.com/jerdaz/FormicAI/blob/main/src/meta_operation.js

Every class ending with 'Op', including MainOp extends this class, so it is called 100's of times each tick. The variable is stored locally in the function.

It happens only once every few hours so it happens only once every 1.000.000 calls or so and only one random operation is affected. It happens in different child classes (CreepOp, AttackOp, BuildingOp, HarvestingOp etc) and if it happens I only see one notification in the tick.

I use cpu.getUsed() to keep track of the cpu used by my functions and notify me when an abnormal amount of cpu is used. I often get a report for a lot of cpu usage (>500ms) because cpu.getUsed() returns negative numbers. This shouldn't be possible.

I get this warning:

{"CPUWARNING":"","OPERATIONTYPE":"HarvestingOp","cpuStart":-1289.7219116999995,"cpuUsed":1300.3438215999986}

This is the code generating the warning:

        let cpuStart = Game.cpu.getUsed();
        // rest of code
        if (Game.cpu.getUsed() - cpuStart > MAX_OPERATION_CPU) {
            Game.notify(JSON.stringify({CPUWARNING: this.name, OPERATIONTYPE: this.constructor.name, cpuStart: cpuStart, cpuUsed: Game.cpu.getUsed() - cpuStart}));
        }

I run this for all of my code. it triggers a couple of times per day because of this bug. cpuUsed is always between 1300 and 1301 when the bug triggers. cpuStart is between -1274 and -1297.

Which shard is affected? Got this on Shard3, shard2, shard1, shard0

What happened? Negative tick time from cpu.getUsed()

What should have happened? Positive tick time result from cpu.getUsed()

How can we reproduce this? Run my bot code (https://github.com/jerdaz/FormicAI)

What happens if you get a duplicate decoration? Can you 'auto-dust' all duplicate decorations back to pixels?

Also, the targetted decoration seems too expensive. It shouldn't be more then 1000.

I I buy 1x targeted decoration, I only get 1 decoration for 1 targeted theme.

If I buy 10x a normal decoration, these will, over long time, be evenly distributed over all the themes. That means 5000 pixels gives me 10/7 = 1,43 decorations on each theme (on average).

It also gives me 8,57 other decorations which I can refund for 80% of cost, returning me 3428 pixels.

Since I got 1,43 targeted decorations for 1572, I'm only paying 1099 pixels for one targeted decoration.

The stats themselves are incorrect for me as well.

Control points is 170 million higher then expected (hourly, daily and weekly)., harvested 300 million. This is 6 weeks of production for me in one hour.

I'm presuming there's a bug where there are too many stats being summed. This causes slow loading times and incorrect numbers as well. For top players this causes integer overflow as well.

I fixed this by completely deleting all files from the screeps game directory and then validating the game. This effectively creates a fresh install.

I had this on two computers..

Hi Nikolay,

Thanks for the info. I've let it rest for some time but did another attempt at dynamic cpu assignment.

I think the bug is triggered by assigning too much cpu to shard3 (more then 20).

I tried cpu assignment again last night. This time with a 60/60/60/60 division. This triggered the bug again. Because of negative cpu on shard 0/2/3 my entire economy collapsed for 12 hours.

This morning I added a manual code snippet that did a 200/10/10/20 assignment and it worked fine.

My goal is to be able to colonize to current and future shards fully autonomously, without hardcoding constants about those shards. This doesn't seem possible at the moment.

The reason I assign too much to shard 3 is:

• Currently I do not need more then 20 cpu per shard
• I haven't found a way to find the shard limit without hardcoding constants

To fix it, I will have to adjust my code to:

• Add a max cpu constant for shard3
• Disable colonization to shard4 and beyond

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

{"tickLimit":500,"limit":5,"bucket":628.8095238095225,"shardLimits":{"shard0":1,"shard1":1,"shard2":5,"shard3":13}}

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.

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;
                InterShardMemory.getRemote(shardName)
                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;
            }
            Game.cpu.setShardLimits(shardLimits);

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.