With the new isolated virtual machine we now have a global environment which can survive for many ticks without being reset. What I am wondering is, what happens if we hold onto a reference to a game object across multiple ticks?

The documentation specifically states that we cannot store game objects in Memory, but doesn't say anything about caching references to game objects on global. I did a brief test with a reference to a Room and it appeared to work, but I am not sure how safe this is.

Has anyone else tried this?

As a 10 CPU player with 9 rooms my largest CPU expense is loading all the room objects each tick. If would be great if I could cache lists of references instead of having to use getObjectById.

I am still getting this issue with the steam version.

Thanks. It's definitely improved - I'm not noticing the same slowdown over time. Having text in the console still seems to cause a big performance hit though. I also still can't manage more than about 2 ticks/s even in an empty room. I'm not sure if it's the renderer or the processor that's the bottleneck here.

As it stands, the default market history page is really hard to read, as all the important information like resourceType, sourceRoom, destinationRoom, price and amount are hidden behind a tooltip.

Screeps-SC did a great job of making this page clearer, with the added bonus that showing resource icons make it look really pretty too! Unfortunately Screeps-SC doesn't seem to be working any more, but it was always a hack anyway. I would really love to see the default page updated in the same way.

Thanks.

There's no point having more than half your creep be MOVE parts.

You don't need to remove existing structures before claiming, but the existing structures do count towards the room limit, so you won't be able to build a spawn if there already is one for example.

For claiming empty rooms I usually just sent a 1 MOVE 1 CLAIM creep to claim the controller along with the largest worker I can make to go build the first spawn.

You can still do moveTo(flag.pos) for flags which aren't in visible rooms.

Yes you can withdraw from enemy structures too, so long as they are not protected by a rampart

Do you have a lot of flags?

I had a brief look at the source code and it seems to traverse the whole list of flags checking for a name conflict. I'm not sure why it's not using a hash of flag names.

This would be so useful!

Is there any way to use the pathfinder to find paths to all goals instead of just the nearest one?

PathFinder.search only seems to return the first goal it finds, which means I have to search for each item separately, which is quite expensive.

I could implement my own A* search for this, but I'd far rather use the builtin pathfinder, especially since it's implemented in native code.

Is there an option I have overlooked?

Thanks.

Ah ok. Server version is 3.0.0.

node_modules\isolated-vm\package.json:

{
  "name": "isolated-vm",
  "version": "1.5.2",
  "description": "Access to multiple isolates",
  "main": "isolated-vm.js",
  "types": "isolated-vm.d.ts",
  "scripts": {
    "install": "node-gyp rebuild --release -j 4",
    "lint": "find src -name '*.cc' | xargs -n1 ./clang-tidy-wrapper",
    "test": "node test.js || nodejs test.js"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/laverdet/isolated-vm.git"
  },
  "author": "https://github.com/laverdet/",
  "license": "ISC",
  "gypfile": true,
  "bugs": {
    "url": "https://github.com/laverdet/isolated-vm/issues"
  },
  "homepage": "https://github.com/laverdet/isolated-vm#readme",
  "dependencies": {
    "electron": "^1.8.4",
    "electron-rebuild": "^1.7.3"
  }
}