Topics created by theAEmix

Oh, you are right. That looks like a bug!

To avoid that in future, you can use this solution to edit & store your scripts locally and commit it up to the game when needed.

As far as I know (I am not an expert on how io.js handles require), require uses a synchronous file system fetch to load in the resource. As a result, if the hardware that the instance of io.js is running on is taking a long time to find the file, or if it is busy doing someone else's loading (most PAAS providers run multiple VMs on a single piece of hardware), then the script will block and wait for the data to come in. I assume that the CPU timer would continue to run during this time and as a result the amount of time wasted on loading the script could vary on things outside of anyone's control. The only way I can think of circumnavigating this problem is to not use require. Perhaps as a community we need to develop a Travis script that will go through all the files, replace any require calls with the code that they would fetch, and then push the modified files to the screeps api. That way, the hardware issues would not be reoccurring cost faced by the scripts, and instead would only be paid once during build time.

I tried to do some benchmarks in the simulation room. I was getting large ranges on filters and find functions. Anywhere from 1 to 5 CPU on a 75 item filter. The room was static, with random structures and creeps spread about. And I still saw a large variation in the needed CPU per tick

Thank you.

So, I was messing with this and have some more information: As before if you declare: Game.spawns.Spawn1.createCree([WORK],'Name',{ role: 'harvester', test : 'test1'}); it works fine in the script but does not apply properties in the console. Instead, if you declare: Game.spawns.Spawn1.createCree([WORK],'Name',{ 'role': 'harvester', 'test' : 'test1'}); with the extra quotations around the role and test object names, it all works correctly. If any one tests this, please verify that it's not just my code.

The flag on the left side of the of findPathTo must be in a room you control. Even still, findPathTo will only find a path to the exit closest to the second flag; findPathTo only works in one room.

@stealth, this would be possible, however, this usecase is rather limited, as the console does not have access to the prototype enhancements of your script anymore

You can kind of do this by just decreasing the size in your browser, but it gets really slow. I guess if the page actually had zooming functionality, it could do something nice like stop displaying all the dynamically updated creeps past a certain zoom level.

No problem, just doing my part. Now to lament in general about how swamp roads are so much more expensive after the fix ;).