@artch @o4kapuk that was it! Thanks for the assist.

@artch

more interesting logs appear in processor:

Error processing room W9N6: TypeError: Cannot read property 'energy' of undefined
    at module.exports (/home/screeps/world/node_modules/@screeps/engine/dist/processor/intents/spawns/tick.js:51:87)
    at /home/screeps/world/node_modules/@screeps/engine/dist/processor.js:423:83
    at /home/screeps/world/node_modules/lodash/index.js:3073:15
    at baseForOwn (/home/screeps/world/node_modules/lodash/index.js:2046:14)
    at /home/screeps/world/node_modules/lodash/index.js:3043:18
    at Function.<anonymous> (/home/screeps/world/node_modules/lodash/index.js:3346:13)
    at /home/screeps/world/node_modules/@screeps/engine/dist/processor.js:410:11
    at _fulfilled (/home/screeps/world/node_modules/q/q.js:854:54)
    at /home/screeps/world/node_modules/q/q.js:883:30
    at Promise.promise.promiseDispatch (/home/screeps/world/node_modules/q/q.js:816:13)

@artch

Not much in there:

Loading mods from "/home/screeps/world/mods.json"
 - /home/screeps/world/node_modules/screepsmod-auth/index.js
 - /home/screeps/world/node_modules/screepsmod-mongo/index.js
 - /home/screeps/world/node_modules/screepsmod-admin-utils/index.js
 - /home/screeps/world/node_modules/screepsmod-features/index.js
Starting storage server
Storage listening on storage.sock

@o4kapuk so this is not a common occurrence?

I simply had v3 installed before and upgraded to v4.

The only other interesting thing is that I'm using an AWS EC2 A1 instance.

Dear Screeps,

Since updating to v4 of the screeps server, there seem to be some strange issues abound.

Receiving an error in the console:
TypeError: Cannot read property 'energy' of undefined
at makeGameObject (:17067:77)
at Object.init (:17239:49)
at :16435:22
at ()
at make (/home/screeps/world/node_modules/@screeps/driver/lib/runtime/make.js:142:34)
at processTicksAndRejections (internal/process/task_queues.js:93:5)

The world doesn't seem to have initialized correctly. Is this a known issue?

Here's how connecting via the client looks like:

Assistance would be welcome.

Kind regards,
Atavus

I think the correct approach is to take a step back and look at the original problem.

You wish to know that a room is in Novice/Respawn so you can use this information in pathfinding.

Why do you need to use this in pathfinding? Because those rooms are walled off.

But the question then is, how does your AI handle trying to go to a normal room that is behind other walled off rooms?

I get the feeling Novice/Respawn is just a more frequent instance of having an area blocked off by walls. You probably should teach your AI to handle that case in pathfinding logic and then you won't need the Novice/Respawn flag.

@duckymirror oh! That's an interesting suggestion.

I like that.

It would maintain the map as dynamic and would smooth out the advantage/disadvantage of being on the edge.

Just a throw-in, but be aware that for terminal transfer costs, the map already behaves this way.

Perhaps relevant for @keenathar.

Agreed.

There's been a fair number of ideas bouncing around, but we don't seem to be converging on a clear solution yet.

There's enough going on with all the other changes and initiatives.

I'm similar to wtfrank.

Each room has a centre position which is calculated once and cached. All structures are offset from that position. For me the cost to calculate this is not so expensive because of how simple(good) and inflexible(bad) the design is.

Normally I check a room only when it has gone up/down in RCL or the cache key(owned structure count) is invalid.

In practice, my architecture (name of the operation in charge of core structures) CPU costs are negligible, but my design is really basic.