The latest changes to the game, the tombstones and new reaction cooldowns, aren't available in the Steam dedicated server like they are available on the production environment.

I used the dedicated Steam server for development and testing. It runs at a pace I can control, allows me to 'cheat' by editing the database from the CLI and in general have full control over it. However, with the dedicated Steam server and the production environment running on different server version my codebase has to either compensate for the change(ie, have a special getCooldownForReaction(resource) method containing a switch and I cannot use the tombstones.

I am aware there is the PTR, but even then it would make my code unable to run on the Steam server and thus severely hamper my ability to develop and debug.

Is there any update on when the Steam version will be updated?

Great idea, however, since accessing the eventLog incurs costs, would it be possible to apply filtering before accessing the eventlog? For instance, let's assume I do not care about my harvest effeciency but only care for attack events, would it be possible to call setEventLogFilter() on the room and only supply EVENT_ATTACK as a filter?

By default, no filtering is applied, but after calling this method, all other events are ommitted from the log(and thus also save cpu cycles server side when serializing it).

I've had this occur in my SIM room as well. Creep.build() returns 0, no actual building is done(carry[ENERGY] won't decrease either) and the whole thing locks up. I noticed that if I build a container it places 2 construction sites. The count goes down by 2 and IF the container finishes I can still see the second construction site. I restarted several times, tried 2 different browsers(and the Steam client) and the lock ups happen at different moments, sometimes it finishes other times it won't.

This bug is still present in the simulation room. Whenever I zoom in on a container it will show a construction site underneath. Changing to a different room is impossible because it will reset the sim room. It also happened that containers were never finished, even though the creep.build() returned 0.

Thank you for the reply Artem, I shall use the PTR for implementing my multi-room related code.

I'm aware that in software development there are always more possible features to implement than there is time available. Having the PTR is a great alternative to the simulation but it lacks one important aspect in regard to the simulation: total control. In the simulation mode I can create a room layout to my liking and if necessary increase the RCL, add structures so I don't need to wait for them to be built and but more importantly: increase the game speed to 500% without any limitations on the amount of CPU cycles. Features that making testing incredibly efficient and productive.

Please don't feel hard pressed, I rather have you guys spend your time on implementing World mode related features but if you at some point do have a little time to spare it would be absolutely wonderful if the simulation room could be made multi-roomed, even if it would only be 2 rooms without any fancy bells and whistles.

I understand that your time is very limited and don't believe this should be a high-priority feature.

I'm currently getting my AI ready to start playing in World mode. However, it is impossible to test out my AI behaves when it has to colonize another room, attack another player or in fact just discovering a new room for the first time. Attacking Player 2 in the same room has limited opportunity to test my scripts in all scenarios and I rather not fiddle around in production later on to implement these things.

Can the simulation be expanded with at least 1 additional room? Having a total of 5 rooms would be most perfect(a center room with connecting rooms in the north/east/west/south) but I'm not too picky and would totally settle for just one additional room.

I've ran into this exact same problem today, with this code:

var drops = _(this.memory).filter(function(node) {
    return node.amount - node.capacity > 0;
}).map(function (node) {
    return Game.getObjectById(node.id);
});

If you're chaining lodash method calls, they will get wrapped in a lodash object and you need to call value() as the last method in the chain to execute it and unwrap the result. The proper block looks like this:

var drops = _(this.memory).filter(function(node) {
    return node.amount - node.capacity > 0;
}).map(function (node) {
    return Game.getObjectById(node.id);
}).value();

You can read more about this here.

In other words, you last method call should look like this:

_(Game.creeps).filter({ memory: { role: 'Harvester' }}).value();

I have noticed this behavior as well and I think it is because of the javascript files being compiled, as I detailed in my answer in this post

You can find more information on the Source Keepers in this post.

In short: Source Keepers guard sources in maps. Every room has up to TWO unprotected sources which are freely accessible by your creeps without being hindered. If your room has more than 2 sources the remaining sources will have a Keeper Lair within 5 tiles which will spawn Keepers. The keepers follow the same lifecycle as your creeps(they live only 30 minutes) and have a mission to keep you from accessing the source's energy. In order to get to the source you will have to kill the keeper and kill it after it respawns after 300 ticks.

It is lazy so it won't stray far from its source and will not bother to follow your creeps but it will attack any creeps that is near the source. Once killed it will drop energy which you can pickup. If you intend to mine those sources(which is advisable) you should build protective ramparts around the source to protect your miners and trucks.

And they just updated to a version of iojs that supports ec6. So I'll be using template strings from now on.