3. PTR Changelog 2019-12-21

PTR Changelog 2019-12-21

  • Dev Team

    This post describes changes on the Public Test Realm.

    • Added new method StructureLab.reverseReaction to "break down" boosts to their components (see discussion).

    • Added new method Game.map.getRoomStatus to determine is the room located in Novice or Respawn Area (see discussion). This outdates Game.map.isRoomAvailable which is deprecated now. Game.map.isRoomProtected has been removed since it's been deprecated long time ago.

    • Added UI option to hide the link to Steam profile (see discussion).

    • Changed error codes of StructureNuker.launchNuke: now it returns ERR_INVALID_TARGET if either source room or target room is part of a Novice or Respawn Area

    • Changed error codes of Room.createConstructionSite: now it returns ERR_NOT_OWNER if the room is owned or reserved by another player.

    • Changed Creep.upgradeController so that controller level-up happens on the same tick when StructureController.ticksToDowngrade becomes full.

    • Changed pathfinding default value of heuristicWeight from 1 to 1.2 for better performance. This affects PathFinder.search, Room.findPath, RoomPosition.findPathTo, Creep.moveTo, PowerCreep.moveTo.

    • Room.name property is now immutable.

    • Changed behavior or NPC invaders, now they shouldn't attack structures which are not on their way.

    • Fixed some edge case inconsistencies in Store methods.

    This update is deployed to ptr private server branch (version 4.1.0-beta.1) on both npm and Steam:

    npm install screeps@ptr

    👌

  • PTR inclusive "StructureLab.reverseReaction" runs fine for me


  • 🚂 🚂 🚂


  • "3 months ago". I was hoping for a new year gift, so +1 for release. Or what is missing? 😮

    1 Reply
  • Dev Team

    @demawi we're currently performing final testing before releasing this update.

  • Dev Team

    The release date of this feature set: March 24, 3 PM UTC.

    🎉

  • Oh, I did not touch this in PTR, so I'm coming in cold in trying to implement it into my lab production system.

    That was easy! It's literally exactly like the "runReaction" method, but backwards. All I had to do set a "shatter" state instead of a "production" state and change the rules (production on not enough, shatter on too much) and reverse the material flow.

    Naturally, I use the "ring of labs" layout, with the output labs in a ring around the 2 input labs, so I can run gang production/shatter. Reversing the reaction uses the exact same layout, but with the input / output reversed.

    Nicely done, Goggles.


  • One weird snafu I ran into:

    UH is backwards. All of the rest of the [U,L,Z,K] [O,H] combinations are in that order, the [O,H] mineral always goes in the second lab.

    I also had G backwards, but that's a 50/50 shot... there is no way to determine which was "supposed" to be first or second, UL or ZK. In hindsight, sure... because that's the order they're just "usually in."

    At issue appears the way the lab reactions are defined. When working out my lab system, I had to redefine the data structures as they were just not useful for the purpose of building compounds, I needed them to be in a 3 deep array, like "['KO'],['K'],['O']" where index 0 of the array is what I'm making.

    So my database looks like: ... ['UH','H','U'],['UO','U','O'], ... etc. Only the UH one is backwards like that.


  • Game.map.getRoomStatus("E999N999") returns

    {
  "status": "normal",
  "timestamp": null
}

    I don't think this should be a valid response!?

    ✔
    1 Reply
  • Dev Team

    @demawi Thanks for the report, I'll take a look