Pages

Friday, September 8, 2017

A Change For Null Sec Makes High Sec Less Safe

During every campaign for the Council of Stellar Management, we hear claims from null sec candidates that they can represent high sec adequately because they have high sec alts. The counter-argument is that if the choice is between null sec interests or high sec interests, the null sec candidates will choose null sec every time. So I would really love to hear the CSM's reaction to the latest citadel mechanics change coming to EVE with the Lifeblood expansion on 24 October. CCP Fozzie announced the change on the EVE Online forums:
We have been discussing these new structures and their mechanics with all of you in the EVE community for much of the year, including some excellent discussions at Fanfest and with the CSM. One concern that was raised both by Fanfest attendees and the CSM was the risk that current structure deployment mechanics might be abused to “block” the orbital moon mining locations by ninja-deploying a Refinery and forcing their opponents to wait 24hrs (or longer in the case of sovereign nullsec space) to interact with that structure. This is an issue that can apply to all Upwell structures at the moment, but it would be especially vulnerable to abuse with Refineries.

After our discussions with the CSM and the wider community we have decided to make a surgical adjustment to the flow when deploying Upwell structures. As of the Lifeblood release there will be a new 15 minute repair timer immediately after a structure is deployed. It will begin after the structure name, access profile, and vulnerability schedule is chosen but before the 24 hour anchoring period. The existing repair timer at the end of the 24 hour vulnerability period will remain in place.

This means the current flow of:

Drag structure into space -> Choose name, profile and vulnerability schedule -> 24hr anchoring -> 15 minute repair (vulnerable) -> Online

will become:

Drag structure into space -> Choose name, profile and vulnerability schedule -> 15 minute repair (vulnerable) -> 24hr anchoring -> 15 minute repair (vulnerable) -> Online
The blocking of minable moons could become a serious nuisance for null sec alliances because the higher a system's ADM, the longer an attacker's, or in this case, a troll's, refinery takes to anchor. For example, under the current system, in a system which has an ADM of 6, the anchoring process would take 7 days before the system's owner could attack the citadel to remove the structure. Trolls could deny a sov holder of 7 days worth of moon mineral income during the initial land rush that Lifeblood will introduce.

Activity Defense Modifiers In Delve
Did CCP need to do something about the situation? Yes. The mechanic was broken from its inception, but never really mattered until now. However, did the fix really have to affect high sec? No.

Currently, if a high sec corporation drops a citadel, they have to hope a high sec wardec alliance doesn't see the deployment for the first 15 minutes. If they do, the wardec alliance issues a wardec and gets a chance to attack a deploying citadel. If the structure goes unnoticed for the first 15 minutes, then a wardec alliance will have to attack a fully functioning and fitted citadel. My understanding is that, unless the citadel is located in a strategically located system, the wardec alliance won't bother.

The change, as described by CCP Fozzie, adds an extra 15 minutes for wardeccers to find deploying structures and issue a wardec. Did CCP intend to double the effective vulnerability time for deploying a structure in high sec? Couldn't CCP just shorten the 24 hour invulnerable anchoring period to 23 hours and 45 minutes?

In my opinion, CCP never intended for individuals in one-man corporations to own citadels, and the POS before them. The mechanics of the POS just lent themselves to avoiding the war declaration system and high sec residents want the same ability with citadels. A resident of null sec would have no sympathy for such an attitude. I wonder if any expressed an argument to avoid the increase at all.

No comments:

Post a Comment