PTR Changelog 2019-09-20: NPC Strongholds

  • I see in the docs that ruins are walkable. What about building on top of them? Is it allowed or not?

  • Reading the docs:

    An Invader Core has two lifetime stages: deploy stage and active stage. When it appears in a random room in the sector, it has ticksToDeploy property, public ramparts around it, and doesn't perform any actions. While in this stage it's invulnerable to attacks (has EFFECT_INVULNERABILITY enabled). When the ticksToDeploy timer is over, it spawns structures around it and starts spawning creeps, becomes vulnerable, and receives EFFECT_COLLAPSE_TIMER which will remove the stronghold when this timer is over.

    What is to stop me from placing 50xT3 boosted dismantle creeps on the public raparts and as soon as the core becomes open, just chewing it down very quickly? The stronghold ramparts will protect me, and my damage/tick is huge.

    Also, how do the structures handle a creep being where they want to spawn?

    I'm not sure I understand why we need this two-phase deployment.

  • I would also feel more comfortable if the "main" stronghold in a sector was owned by Invaders, rather than just being reserved. Feels more consistent. I'm currently going through code adding checks against the reservation username and fixing things where I use stuff like CONTROLLER_STRUCTURES[STRUCTURE_TOWER][room.controller.level]


  •!/room/shard2/W19S15 There is a stronghold in this room but it isn't reserved. Is this intended?

  • I knocked up some code and thought about testing it on PTR, but for whatever reason my CPU usage is very high on PTR, and 10 second ticks doesn't really suit debugging that well. No shard specific code or anything and the same code is running fine on MMO.

    I guess I'll wait until they're on private servers.

    EDIT: Oh. Now it's fast. Thanks!

  • I got the following error:

    TypeError: Cannot read property 'energy' of null
        at exports.make.register.wrapFn.Object.defineProperties.C.RESOURCES_ALL.reduce (:41357:40)
        at Array.reduce ()
        at new  (:41355:29)
        at Object._storeGetter [as store] (:41284:12)
        at Object.get [as store] (eval at exports.defineGameObjectProperties (:1093:9), :7:61)

    When doing:

    for (let ruin of room.find(FIND_RUINS)) {
    	loot += _.sum(

    Specifically, _.sum( seems to be failing. Not sure which room or ruin, just saw it in some logs.

    EDIT: Could be I'm getting the store of a ruined object that didn't have a store property - like a wall? Probably my fault and I was just confused by the error.

    EDIT2: Ok, the issue shows just seeing if there is a store property on a ruin: if ( {

    W9S39 [ruin (extractor) #5d84b9f57c29e164bd6fcf85]
    [16:01:53][shard2]TypeError: Cannot read property 'energy' of null
        at exports.make.register.wrapFn.Object.defineProperties.C.RESOURCES_ALL.reduce (:41357:40)
        at Array.reduce ()
        at new  (:41355:29)
        at Object._storeGetter [as store] (:41284:12)
        at Object.get [as store] (eval at exports.defineGameObjectProperties (:1093:9), :7:61)

  • Dev Team

    We've migrated the Public Test Realm to our new cluster based on Intel Core i9-9900K and Nodejs 10, so you can test NPC Strongholds with a bit higher performance.

  • Something funky going on with caravans on PTR.!/room/shard2/W0S20 tick 19029510

    Caravan creeps with no owner that aren't visible (but are clickable) on the room view, but are visible on the map view.

  • Dev Team

    This post is deleted!

  • Dev Team

    All: thank you very much for your reports and suggestions!

    @eduter We're currently working on structure information in ruin, should be on PTR later this week.

    @QGazQ all ruins are walkable.

    @Smokeman yes, with proper placement you'll probably be able to loot ruins before ruin decays.

    @Zyzyzyryxy building on top of ruins is allowed. If you're fast enough, you can build something on top of a ruin, destroy it again and stack ruins

    @duckymirror no, this is a bug, we'll investigate it, thanks.

    @Tigga creeps standing in the deployment area will be removed. We're currently reworking stronghold/controller interaction, strongholds will claim rooms where they are. Thanks for reporting the issue, the fix will be deployed to the PTR later this week. Caravans should be already fixed.

  • isActive() currently returns false on Invader towers. I guess that will be fixed with controller ownership?

  • There is a breaking change with RoomObject.effects.

    Previously an object in that array was guarenteed to have a power field. This is no longer true. Any code that assumes it does will fail.

  • There's a couple of stronghold exploits I've not tested but I'm pretty sure would break things:

    1. The current AI will fill towers to 1000 energy if they drop below 500. It is also possible for the player to withdraw energy from hostile towers. Depending on the order of operations a player could farm a stronghold for 500-1000 energy/tick per tower by emptying the towers out with haulers.
    2. Less bad, but if a stronghold can spawn a 50 part creep with 40 T3 boosts in 50 ticks then those are farmable for 240 T3 boosts in 50 ticks. Now a squad of 4 50xT3 boosted creeps would cost 200 T3 boosts in those 50 ticks, but once you've cleared out everything but the invader core you can probably farm pretty cheaply.

  • Dev Team

    An update deployed, now strongholds have ownership on their base room.

  • @artch said in PTR Changelog 2019-09-20: NPC Strongholds:

    An update deployed, now strongholds have ownership on their base room.

    How does that work if the stronghold is in a centre room with no controller?

  • How does the invulnerability effect work? Right now my creeps are attacking an invulnerable core in!/room/shard2/W8S32 and are damaging it just fine. I kinda feel it shouldn't be taking damage.

  • Dev Team

    @tigga In centre room with no controller strongholds won't claim or reserve controller. Invulnerability should work, I'll double-check that, thank you for your reports, for all of them.

  • Dev Team

    PTR is updated.

    Thank all of you for your feedback and suggestions!

    • Strongholds claim rooms where they appear (setting RCL to 8 instantly) and unclaim them when destroyed or decayed. It would make a room more like a player's room and solve some inconsistencies.

    • Strongholds will clear its area when being deployed removing all room objects there.

    • Nuke impact is updated: now creeps that killed by nukes don't leave tombstones and structures destroyed by nukes don't leave ruins. Also, all existing tombstones and ruins will be removed when a nuke lands. So it's still possible to destroy a Stronghold with a nuke, but you won't have the loot, and new Stronghold will be deployed to the same sector shortly which means that you'll not have an invasion-free time either.

    • Ruin.structureType is replaced by Ruin.structure - it's an instance of Structure or OwnedStructure with basic data about the destroyed structure: identifier, type, owner (for OwnedStructure), hits. Remember that this is an instance of Structure or OwnedStructure, not an instance of a real structure class (like StructureStorage). Also, we removed owner and my properties from ruins because they exist in Ruin.structure for OwnedStructure.

    • StructurePowerBank now leave ruin with 10 TTL (see RUIN_DECAY_STRUCTURES constant). We believe that the challenge of bringing enough haulers just about time must be preserved.

    • RoomObject.effects is reworked, now the effect field is mandatory, and it contains the identifier of both power and non-power effects. Also, we're preserving the power field (now it contains id for non-power effect either) for sake of backward compatibility (although using it is not recommended, this is why it's removed from the documentation; consider it deprecated). This is done to make new effects less breaking.

    • When a player despawns, his structures are being turned into ruins with 500000 TTL

    • Nuke land doesn't reduce upgradeBlocked of a controller if it's over 200 ticks

    • Fixed few bugs and regressions

    It's still not the final state of Strongholds, but definitely a few steps closer.

    As usual, your suggestions and reports are appreciated!

  • A really minor but to me interesting change:

    Can the ruins from player respawn have randomized expiration durations? e.g. anywhere between 400k and 600k? Would add some immersion to the world if there are "half collapsed" rooms here and there, instead of everything disappearing at exactly the same tick.

    Not sure how much overhead this would cause and if that's a reason not to do it, as I have no clue how often people respawn and how many structures they tend to have.


  • So, if I claim a room from a player who has respawned, and their ruins have a 500,000 tick timeout... can I destroy the ruins? I mean... it's already destroyed. As far as I know, you can't destroy a tombstone.

    Is it just going to sit there for 20 days waiting to decay?