@JBYoshi

Posts made by JBYoshi

Looking at your room, I think your problem is not with the spawn, but with the source. find(), findClosestByRange(), and findClosestByPath() only work for objects in the same room, so if your creep happens to wander into the next room, it will start harvesting from that room's sources. If you weren't trying to harvest from the other source, I'd recommend storing the source's ID in the creep's memory whenever it switches to harvesting mode (see @SandGrainOne's post).

That said, so far I've been thinking about this in terms of the entire tick length. If the reading/writing happens individually before/after each player's code then that would significantly reduce the problematic delay, although I'm still not sure we can place any guarantees on it.

Both the main server and private servers use Node.js, so they support any ES6 feature that works in Node.js.

The simulator uses your browser’s engine, or Chrome if you’re using the desktop client. Anything that works in that will work on the simulator.

Right now, Node.js, and the popular browsers, support almost everything in ES6, but no single option supports every feature out there. I recommend https://kangax.github.io/compat-table/es6/ as a list of what works and what doesn’t on any particular browser.

Would it be possible to expose some additional room APIs to handle this? For example, checking whether an arbitrary room is a novice/respawn area, and whether it has a room controller. If you're in a novice area, you can travel to any room with a controller if (and only if) it is part of the same novice area, and any room without a controller if (and only if) it is adjacent, possibly diagonally, to the same novice area.