PTR Changelog 2017-06-23

  • Dev Team

    This post describes changes on the Public Test Realm.

    This is an experimental attempt to store all room objects data in Apache Cassandra instead of MongoDB. It potentially can reduce the database load and allow us to effectively scale the database without introducing the world sharding feature.

    The server driver has been refactored with experimental support of Cassandra and deployed to the PTR. We ask everybody to help us test this change. When the driver is tested well enough and confirmed to be stable, we’ll make a temporary production deployment to benchmark performance and decide whether it’s worth it to proceed with the migration.

    What to test?

    This change affects all mechanics regarding world room objects, their state fetching and modification, using both API and UI. Only room objects data is moved to Cassandra; all other types of data (like account preferences and activity, flags, intents, leaderboards, market data, map statistics and terrain) are still stored in MongoDB and Redis and not affected by this change.

    Please do your best to test as many patterns changing rooms objects state as possible and report in this topic what are your results.

  • Culture

    Awsome change, testing now.

    findings so far:

    Could it be that we currently don't have vision in rooms where we do have an owned structure, but no active creeps? 

    • Flag in a room with owned structures WITHOUT creeps do not have any .room property set

  • I hope I'm not too stupid, didn't touch PTR for a long time now


     - It took very long (~a minute) between uploading code via grunt to PTR and actually showing the code in the web interface

    More important:

     - `> JSON.stringify(Game.rooms)
    < {}`

    I just respawned in room W48N96, I guess I should have at least the room, where my spawn is located.

  • Culture

    Same issue as TooAngel,

    No creeps = no vision now

  • Dev Team

    Deployed some fixes, please try the same test pattern again.

  •  - W48N96 can not remove hostile constructionSites (via the web interface)

  • Dev Team

    Currently it can't be deleted on the main realm either. Probably some glitch somewhere, but not related to this change.

  • Culture

  • It seems terminal transfers aren't working. I'm receiving OK statuses, but no resources are actually being transferred.

  • Culture

    That could also explain why I got 0 energy in every terminal now. The cooldown is also 60K ticks

  • Dev Team

    It seems terminal transfers aren’t working. I’m receiving OK statuses, but no resources are actually being transferred.

    A quick test of terminals seemed to work fine. Could you please provide more details?

  • My code keeps trying to balance energy among rooms, and it's constantly trying to send the same amount of energy from one room to another, which gets a status of OK, but no transfer actually occurs, so the next tick it tries to do the same thing again. An example of this is an energy transfer from E21N57 to E21N51, which is currently failing with an OK status every tick.

  • Culture

    I got the same kind of logic in olace, but for minerals.
    It does also send back a transaction, so it could be related to 2 terminals sending things to each other

  • Awesome! I love tech experiments. Let the stress testing commence.

    I activated my CPU and let my AI go all in. I've modified no code since my last run, and things were to my knowledge stable. So far my code itself seems to be running, but at time of writing this, E59S39 on PTR is froze up entirely, excluding [room]visuals. Creep TTL seems to be decreasing but intents don't seem to be processing? Other rooms are intermittently freezing as well.

    Container and rampart decay went into the negative in both rooms (attempting to remove containers didn't work either). Seems to have a loose correlation with the pauses at least. Is it possible the rooms aren't considered "active"? My code runs in stages with rooms, creeps, and structures as separate main-level loops, so I can guarantee something is trying to act on the world. 

    Something appears to be wiping out the terminal store entirely. No energy value, nothing. Inspection of a terminal shows the property 'store' is there, but as an empty object. The GUI still shows the resources.

    Transfer behavior appears to be a little bugged. Getting invalid target on some previously valid transfer targets such as towers and extensions. Not yet sure why this might be. Mostly occuring in the the frozen room E59S39.


  • I spent awhile trying to track down an issue, and it turned out to be that Game.getObjectById(undefined) is returning a seemingly random object in one of my rooms (it changes), but with the id field undefined.

    I have many calls in my code that will call Game.getObjectById(undefined) and expect to get null back, and that has never caused problems on the main server. No idea if this issue is related in any way to having a different DB.

  • Dev Team

    @WarInternal has it happened right after you activated your account on the PTR, or kept happening after that? I can see now that E59S39 is active, is something wrong with it right now?

    @stuy486 Could you please show an exact snippet of code and the result of it? What is the object with id field undefined?

  • Code in my main loop:

    module.exports.loop = function () {


    Output on the console:



    Now that I'm typing this up, I've gone and looked at that room and there's actually two roads at that spot, one with an ID and one without.

    So, I suppose it's possible Game.getObjectById() is functioning properly, and the real problem is that there are structures without IDs in various places in my rooms.

  • @Artem It's ongoing. 

    Found a bug. Everything in my `Game.structures` is reporting the property structureType as road. Explains all (or most of) the problems I'm having actually.

  • Dev Team

    Undefined objects and invalid structureTypes must be fixed now, please confirm.

  • structureType fix confirmed, thank you.