PTR Changelog 2017-08-31: controllers downgrade changes
This post describes changes on the Public Test Realm. The estimated launch date is September 19.
attackControllerapplies 1000 ticks of
upgradeBlockedand decreases the
300 * <CLAIM_parts>ticks. The claimer creep will only need 1 tick to do this amount of damage. The creep will not be able to do another attack until
upgradeBlockedis back to 0.
upgradeControllerrestores 100 ticks of
ticksToDowngraderather then resets it immediately.
- While the controller is downgrading, it doesn't upgrade its level even when it has enough progress (progress is not lost, but accumulated without triggering the level up).
- Safe mode activation is not possible when the controller is downgraded for 5000 or more ticks.
Safe mode activation is not possible when the controller is downgraded for 5000 or more ticks.
Amazing change! No more safemodeing for exposed controller rooms
I think it is great that the issue of attacking the controller is being addressed because as it stands it is extremely difficult to actually take territory from another player (or group of players). While I think a lot of these changes are great, I think there are a couple of them that will have unintended consequences and it is worth taking another look at them to really evaluate if this is what we want.
"attackController applies 1000 ticks of upgradeBlocked and decreases the ticksToDowngrade by 300 * <CLAIM_parts> ticks. The claimer creep will only need 1 tick to do this amount of damage. The creep will not be able to do another attack until upgradeBlocked is back to 0."
Will have serious consequences on lower level RCL's. Being able to attack a controller with just a single claim part and having that attack block upgrading for 1000 ticks will have a significant impact on a newer players progress. Also at lower RCL's where the downgrade timers aren't especially long just a few attacks will downgrade a room to a lower level.
"Safe mode activation is not possible when the controller is downgraded for 5000 or more ticks."
This is actually the one that concerns me more because when it comes to wall layouts I only really see two types of layouts, pull everything in and push everything out. Both of these choices come with serious benefits and consequences and I feel as though each favors different situations but they are both overall even. This change will have a major negative impact on pulling the walls in the room in and make the pushing the walls out an all around superior choice. I don't think we want the game mechanics to push everyone down the same path. Where this change will force a lot of players to completely rewrite major sections of their codebase as well as rebuild many of there rooms, it shouldn't be made lightly and I think we should evaluate some of the other options available to either accomplish the same goals or maintain a balance between play styles.
Being able to attack a controller with just a single claim part and having that attack block upgrading for 1000 ticks will have a significant impact on a newer players progress.
If some hostile claimer creep manages to reach your controller, then it deserves to cause some damage.
This change will have a major negative impact on pulling the walls in the room in and make the pushing the walls out an all around superior choice.
I disagree that this change promotes "walls out" style. I would rather say that it promotes building your "bunker" around the controller instead of sources, relying on your storage/terminal for energy supply in case of a siege. And this concept looks much more intuitive than building around energy sources and exposing the controller without any defense.
Awesome changes. They open up some really interesting strategies at all levels.
I don't share Rajecz's concerns. The last months of warfare have shown that bunker style rooms or "walls in" strategy have an edge over walls out.
The bunkers have their own issues (traffic management) that are quite tricky to solve, but at the moment there is no known effective strategy at dealing with a properly managed bunker. On the other hand, there are numerous strategies for dealing with the traditional wall structure. The lack of strategies on tackling effective bunkers is certainly not due to lack of trying mind you.
In any case, this change only requires that bunker rooms be constructed around controllers. It makes the layouting of bunker rooms a more complex problem (the very source of bunker rooms was standardizing layout), but I feel they will still be quite effective. Not to mention that this change only turns the game into a cool tug of war over the controller.
As the defender you still have a healthy edge in ensuring effective control over the room controller.
"upgradeController restores 100 ticks of ticksToDowngrade rather then resets it immediately."
Can you clarify if this is: per WORK part, per creep, or per tick?
@reini This is per tick regardless of creeps and their parts.
Being able to attack a controller with just a single claim part and having that attack block upgrading for 1000 ticks will have a significant impact on a newer players progress
Rajecz how did you reach this conclusion of 1 CLAIM part? It's not stated in the post by artch. The existing .attackController() requires 5 CLAIM parts. The 300*claimParts calculation is for a secondary effect.
@artch Is a change being made to the existing .attackController() such that you no longer need x5 CLAIM parts (minimum)?? The high cost of x5 parts makes sense for the old system AND the new system given the nature of the attack and the implications. Can you confirm if a change is being made to the x5 CLAIM minimum requirement on this call to .attackController() ?
Minimum requirement of 5 parts was due to attack effectiveness of 1 tick per 5 parts. Now it is changed to 300 ticks per 1 part, so the artificial limit is no longer needed.
Yup, thank you! I derped. Thought I was reading loosely worded proposed changes, not the verbatim wording changes to the API docs. I'll keep an eye out on the commit stuff. (omg that Taiwaneese girls footer link thing... LOL ... oh git... )