Citadels, sieges and you
Posted: Thu Aug 13, 2015 3:00 pm
http://community.eveonline.com/news/dev ... s-and-you/
Hello again dear spacebros and welcome back to another structure blog by Team Game of Drones. Time has passed since we last discussed upcoming new structures (Fanfest 2015 and shortly thereafter), which we have spent reading feedback and iterating on concepts. More importantly we have been busy coming up with more detailed answers on the following two questions, which are the most heated topics you wish to see explained regarding this specific feature:
How exactly am I going to attack, or protect, one of those new structures?
What happens to my stuff if one of those structures has been attacked?
We now have a refined version of how those systems are going to work and are ready to share them with you. However, to avoid heart attacks, eye gouging or bleach drinking we are going to focus this blog on answering point 1, while another blog is to follow on point 2. For all the math wizards, min-maxers extraordinaire, and OCD freaks out there, numbers will be provided, but please remember those aren’t final and will most likely change based on player feedback, testing and various iterations.
Missed a structure blog? Have a look at the following:
Back into the structure - Blog introducing the structure changes and long term plan.
Shake my Citadel - Blog listing the first structure class to be worked on, as well as general mechanics.
I feel safe in Citadel city - Blog outlining the asset safety mechanics once a Citadel got destroyed.
CSM Citadel FAQ - A detailed FAQ covering all important aspects of the new structures. Compiled by the CSM in conjunction with CCP. Available in English only.
Capture process
As mentioned in Shake my Citadel, new structures are going to use mechanics similar to the revamped Sovereignty system, with a twist to fit our own needs. This naturally implies vulnerable and reinforced states.
All Citadels, no matter their size, will have 3 vulnerability windows. They are supposed to be the safest structures around, and thus provide the longest defense buffer available to owners. Please note this will not be true of all structures. Observatory arrays may have only 2 for example, since they are supposed to be more fragile.
Also, there will be no Command Node spawning under this system – CSM feedback showed it was quite counter-intuitive to fit big guns to your massive structure only to have the fight take place somewhere else.
With the chart below, we are going to go into details how each phase is going to work.
Deployment
All structures will have a deployment time, which will vary depending on the structure size and type. The larger or more impact on the surrounding the structure has, the more time is going to be needed in an effort to give various parties more time to react.
A new structure that is being deployed is totally vulnerable to entosis links, and any third party can come to disrupt it (for high-security space however, a war declaration is required not to suffer the wrath of CONCORD). The exact details on the attack process are explained under the “entosis link contest” below.
Current numbers to deploy Citadels, our first batch of structures, are:
M
L
XL
Citadel deployment timer
1 hour
2 hours
4 hours
Please note those do not require downtime to proceed, unlike existing outposts. It is also important to remember that scooping a structure will cause an immediate and full vulnerability window to begin. If a vulnerability window was already underway, it will refresh the duration to its maximum value. A structure going through a reinforcement timer cannot be scooped until it comes out of it.
Vulnerable 1
A structure that is successfully deployed then enters normal operation mode. Players may use its services, dock, man the defenses or do whatever else is allowed by them. The structure also becomes vulnerable to attack during specific times.
In more details that means:
Structures may only be attacked by entosis links during their vulnerability windows.
The duration of a vulnerable 1 window is a mandatory timer expressed on a weekly basis, whose length varies depending on the structure size, location and role.
This phase happens periodically while the structure is working normally and has not be set into reinforcement yet.
Players owning the structures set the vulnerability time themselves (if they have enough roles) – this can be done in advance, before deploying the structure.
Attacking a structure in high-security space without a war declaration is a bad idea and thus gives you a criminal flag. It is like trying to add pineapples to a pizza (which is one of the many barbaric traditions a Frenchman must endure in Iceland).
How players assign weekly vulnerability hours is entirely up to them, as long as they fill the quota. You could assign all hours consecutively if you dispose of enough manpower, or you could spread them out over multiple days. Hours have to be spent whole however, no weird split minute shenanigan is allowed.
Example 1:
Soft Croissant Incorporated™ is a small 5 man corporation having a Citadel L structure in high security space with a 6 hours of weekly vulnerability window. Not being a hardcore gamer, the structure owner decides to set the vulnerability window 2 hours during Tuesday evening and 4 hours on Saturday.
Example 2:
The Alluring Baguette Syndicate™ is a large alliance that just deployed a Citadel XL structure in null security space with a 21 hours of weekly vulnerability window (they have full occupancy and indexes). Confident of its manpower and general resources, the structure owner sets the vulnerability window to cover 3 hours each day of the week.
Current numbers for the weekly vulnerability window are set as follows and varies based on location or occupancy. Those numbers will most likely change with time.
M
L
XL
High-sec, low-sec, Null-sec with full occupancy
3 hours
6 hours
21 hours
Wormhole space
6 hours
12 hours
42 hours
Null-sec without occupancy
12 hours
24 hours
84 hours
Reinforced 1, 2, and 3
Structures that are successfully attacked through entosis links during their vulnerability windows go into an invulnerable mode for a specific amount of time, at the end of which another vulnerability window may occur.
Reinforcement periods exist to pause the assault and give both attacking and defending parties time to prepare for the next phase, especially if they do not operate within the same timezones.
They also serve to give penalties to the structure owner. A structure entering its first reinforcement window cannot have its fittings altered – players will still be able to refuel its various bays, fit ammunition to the various defense systems or take items in or out of its hangars, but will unable to add, remove or change fitted structure modules in any way. A structure entering its second reinforcement window will cause all industry jobs to be paused and services to go offline on top of the previous penalty. Those penalties will exist until the structure goes back into its normal operation mode (thus until defenders successfully entosis it).
Reinforcement will not require Strontium Clathrates to operate, and will be a functionality that’s always available on all structures for free.
Reinforcement timers last for a specific amount of vulnerability hours:
Unlike existing Starbase reinforcement timers, those reinforcement timers are based on vulnerability hours to operate. This is to ensure the reinforcement timer always ends during a vulnerability window, when defenders are online and committed to defend it.
Reinforcement duration may change depending on the structure type and size – larger structures may have a reinforcement timer set to half the vulnerability window, while smaller ones may have longer reinforcement timers to give owners more time to react.
Example:
The Mighty Bouillabaisse Conglomerate™ has a Citadel XL structure in null-security space, with full occupancy and indexes. The vulnerability window thus lasts 21 hours a week, which has been assigned by the structure owner (yellow duration below).
If a party attacks the structure with an entosis link during the vulnerability window at 15 GMT on Saturday (red box below), the reinforcement timer, which lasts 15 vulnerability hours, will end at 20 GMT on the following Tuesday (green part below).
The Citadel XL structure will thus enter its second vulnerability window at 20 GMT, next Tuesday after the initial attack. When the structure goes into reinforcement, the timer will display that date for everyone instead of doing complex math with vulnerability hours.
Vulnerable 2 and 3
This type of vulnerability window does not appear in a regular operation state, and is a reactionary state appearing once the structure has been set into reinforcement at least once.
Those windows automatically appear after the structure comes out of a reinforcement period.
This vulnerability window lasts indefinitely, until an attacker or defender wins the contest by using entosis links (see “entosis link contest” further below).
Except for their duration, they work exactly the same than the vulnerable 1 phase.
Entosis link contest
Entosis links are needed to be able to attack (or defend) a structure during its deployment or vulnerability window.
The process is as follow:
A structure that is successfully attacked by an entosis link during its vulnerability window goes into reinforcement. If it was being deployed, or if that was the last vulnerability window it was capable of withstanding, the structure is destroyed instead.
A structure that is partially contested with an entosis link will delay the vulnerability or deployment timer indefinitely, until such time where the owner uses his own entosis link to remove the contested status, or an attacker chooses to fully attack it. The duration will however count toward the vulnerability or deployment timer – a structure that needs 4 hours to be deployed, but is stuck in a contested state for 5 days can be immediately deployed if the owner removes this particular status with his own entosis link.
The entosis contest time will vary depending on the location where the battle takes place and if you are attacking or defending.
High, low-sec and null-sec with full indexes
Wormhole space
Null sec with no indexes
Attacking a structure
60 minutes
30 minutes
10 minutes
Defending a structure
10 minutes
10 minutes
10 minutes
Example:
The Daring Tartiflette Expedition™ is a corporation having a Citadel L deployed in a random wormhole.
Anyone attacking their structure when it is being deployed, or in its vulnerability phase will need full 30 minutes to win the entosis link contest.
For being the owners of the structure and defending it, the Daring Tartiflette Expedition™’s members will only need 10 minutes of entosis linking to defend it, or to fully remove its contested status.
Please note that if the Daring Tartiflette Expedition™ was to attack a structure belonging to another corporation in their wormhole, they would have to go through a 30 minutes entosis link timer themselves.
Visibility
We also want to make sure all the previous states and phases are properly represented in the game.
As such:
Corporation members with enough roles to do so will have full information on vulnerability, reinforcement, capture timers. Notifications will be sent for those particular states to make sure people can respond and defend their structures in a timely manner.
Any external party to the corporation will only be able to see the timer related to the current state. For example, a scout may learn the structure is in reinforced state 2, with 5 hours left on it by going to the solar system where the structure is located. However the same scout will not be able to guess how the vulnerability window is weekly set. In the same manner, we want to avoid automation for this particular information, which means not displaying it in the API, since we want people to actively scout, or infiltrate spies in the target entity they wish to disrupt instead of relying on external tools to do the job for them.
Structure brackets are going to be visible in space and in the overview if:
The user can interact with the structure in question. A structure set to accept neutral parties will be displayed publicly for such pilots. Another structure set for alliance use only will not appear to any neutral pilot at all.
The structure itself disrupts the user in any way. An Observatory Array having adverse effects on a pilot ability to probe or scan will appear to anyone.
On top of the points above, all structures, no matter their size or role, will have warpable signatures like cosmic combat anomalies. None of them will need to be probed to be warped to, even if the user doesn’t have direct access to them. This will ensure pilots can quickly see what’s happening in their surroundings without having to use probes, and thus not having to give their position away to the inhabitants.
Death is only the beginning
And that’s it on how to attack and defend structures. Please remember most of this is subject to change based on feedback and time, even if we’re are starting to see the light at the end of the tunnel. We would also like to thank the CSM for their time reviewing this particular feature with us. As mentioned at the beginning, our next blog is going to focus on asset safety, or what’s happening to your stuff when a structure blows up.
In the meantime, happy hunting and may the odds be in your favor.
Hello again dear spacebros and welcome back to another structure blog by Team Game of Drones. Time has passed since we last discussed upcoming new structures (Fanfest 2015 and shortly thereafter), which we have spent reading feedback and iterating on concepts. More importantly we have been busy coming up with more detailed answers on the following two questions, which are the most heated topics you wish to see explained regarding this specific feature:
How exactly am I going to attack, or protect, one of those new structures?
What happens to my stuff if one of those structures has been attacked?
We now have a refined version of how those systems are going to work and are ready to share them with you. However, to avoid heart attacks, eye gouging or bleach drinking we are going to focus this blog on answering point 1, while another blog is to follow on point 2. For all the math wizards, min-maxers extraordinaire, and OCD freaks out there, numbers will be provided, but please remember those aren’t final and will most likely change based on player feedback, testing and various iterations.
Missed a structure blog? Have a look at the following:
Back into the structure - Blog introducing the structure changes and long term plan.
Shake my Citadel - Blog listing the first structure class to be worked on, as well as general mechanics.
I feel safe in Citadel city - Blog outlining the asset safety mechanics once a Citadel got destroyed.
CSM Citadel FAQ - A detailed FAQ covering all important aspects of the new structures. Compiled by the CSM in conjunction with CCP. Available in English only.
Capture process
As mentioned in Shake my Citadel, new structures are going to use mechanics similar to the revamped Sovereignty system, with a twist to fit our own needs. This naturally implies vulnerable and reinforced states.
All Citadels, no matter their size, will have 3 vulnerability windows. They are supposed to be the safest structures around, and thus provide the longest defense buffer available to owners. Please note this will not be true of all structures. Observatory arrays may have only 2 for example, since they are supposed to be more fragile.
Also, there will be no Command Node spawning under this system – CSM feedback showed it was quite counter-intuitive to fit big guns to your massive structure only to have the fight take place somewhere else.
With the chart below, we are going to go into details how each phase is going to work.
Deployment
All structures will have a deployment time, which will vary depending on the structure size and type. The larger or more impact on the surrounding the structure has, the more time is going to be needed in an effort to give various parties more time to react.
A new structure that is being deployed is totally vulnerable to entosis links, and any third party can come to disrupt it (for high-security space however, a war declaration is required not to suffer the wrath of CONCORD). The exact details on the attack process are explained under the “entosis link contest” below.
Current numbers to deploy Citadels, our first batch of structures, are:
M
L
XL
Citadel deployment timer
1 hour
2 hours
4 hours
Please note those do not require downtime to proceed, unlike existing outposts. It is also important to remember that scooping a structure will cause an immediate and full vulnerability window to begin. If a vulnerability window was already underway, it will refresh the duration to its maximum value. A structure going through a reinforcement timer cannot be scooped until it comes out of it.
Vulnerable 1
A structure that is successfully deployed then enters normal operation mode. Players may use its services, dock, man the defenses or do whatever else is allowed by them. The structure also becomes vulnerable to attack during specific times.
In more details that means:
Structures may only be attacked by entosis links during their vulnerability windows.
The duration of a vulnerable 1 window is a mandatory timer expressed on a weekly basis, whose length varies depending on the structure size, location and role.
This phase happens periodically while the structure is working normally and has not be set into reinforcement yet.
Players owning the structures set the vulnerability time themselves (if they have enough roles) – this can be done in advance, before deploying the structure.
Attacking a structure in high-security space without a war declaration is a bad idea and thus gives you a criminal flag. It is like trying to add pineapples to a pizza (which is one of the many barbaric traditions a Frenchman must endure in Iceland).
How players assign weekly vulnerability hours is entirely up to them, as long as they fill the quota. You could assign all hours consecutively if you dispose of enough manpower, or you could spread them out over multiple days. Hours have to be spent whole however, no weird split minute shenanigan is allowed.
Example 1:
Soft Croissant Incorporated™ is a small 5 man corporation having a Citadel L structure in high security space with a 6 hours of weekly vulnerability window. Not being a hardcore gamer, the structure owner decides to set the vulnerability window 2 hours during Tuesday evening and 4 hours on Saturday.
Example 2:
The Alluring Baguette Syndicate™ is a large alliance that just deployed a Citadel XL structure in null security space with a 21 hours of weekly vulnerability window (they have full occupancy and indexes). Confident of its manpower and general resources, the structure owner sets the vulnerability window to cover 3 hours each day of the week.
Current numbers for the weekly vulnerability window are set as follows and varies based on location or occupancy. Those numbers will most likely change with time.
M
L
XL
High-sec, low-sec, Null-sec with full occupancy
3 hours
6 hours
21 hours
Wormhole space
6 hours
12 hours
42 hours
Null-sec without occupancy
12 hours
24 hours
84 hours
Reinforced 1, 2, and 3
Structures that are successfully attacked through entosis links during their vulnerability windows go into an invulnerable mode for a specific amount of time, at the end of which another vulnerability window may occur.
Reinforcement periods exist to pause the assault and give both attacking and defending parties time to prepare for the next phase, especially if they do not operate within the same timezones.
They also serve to give penalties to the structure owner. A structure entering its first reinforcement window cannot have its fittings altered – players will still be able to refuel its various bays, fit ammunition to the various defense systems or take items in or out of its hangars, but will unable to add, remove or change fitted structure modules in any way. A structure entering its second reinforcement window will cause all industry jobs to be paused and services to go offline on top of the previous penalty. Those penalties will exist until the structure goes back into its normal operation mode (thus until defenders successfully entosis it).
Reinforcement will not require Strontium Clathrates to operate, and will be a functionality that’s always available on all structures for free.
Reinforcement timers last for a specific amount of vulnerability hours:
Unlike existing Starbase reinforcement timers, those reinforcement timers are based on vulnerability hours to operate. This is to ensure the reinforcement timer always ends during a vulnerability window, when defenders are online and committed to defend it.
Reinforcement duration may change depending on the structure type and size – larger structures may have a reinforcement timer set to half the vulnerability window, while smaller ones may have longer reinforcement timers to give owners more time to react.
Example:
The Mighty Bouillabaisse Conglomerate™ has a Citadel XL structure in null-security space, with full occupancy and indexes. The vulnerability window thus lasts 21 hours a week, which has been assigned by the structure owner (yellow duration below).
If a party attacks the structure with an entosis link during the vulnerability window at 15 GMT on Saturday (red box below), the reinforcement timer, which lasts 15 vulnerability hours, will end at 20 GMT on the following Tuesday (green part below).
The Citadel XL structure will thus enter its second vulnerability window at 20 GMT, next Tuesday after the initial attack. When the structure goes into reinforcement, the timer will display that date for everyone instead of doing complex math with vulnerability hours.
Vulnerable 2 and 3
This type of vulnerability window does not appear in a regular operation state, and is a reactionary state appearing once the structure has been set into reinforcement at least once.
Those windows automatically appear after the structure comes out of a reinforcement period.
This vulnerability window lasts indefinitely, until an attacker or defender wins the contest by using entosis links (see “entosis link contest” further below).
Except for their duration, they work exactly the same than the vulnerable 1 phase.
Entosis link contest
Entosis links are needed to be able to attack (or defend) a structure during its deployment or vulnerability window.
The process is as follow:
A structure that is successfully attacked by an entosis link during its vulnerability window goes into reinforcement. If it was being deployed, or if that was the last vulnerability window it was capable of withstanding, the structure is destroyed instead.
A structure that is partially contested with an entosis link will delay the vulnerability or deployment timer indefinitely, until such time where the owner uses his own entosis link to remove the contested status, or an attacker chooses to fully attack it. The duration will however count toward the vulnerability or deployment timer – a structure that needs 4 hours to be deployed, but is stuck in a contested state for 5 days can be immediately deployed if the owner removes this particular status with his own entosis link.
The entosis contest time will vary depending on the location where the battle takes place and if you are attacking or defending.
High, low-sec and null-sec with full indexes
Wormhole space
Null sec with no indexes
Attacking a structure
60 minutes
30 minutes
10 minutes
Defending a structure
10 minutes
10 minutes
10 minutes
Example:
The Daring Tartiflette Expedition™ is a corporation having a Citadel L deployed in a random wormhole.
Anyone attacking their structure when it is being deployed, or in its vulnerability phase will need full 30 minutes to win the entosis link contest.
For being the owners of the structure and defending it, the Daring Tartiflette Expedition™’s members will only need 10 minutes of entosis linking to defend it, or to fully remove its contested status.
Please note that if the Daring Tartiflette Expedition™ was to attack a structure belonging to another corporation in their wormhole, they would have to go through a 30 minutes entosis link timer themselves.
Visibility
We also want to make sure all the previous states and phases are properly represented in the game.
As such:
Corporation members with enough roles to do so will have full information on vulnerability, reinforcement, capture timers. Notifications will be sent for those particular states to make sure people can respond and defend their structures in a timely manner.
Any external party to the corporation will only be able to see the timer related to the current state. For example, a scout may learn the structure is in reinforced state 2, with 5 hours left on it by going to the solar system where the structure is located. However the same scout will not be able to guess how the vulnerability window is weekly set. In the same manner, we want to avoid automation for this particular information, which means not displaying it in the API, since we want people to actively scout, or infiltrate spies in the target entity they wish to disrupt instead of relying on external tools to do the job for them.
Structure brackets are going to be visible in space and in the overview if:
The user can interact with the structure in question. A structure set to accept neutral parties will be displayed publicly for such pilots. Another structure set for alliance use only will not appear to any neutral pilot at all.
The structure itself disrupts the user in any way. An Observatory Array having adverse effects on a pilot ability to probe or scan will appear to anyone.
On top of the points above, all structures, no matter their size or role, will have warpable signatures like cosmic combat anomalies. None of them will need to be probed to be warped to, even if the user doesn’t have direct access to them. This will ensure pilots can quickly see what’s happening in their surroundings without having to use probes, and thus not having to give their position away to the inhabitants.
Death is only the beginning
And that’s it on how to attack and defend structures. Please remember most of this is subject to change based on feedback and time, even if we’re are starting to see the light at the end of the tunnel. We would also like to thank the CSM for their time reviewing this particular feature with us. As mentioned at the beginning, our next blog is going to focus on asset safety, or what’s happening to your stuff when a structure blows up.
In the meantime, happy hunting and may the odds be in your favor.