Summer 2015 Nullsec and Sov Status Report
Posted: Thu May 07, 2015 4:26 pm
http://community.eveonline.com/news/dev ... us-report/
Hello crafty capsuleers! This is CCP Fozzie bringing you another dev blog about our upcoming changes to Nullsec and Sovereignty. This blog is intended to update the community in a few different areas:
Updates to the design thanks in part to the excellent feedback and discussion from the community. This includes some updates that we have already announced on the forums but that some players might have missed, and some completely new updates being unveiled in this blog
Updates to the release schedule for the summer sov changes. To achieve the best possible quality and to ensure that we can continue responding to player ideas and feedback, we have made the decision to spread the release of the Nullsec changes over multiple deployments, one of which has already been released on April 28th, and two more currently scheduled for the Carnyx release in June and the Aegis release in July
A new peek into the most recent Sovereignty UI mockups in development
A reminder and summary of what Nullsec and Sov changes were released on April 28th in our Mosaic release
Before we get started, I want to thank everyone who has provided constructive feedback on the Nullsec and Sov designs so far. Special thanks to those who filled out our time zone mechanics survey.
The Latest Capture System Design
This section of the blog will bring you up to date on the current status of the Sovereignty capture system design. We highly recommend that everyone read and understand our original dev blog covering the first public version of the proposal. These updates build upon the design that was laid out in that blog, and all the goals expressed there still apply.
Entosis Link Module Mechanics
While the basic mechanics and gameplay goals for the Entosis Link were clear in our original dev blog, we were intentionally vague about many details in that document. We then asked the EVE Community to participate in helping us design the ideal Entosis Link details, primarily in the Features and Ideas forum. We received a lot of great feedback in that thread, and together with the EVE community we have put together a much more detailed set of information about the Entosis Link module itself.
So that we’re all on the same page, I’ll spend a little time going over some of the key goals that we are working towards with the Entosis Link module design:
As much as possible, the Entosis Link capture progress should reflect which group has effective military control of the grid.
At its core, the Entosis Link mechanic is a way for the server to tell who won (or is winning) a fight in a specific location. The best way to win a structure or command node with the Entosis Link should be to gain effective control of the grid by simultaneously keeping your forces alive and eliminating your opponents. It’s expected that many fights over structures or nodes should go through a potentially extended period where the grid is effectively contested between multiple sides, and where the capture progress remains paused until one side or another has taken critical losses.
This goal would be broken if certain types of forces could somehow just ignore enemies (for instance, through overwhelming remote repair or through evasion) or if mechanics pushed fights towards indefinite deathless stalemates. This goal is the reason for most of the special restrictions and limitations on the Entosis Link, such as the “no remote reps” rule.
The Entosis Link itself should have the minimum possible effect on what ships and tactics players can choose.
Entosis Links will always have some effect on the types of ships and tactics people find viable for Sov warfare, but we should strive to keep those effects to a minimum. As much as possible, we should work towards a prevailing metagame where whatever fleet concept would win the fight and control the grid would also be viable for using the Entosis Links.
This also means that we don't want to be using the Entosis Links to intentionally manipulate ship use. We've seen some people suggesting that we restrict Entosis Links to battleships, command ships or capital ships in order to buff those classes. Using the Entosis Link mechanics to artificially skew the metagame in that way is not something we are interested in doing.
This goal is why we intend to use the lightest touch possible when working towards the first two goals. It would be easy to overreact to potentially unwanted uses of the Entosis Link by placing extremely harsh restrictions on the module, but we believe that by looking at the situation in a calm and measured manner we can find a good balance.
The restrictions and penalties on the Entosis Link should be as simple and understandable as possible.
This is a fairly obvious goal but I do think it's worth stating explicitly. If we can achieve similar results with two different sets of restrictions and penalties, we'll generally prefer to use the simpler and more understandable set. This also means that we'd generally prefer to use pre-existing mechanics that players will already be familiar with, rather than using completely new mechanics.
We announced this information in a forum thread in the Features and Ideas section, and we’re reprinting it here for visibility.
The most current design details for the Entosis Link Module are:
High Slot module with a limit of one per ship
Requires a target lock on the structure to have any impact
While the module is active, your ship is unable to cloak, warp, dock, jump or receive remote assistance. There is no way to get rid of the module penalties early except for losing your ship
The first cycle of the module is always a "warmup cycle" and has no impact. If you lose lock or the module is disabled for any reason, you'll need to go through that warmup cycle again before you can continue exerting any influence over the structure
Other than that warmup cycle, the cycle time of the module does not impact how long it takes to capture a structure. Once you're past the warmup cycle all that matters is that your module stays active
Capital ships have a role penalty that increases the module cycle time by 5x
Consumes Strontium Clathrates as fuel for each cycle
The Entosis Link comes in two distinct variations: Tech 1 and Tech 2.
T1 Entosis Link:
Requires Infomorph Psychology 1
+250,000kg mass when online
5 Minute Cycle Time
25km range
Fitting requirements: 10 PWG, 1 CPU
Capacitor use: 50 Capacitor per cycle (0.1666 cap/s)
Consumes 1 unit of Strontium Clathrates per cycle
T2 Entosis Link:
Requires Infomorph Psychology 4
+1,000,000kg mass when online
2 Minute Cycle Time
250km range
Fitting requirements: 100 PWG, 10 CPU
500 Capacitor per cycle (4.166 cap/s)
Consumes 1 unit of Strontium Clathrates per cycle
More details about the Entosis Link module mechanics as well as the design goals for the module can be found in this forum thread.
Activity Defense Multiplier Mechanics
The Activity Defense Multiplier is the mechanic that provides defensive advantages from active occupancy of a star system. This is the key mechanic through which we hope to achieve the goal of making unused space easy to conquer and heavily used space hard to conquer.
As described in the last Sov dev blog, this multiplier will be obtained through the existing Sovereignty system indices (Military, Industrial and Strategic), which together will form a collected defensive multiplier.
In-universe, this mechanic represents an advanced AI built into the Sovereignty structures that uses behavioral profiling to determine the difference between benign network access and dangerous intrusions. The more normal baseline activity in the system, the more data available for this AI to use in its intrusion detection system, minimizing system vulnerability and slowing hostile influence.
In practice, the Activity Defense Multiplier slows down the rate of hostile Entosis Link capture for all Sovereignty structures within the star system and all their associated command nodes, allowing defenders more time to respond to attacks and providing a major advantage to the defender when competing in a capture event.
We are making a number of changes to the original designs that increase the effectiveness and importance of this Activity Defensive Multiplier. We believe that these changes will go a long way towards improving the defensive options for alliances that make use of their space and avoid over-extending.
The first significant update to the design is a 50% increase in the maximum activity defense multiplier, from 4x to 6x.
This change allows for much stronger defense of actively used systems, while still ensuring that defenders must undock and actively fight for their space when threatened.
This new cap for the multiplier means that disabling a station service with the Entosis Link would require between 5 minutes and 30 minutes of uncontested linking depending on the system activity level (under the old cap the range was 5-20 minutes) and reinforcing a structure or capturing a hostile command node would take between 10 and 60 minutes of uncontested linking (as opposed to the previous range of 10-40 minutes).
This higher multiplier is especially powerful during the capture events, where the defenders can capture command nodes up to 6x faster than the attackers if they have maximum activity. This allows much more powerful asymmetric warfare for smaller, determined defenders fighting larger attackers, and forces the invader to further split their forces to keep up with the node capture rates of an active defender.
We are also planning to allow multiple paths to reach the activity defense multiplier cap.
One piece of feedback we’ve seen since the reveal of the initial designs is that a cap that matches the top level of all three indices can feel a bit too punishing, as reaching the cap would require the owners of a star system to be equally active in both NPC killing and mining. Ensuring that the cap is reachable without maximum levels of all three indices allows players to play to their strengths and interests without being punished. This also has the effect of increasing the multiplier of the average system, further increasing defender advantage.
With these new changes, the contribution towards the Activity Defense Multiplier for each level of system indices is increased significantly, and the final result is capped at 6x.
The new version of the table listing the bonus provided by the system indices is:
To determine the full bonus applied to each owned structure, find the appropriate value of your current level in each of the three indices and add them together, then add the base value of 1. If the final result is above 6, cap it at 6. The speed at which attackers reinforce or capture structures or command nodes is then divided by that result.
We’ve also created a new version of the example table from the last blog:
You’ll notice that the defensive benefits obtained from all of the system indices have been increased significantly.
The fairly achievable goal of having a Strategic Index of 5, one of Military or Industrial at 5 and the other at 3 is enough to reach the new cap of 6x.
We are also introducing a new mechanic to help alliances defend their home staging systems: designated alliance “capital” systems.
This feature is designed specifically to address the fact that major staging systems are often singularly unsuitable locations for mining or ratting. These systems tend to be some of the busiest in Nullsec space, with many pilots docked and in space, very active markets and strong industrial operations. However they also tend to attract too much attention to make excellent PVE systems, and our first generation Activity Defense Multiplier system will not include contributions from typical capital system activity such as trading and manufacturing. We hope to work towards including these factors in future iterations of the Activity Defense Multiplier mechanic, but in the meantime we need an effective way for alliances to defend their staging systems.
Under this system, each alliance will be able to designate one system as their “capital”. The system they choose must already have an active Territorial Control Unit belonging to their alliance and when changing capitals, the bonuses in the new capital will not take effect for several days. This is intended to prevent alliances from shifting their capitals rapidly to react to invasions or to stabilize newly captured territory.
The capital system for each alliance will provide a flat +2 addition to the Activity Defense Multiplier of all Sovereignty structures owned by that alliance within that system. The cap of 6x multiplier still applies. This allows capital systems to hit the activity multiplier cap much more easily, even in systems that are not particularly safe ratting or mining locations.
If the bonus on this feature is too high there would be danger of alliance intentionally splitting just to get more capital systems, but we currently think that a +2 to the multiplier in a single system isn't so strong that it will push people too hard in that direction. We're of course interested feedback from the community on this feature. If people start abusing this feature by splitting alliances to gain large numbers of capital systems, we will not hesitate to reduce or even remove the bonus.
Vulnerability and Time Zone Mechanics
The designs surrounding vulnerability windows and time zones have been a major area of focus for us over recent months. Time zone safety is an absolutely critical part of any capture system in a worldwide game like EVE Online, and it is also one of the most challenging aspects of the design to get right.
Time zone safe game systems are those that allow players to determine the rough time period in which events can occur and their assets are in danger. They play two crucial roles in a game like EVE:
They prevent players from losing their stuff while they are unavoidably away from the game (work, sleep, etc). Nobody should feel the need to play the game 24/7 in order to be competitive.
They encourage players to show up at the same place at the same time, facilitating multiplayer gameplay. Playing with and outplaying other human beings is the core of EVE, and putting players in contact with each other is a big part of that. If people can fight over an asset without ever coming into contact with each other, we've lost something very valuable.
The initial design for reaching these goals was explained in the previous Sov dev blog, and we have been working with the community to improve and refine the designs from that point. We created a Sovereignty time zone mechanics survey which has been immensely helpful in collecting your feedback. As of now, the survey has received a little over ten thousand responses and we’re extremely grateful to everyone who took the time to participate, especially those of you who filled out the text answers.
We’re ready to announce two significant changes to the earlier vulnerability window design, which we believe will improve the system significantly and address the most crucial player needs expressed in your feedback.
Firstly, it will be possible for alliances to set custom vulnerability timers per structure.
Many players have expressed concerns that the alliance-wide prime time windows will reduce their freedom to designate certain structures and/or areas for defense by certain time zones within their alliance.
Under the new version of the vulnerability window design, each alliance will still have a default prime time set, and all newly captured or deployed structures would take on that default. Once the structure is in place though, the alliance would be able to choose to separate the structure from the default vulnerability timer and set a custom timer.
Changes to the vulnerability timer of a structure will have a delay before taking effect to prevent alliances from shifting timers to dodge enemies.
This system will allow alliances to choose their level of customization. If your alliances wishes, it can keep all Sovereignty structures on the alliance default to keep management simple, or it can spread out vulnerability windows to provide content for members within many different time zones.
In addition, vulnerability windows will now scale in size based on the Activity Defense Multiplier.
This is an idea that was first suggested by Steve Ronuken at the CSM 9 Winter Summit, and has come up quite a few times since in the community feedback. In conjunction with the addition of the alliance capital systems described above, we believe that it has the potential to significantly improve the options for attacking forces in many time zones as well as reinforcing the importance of the Activity Defense Multiplier and active occupancy of Sovereignty systems.
Under the new design, the vulnerability window of each structure would get longer or shorter depending on the activity defensive multiplier of its specific system. The alliance chooses the middle of the window and the window scales in size in both directions from that middle.
The length of the vulnerability window would be 18 hours divided by the activity defensive multiplier (leading to windows ranging in length from 18 hours to 3 hours). Since the timer is divided by the activity index it begins to drop fast as the activity index increases even slightly. A system with Military and Industrial each at 1 would already have shrunk its vulnerability window all the way to 8.18 hours. A system with Military 5 and Strategic 5 (quite common) would have a vulnerability window of 4 hours.
To ensure that players are not surprised by last minute changes in vulnerability windows, the length of each day's vulnerability window will be locked in at the midpoint of the vulnerability window the day before.
Combined, we believe that these updates to the Sovereignty design represent significant improvements that will help ensure that we get the best possible system this summer. Team Five 0 wants to once again express our sincere thanks to every member of the community who has provided us with reasoned feedback.
The Latest Release Schedule
As we have continued to incorporate community feedback into our designs and work on implementing the new system, we have been able to further refine our anticipated deployment schedule for these updates. As we discussed with the community previously, the original estimate was deployment on our June 2nd release, with the expectation that this estimate could change as implementation continued and we received a clearer picture of what work was needed.
We now have that clearer picture and we’re ready to announce that the currently announced changes will be spread across multiple releases. As previously announced, some Sovereignty changes were deployed last week in our Mosaic release.
We are planning to release the rest of the announced features across the upcoming June 2nd and July 7th releases.
The deployment on June 2nd is called the Carnyx release, and will contain the core Entosis Link influence mechanic and the Activity Defense Multiplier mechanic, which will be connected to the enabling and disabling of station services in that first release. We also plan to release the user interface for alliances to manage their default vulnerability window and capital systems, so that they can be selected and ready to go when the rest of the features release.
The deployment on July 7th is called the Aegis released, and will contain the rest of the announced changes. The Entosis Link will be expanded to impact all Sovereignty structures, the vulnerability windows will take effect, and the constellation-wide capture events and Freeport mode mechanics will become active.
This deployment schedule is intended to ensure that we will be able to release the most polished system possible. It also allows any potential issues with the core Entosis Link mechanic to expose themselves with the comparatively low-impact station services.
As part of this schedule update, we now expect that the Singularity test server playtests of the full system will take place in June. More details will be made available as we get closer to the date. We have received quite a few signups for the playtest so far, and we’ll be keeping signups open until downtime on Friday, May 22nd. If your alliance wishes to participate in a competitive playtest of the new Sovereignty capture system on SISI this summer, have your alliance executor corp CEO character send an EVEmail to the character “CCP Fozzie” expressing your interest, as well as a rough estimate of how many players you expect to get in fleets for such a test and information on your primary timezone(s) before downtime on May 22nd. As we announced at Fanfest, the winning alliance will have their alliance name added to the description of the Entosis Link I blueprint as a permanent testament to your contribution.
The Latest Sovereignty UI Designs
Our team is hard at work implementing the new system as well as refining the UI designs that will connect players with Sovereignty and provide them with the information they need to outplay their enemies. Keep in mind that these are work in progress images and there will be details in some of them that aren't correct or that reflect earlier versions of some designs. Here are a few UI mockups showing the latest versions of the UI design work in progress:
This image shows the updated system info panel, including icons for the three sovereignty structures and the Activity Defense Multiplier:
These mockups provide examples of the kinds of information we plan to share in tooltips for the system info panel:
(click image for a larger version)
This image shows the public show-info panel for a nullsec star system:
This image shows the summary window available to members of an alliance, helping them keep track of the status of their alliance’s sovereignty structures:
(click image for a larger version)
Previously, in the Mosaic Release
Those of you who read the forums, watch the o7 show on our Twitch.tv channel, or read the Mosaic release patchnotes already know that a few important improvements were made to the Sovereignty system last week with the Mosaic deployment. I want to quickly highlight these changes here as well, to ensure that every player is completely up to date.
Infrastructure Hub and Infrastructure Upgrade Volumes and Manufacturing
One area changed in the Mosaic release was the Infrastructure Hubs and their Upgrades. We reduced the volume of Infrastructure Hubs and Infrastructure Upgrades so that they can be deployed more easily, and we also made all of the Infrastructure Upgrades manufacturable by players instead of selling them directly from NPCs.
The volumes of IHubs and Upgrades have been reduced to:
Infrastructure Hubs: 60,000 m3
Military/Industrial upgrades: From 5,000 m3 to 60,000 m3 (depending on the level)
Strategic Upgrades: 200,000 m3
This allows IHubs and Military/Industrial upgrades to all be deployed by a wider variety of ships including Deep Space Transports. Strategic Upgrades still require at least a Jump Freighter or Freighter.
To go along with these changes we have enabled the deploying of all structures (including Starbase Control Towers) from fleet hangars, so that ships like Orcas and Deep Space Transports will have more structure deployment options.
We have also made all of the IHub upgrades manufacturable using PI materials. Blueprints are sold by the Empire Navy corporations, and the material requirements consist of Tier 4 PI Commodities and Capital Construction Parts.
More details about these changes can be found in this forum thread.
Ore, Mineral and Nullsec Mining Anomaly Revamp
For the Mosaic release we deployed a huge set of changes to minerals, blueprints and ores aimed at improving nullsec, lowsec, and wormhole mining and enabling stronger nullsec industry. Anyone who has been watching the mineral markets will have already noticed the major impact this shakeup is having on mineral prices.
These changes are intended to make Nullsec more self-sufficient then it is currently. We continue to believe that no area of space should be completely independent of any other, but there is a lot of room to make nullsec more self-sufficient and improve the opportunities for zero-sec miners and industrialists.
These changes consist of three parts:
Increasing Zydrine and Megacyte consumption in manufacturing
Rebalancing the mineral content of the Null and Lowsec focused ores
Rebalancing the ore content of the mining anomalies generated by the Ore Prospecting Array
Increasing Zydrine and Megacyte consumption in manufacturing.
This is a fairly simple change, but it will have some significant effects. As first mentioned on the o7 show, we are doubled the Zydrine and Megacyte consumption of almost all blueprints in the game. This will bring the universe-wide consumption of Zydrine and Megacyte closer to some of the original designs for overall mineral consumption, and will provide a very significant boost to Nullsec (including wormhole) and to a lesser extent Lowsec mining.
Rebalancing the mineral content of the Null and Lowsec focused ores.
This is the big set of changes that will enable a healthier Nullsec mining environment. Each of the "Nullsec ores" have been rebalanced to focus on one main mineral (except for Spodumain which is more widely distributed between four mineral types). This allows us to adjust the supply of each mineral in Nullsec to bring overall balance closer to the actual mineral consumption from the average industry job. It also makes it much easier for players to decide what ore to mine if they find themselves in need of a specific mineral. We are also making somewhat smaller sets of changes to the "Lowsec ores" to clean up their mineral spread and increase their value.
The following values are for a theoretical 100% refine of a batch of each ore type. The upgraded versions of each ore will continue to contain +5% and +10% minerals as they did before. Volumes of each ore did not change in this pass.
Arkonor:
Tritanium: 22000
Mexallon: 2500
Megacyte: 320
Bistot:
Pyerite: 12000
Zydrine: 450
Megacyte: 100
Crokite:
Tritanium: 21000
Nocxium: 760
Zydrine: 135
Dark Ochre:
Tritanium: 10000
Isogen: 1600
Nocxium: 120
Gneiss:
Pyerite: 2200
Mexallon: 2400
Isogen: 300
Spodumain:
Tritanium: 56000
Pyerite: 12050
Mexallon: 2100
Isogen: 450
Mercoxit:
Morphite: 300
Hedbergite:
Pyerite: 1000
Isogen: 200
Nocxium: 100
Zydrine: 19
Hemorphite:
Tritanium: 2200
Isogen: 100
Nocxium: 120
Zydrine: 15
Jaspet:
Mexallon: 350
Nocxium: 75
Zydrine: 8
Rebalancing the ore content of the mining anomalies generated by the Ore Prospecting Array
With these changes, the total mineral supply gained by mining out an entire Ore Prospecting Array anomaly (other than the small belts) will now more closely match the average mineral consumption across the EVE universe, allowing alliances to more easily source the bulk of their raw minerals locally for industrial activities. The relative compositions of each anomaly are slightly different, allowing each corporation or alliance to decide which best matches their personal industrial activities.
Small:
Arkonor: 9600
Bistot: 12800
Crokite: 30000
Dark Ochre: 16000
Gneiss: 170000
Spodumain: 300000
Medium:
Arkonor: 28000
Bistot: 38700
Crokite: 84700
Dark Ochre: 31000
Gneiss: 340000
Spodumain: 270000
Mercoxit: 2600
Large:
Arkonor: 29900
Bistot: 57000
Crokite: 124000
Dark Ochre: 60000
Gneiss: 313500
Spodumain: 368100
Mercoxit: 3500
Enormous:
Arkonor: 58000
Bistot: 86000
Crokite: 169000
Dark Ochre: 50000
Gneiss: 540000
Spodumain: 542000
Mercoxit: 5200
Colossal:
Arkonor: 60800
Bistot: 114300
Crokite: 225200
Dark Ochre: 115000
Gneiss: 630000
Spodumain: 736200
Mercoxit: 7000
The ore compositions of other mining anomalies found within Nullsec, Lowsec, and Wormhole space have not changed, but the mineral changes will cause the value of mining those anomalies to rise significantly as well.
We have also updated the rate at which mining and NPC killing contributes to the current Sovereignty system indices. Since Mosaic, mining now builds the Industrial Index much more quickly than before, and ratting now builds the Military Index slightly slower than before.
Together, these changes represent a huge shift in how minerals are obtained in Nullsec. We have already seen significant increases in overall Nullsec mining volume in the first week since these changes and we hope that many miners will find themselves free to choose between multiple viable locations to ply their trade.
Thanks for joining us for this update dev blog, and I hope you are all as excited as we are to see the results of our upcoming summer releases. As always, we welcome feedback on all the updates described in this blog, as well as all other aspects of the new designs.
-CCP Fozzie on behalf of Team Five 0
Hello crafty capsuleers! This is CCP Fozzie bringing you another dev blog about our upcoming changes to Nullsec and Sovereignty. This blog is intended to update the community in a few different areas:
Updates to the design thanks in part to the excellent feedback and discussion from the community. This includes some updates that we have already announced on the forums but that some players might have missed, and some completely new updates being unveiled in this blog
Updates to the release schedule for the summer sov changes. To achieve the best possible quality and to ensure that we can continue responding to player ideas and feedback, we have made the decision to spread the release of the Nullsec changes over multiple deployments, one of which has already been released on April 28th, and two more currently scheduled for the Carnyx release in June and the Aegis release in July
A new peek into the most recent Sovereignty UI mockups in development
A reminder and summary of what Nullsec and Sov changes were released on April 28th in our Mosaic release
Before we get started, I want to thank everyone who has provided constructive feedback on the Nullsec and Sov designs so far. Special thanks to those who filled out our time zone mechanics survey.
The Latest Capture System Design
This section of the blog will bring you up to date on the current status of the Sovereignty capture system design. We highly recommend that everyone read and understand our original dev blog covering the first public version of the proposal. These updates build upon the design that was laid out in that blog, and all the goals expressed there still apply.
Entosis Link Module Mechanics
While the basic mechanics and gameplay goals for the Entosis Link were clear in our original dev blog, we were intentionally vague about many details in that document. We then asked the EVE Community to participate in helping us design the ideal Entosis Link details, primarily in the Features and Ideas forum. We received a lot of great feedback in that thread, and together with the EVE community we have put together a much more detailed set of information about the Entosis Link module itself.
So that we’re all on the same page, I’ll spend a little time going over some of the key goals that we are working towards with the Entosis Link module design:
As much as possible, the Entosis Link capture progress should reflect which group has effective military control of the grid.
At its core, the Entosis Link mechanic is a way for the server to tell who won (or is winning) a fight in a specific location. The best way to win a structure or command node with the Entosis Link should be to gain effective control of the grid by simultaneously keeping your forces alive and eliminating your opponents. It’s expected that many fights over structures or nodes should go through a potentially extended period where the grid is effectively contested between multiple sides, and where the capture progress remains paused until one side or another has taken critical losses.
This goal would be broken if certain types of forces could somehow just ignore enemies (for instance, through overwhelming remote repair or through evasion) or if mechanics pushed fights towards indefinite deathless stalemates. This goal is the reason for most of the special restrictions and limitations on the Entosis Link, such as the “no remote reps” rule.
The Entosis Link itself should have the minimum possible effect on what ships and tactics players can choose.
Entosis Links will always have some effect on the types of ships and tactics people find viable for Sov warfare, but we should strive to keep those effects to a minimum. As much as possible, we should work towards a prevailing metagame where whatever fleet concept would win the fight and control the grid would also be viable for using the Entosis Links.
This also means that we don't want to be using the Entosis Links to intentionally manipulate ship use. We've seen some people suggesting that we restrict Entosis Links to battleships, command ships or capital ships in order to buff those classes. Using the Entosis Link mechanics to artificially skew the metagame in that way is not something we are interested in doing.
This goal is why we intend to use the lightest touch possible when working towards the first two goals. It would be easy to overreact to potentially unwanted uses of the Entosis Link by placing extremely harsh restrictions on the module, but we believe that by looking at the situation in a calm and measured manner we can find a good balance.
The restrictions and penalties on the Entosis Link should be as simple and understandable as possible.
This is a fairly obvious goal but I do think it's worth stating explicitly. If we can achieve similar results with two different sets of restrictions and penalties, we'll generally prefer to use the simpler and more understandable set. This also means that we'd generally prefer to use pre-existing mechanics that players will already be familiar with, rather than using completely new mechanics.
We announced this information in a forum thread in the Features and Ideas section, and we’re reprinting it here for visibility.
The most current design details for the Entosis Link Module are:
High Slot module with a limit of one per ship
Requires a target lock on the structure to have any impact
While the module is active, your ship is unable to cloak, warp, dock, jump or receive remote assistance. There is no way to get rid of the module penalties early except for losing your ship
The first cycle of the module is always a "warmup cycle" and has no impact. If you lose lock or the module is disabled for any reason, you'll need to go through that warmup cycle again before you can continue exerting any influence over the structure
Other than that warmup cycle, the cycle time of the module does not impact how long it takes to capture a structure. Once you're past the warmup cycle all that matters is that your module stays active
Capital ships have a role penalty that increases the module cycle time by 5x
Consumes Strontium Clathrates as fuel for each cycle
The Entosis Link comes in two distinct variations: Tech 1 and Tech 2.
T1 Entosis Link:
Requires Infomorph Psychology 1
+250,000kg mass when online
5 Minute Cycle Time
25km range
Fitting requirements: 10 PWG, 1 CPU
Capacitor use: 50 Capacitor per cycle (0.1666 cap/s)
Consumes 1 unit of Strontium Clathrates per cycle
T2 Entosis Link:
Requires Infomorph Psychology 4
+1,000,000kg mass when online
2 Minute Cycle Time
250km range
Fitting requirements: 100 PWG, 10 CPU
500 Capacitor per cycle (4.166 cap/s)
Consumes 1 unit of Strontium Clathrates per cycle
More details about the Entosis Link module mechanics as well as the design goals for the module can be found in this forum thread.
Activity Defense Multiplier Mechanics
The Activity Defense Multiplier is the mechanic that provides defensive advantages from active occupancy of a star system. This is the key mechanic through which we hope to achieve the goal of making unused space easy to conquer and heavily used space hard to conquer.
As described in the last Sov dev blog, this multiplier will be obtained through the existing Sovereignty system indices (Military, Industrial and Strategic), which together will form a collected defensive multiplier.
In-universe, this mechanic represents an advanced AI built into the Sovereignty structures that uses behavioral profiling to determine the difference between benign network access and dangerous intrusions. The more normal baseline activity in the system, the more data available for this AI to use in its intrusion detection system, minimizing system vulnerability and slowing hostile influence.
In practice, the Activity Defense Multiplier slows down the rate of hostile Entosis Link capture for all Sovereignty structures within the star system and all their associated command nodes, allowing defenders more time to respond to attacks and providing a major advantage to the defender when competing in a capture event.
We are making a number of changes to the original designs that increase the effectiveness and importance of this Activity Defensive Multiplier. We believe that these changes will go a long way towards improving the defensive options for alliances that make use of their space and avoid over-extending.
The first significant update to the design is a 50% increase in the maximum activity defense multiplier, from 4x to 6x.
This change allows for much stronger defense of actively used systems, while still ensuring that defenders must undock and actively fight for their space when threatened.
This new cap for the multiplier means that disabling a station service with the Entosis Link would require between 5 minutes and 30 minutes of uncontested linking depending on the system activity level (under the old cap the range was 5-20 minutes) and reinforcing a structure or capturing a hostile command node would take between 10 and 60 minutes of uncontested linking (as opposed to the previous range of 10-40 minutes).
This higher multiplier is especially powerful during the capture events, where the defenders can capture command nodes up to 6x faster than the attackers if they have maximum activity. This allows much more powerful asymmetric warfare for smaller, determined defenders fighting larger attackers, and forces the invader to further split their forces to keep up with the node capture rates of an active defender.
We are also planning to allow multiple paths to reach the activity defense multiplier cap.
One piece of feedback we’ve seen since the reveal of the initial designs is that a cap that matches the top level of all three indices can feel a bit too punishing, as reaching the cap would require the owners of a star system to be equally active in both NPC killing and mining. Ensuring that the cap is reachable without maximum levels of all three indices allows players to play to their strengths and interests without being punished. This also has the effect of increasing the multiplier of the average system, further increasing defender advantage.
With these new changes, the contribution towards the Activity Defense Multiplier for each level of system indices is increased significantly, and the final result is capped at 6x.
The new version of the table listing the bonus provided by the system indices is:
To determine the full bonus applied to each owned structure, find the appropriate value of your current level in each of the three indices and add them together, then add the base value of 1. If the final result is above 6, cap it at 6. The speed at which attackers reinforce or capture structures or command nodes is then divided by that result.
We’ve also created a new version of the example table from the last blog:
You’ll notice that the defensive benefits obtained from all of the system indices have been increased significantly.
The fairly achievable goal of having a Strategic Index of 5, one of Military or Industrial at 5 and the other at 3 is enough to reach the new cap of 6x.
We are also introducing a new mechanic to help alliances defend their home staging systems: designated alliance “capital” systems.
This feature is designed specifically to address the fact that major staging systems are often singularly unsuitable locations for mining or ratting. These systems tend to be some of the busiest in Nullsec space, with many pilots docked and in space, very active markets and strong industrial operations. However they also tend to attract too much attention to make excellent PVE systems, and our first generation Activity Defense Multiplier system will not include contributions from typical capital system activity such as trading and manufacturing. We hope to work towards including these factors in future iterations of the Activity Defense Multiplier mechanic, but in the meantime we need an effective way for alliances to defend their staging systems.
Under this system, each alliance will be able to designate one system as their “capital”. The system they choose must already have an active Territorial Control Unit belonging to their alliance and when changing capitals, the bonuses in the new capital will not take effect for several days. This is intended to prevent alliances from shifting their capitals rapidly to react to invasions or to stabilize newly captured territory.
The capital system for each alliance will provide a flat +2 addition to the Activity Defense Multiplier of all Sovereignty structures owned by that alliance within that system. The cap of 6x multiplier still applies. This allows capital systems to hit the activity multiplier cap much more easily, even in systems that are not particularly safe ratting or mining locations.
If the bonus on this feature is too high there would be danger of alliance intentionally splitting just to get more capital systems, but we currently think that a +2 to the multiplier in a single system isn't so strong that it will push people too hard in that direction. We're of course interested feedback from the community on this feature. If people start abusing this feature by splitting alliances to gain large numbers of capital systems, we will not hesitate to reduce or even remove the bonus.
Vulnerability and Time Zone Mechanics
The designs surrounding vulnerability windows and time zones have been a major area of focus for us over recent months. Time zone safety is an absolutely critical part of any capture system in a worldwide game like EVE Online, and it is also one of the most challenging aspects of the design to get right.
Time zone safe game systems are those that allow players to determine the rough time period in which events can occur and their assets are in danger. They play two crucial roles in a game like EVE:
They prevent players from losing their stuff while they are unavoidably away from the game (work, sleep, etc). Nobody should feel the need to play the game 24/7 in order to be competitive.
They encourage players to show up at the same place at the same time, facilitating multiplayer gameplay. Playing with and outplaying other human beings is the core of EVE, and putting players in contact with each other is a big part of that. If people can fight over an asset without ever coming into contact with each other, we've lost something very valuable.
The initial design for reaching these goals was explained in the previous Sov dev blog, and we have been working with the community to improve and refine the designs from that point. We created a Sovereignty time zone mechanics survey which has been immensely helpful in collecting your feedback. As of now, the survey has received a little over ten thousand responses and we’re extremely grateful to everyone who took the time to participate, especially those of you who filled out the text answers.
We’re ready to announce two significant changes to the earlier vulnerability window design, which we believe will improve the system significantly and address the most crucial player needs expressed in your feedback.
Firstly, it will be possible for alliances to set custom vulnerability timers per structure.
Many players have expressed concerns that the alliance-wide prime time windows will reduce their freedom to designate certain structures and/or areas for defense by certain time zones within their alliance.
Under the new version of the vulnerability window design, each alliance will still have a default prime time set, and all newly captured or deployed structures would take on that default. Once the structure is in place though, the alliance would be able to choose to separate the structure from the default vulnerability timer and set a custom timer.
Changes to the vulnerability timer of a structure will have a delay before taking effect to prevent alliances from shifting timers to dodge enemies.
This system will allow alliances to choose their level of customization. If your alliances wishes, it can keep all Sovereignty structures on the alliance default to keep management simple, or it can spread out vulnerability windows to provide content for members within many different time zones.
In addition, vulnerability windows will now scale in size based on the Activity Defense Multiplier.
This is an idea that was first suggested by Steve Ronuken at the CSM 9 Winter Summit, and has come up quite a few times since in the community feedback. In conjunction with the addition of the alliance capital systems described above, we believe that it has the potential to significantly improve the options for attacking forces in many time zones as well as reinforcing the importance of the Activity Defense Multiplier and active occupancy of Sovereignty systems.
Under the new design, the vulnerability window of each structure would get longer or shorter depending on the activity defensive multiplier of its specific system. The alliance chooses the middle of the window and the window scales in size in both directions from that middle.
The length of the vulnerability window would be 18 hours divided by the activity defensive multiplier (leading to windows ranging in length from 18 hours to 3 hours). Since the timer is divided by the activity index it begins to drop fast as the activity index increases even slightly. A system with Military and Industrial each at 1 would already have shrunk its vulnerability window all the way to 8.18 hours. A system with Military 5 and Strategic 5 (quite common) would have a vulnerability window of 4 hours.
To ensure that players are not surprised by last minute changes in vulnerability windows, the length of each day's vulnerability window will be locked in at the midpoint of the vulnerability window the day before.
Combined, we believe that these updates to the Sovereignty design represent significant improvements that will help ensure that we get the best possible system this summer. Team Five 0 wants to once again express our sincere thanks to every member of the community who has provided us with reasoned feedback.
The Latest Release Schedule
As we have continued to incorporate community feedback into our designs and work on implementing the new system, we have been able to further refine our anticipated deployment schedule for these updates. As we discussed with the community previously, the original estimate was deployment on our June 2nd release, with the expectation that this estimate could change as implementation continued and we received a clearer picture of what work was needed.
We now have that clearer picture and we’re ready to announce that the currently announced changes will be spread across multiple releases. As previously announced, some Sovereignty changes were deployed last week in our Mosaic release.
We are planning to release the rest of the announced features across the upcoming June 2nd and July 7th releases.
The deployment on June 2nd is called the Carnyx release, and will contain the core Entosis Link influence mechanic and the Activity Defense Multiplier mechanic, which will be connected to the enabling and disabling of station services in that first release. We also plan to release the user interface for alliances to manage their default vulnerability window and capital systems, so that they can be selected and ready to go when the rest of the features release.
The deployment on July 7th is called the Aegis released, and will contain the rest of the announced changes. The Entosis Link will be expanded to impact all Sovereignty structures, the vulnerability windows will take effect, and the constellation-wide capture events and Freeport mode mechanics will become active.
This deployment schedule is intended to ensure that we will be able to release the most polished system possible. It also allows any potential issues with the core Entosis Link mechanic to expose themselves with the comparatively low-impact station services.
As part of this schedule update, we now expect that the Singularity test server playtests of the full system will take place in June. More details will be made available as we get closer to the date. We have received quite a few signups for the playtest so far, and we’ll be keeping signups open until downtime on Friday, May 22nd. If your alliance wishes to participate in a competitive playtest of the new Sovereignty capture system on SISI this summer, have your alliance executor corp CEO character send an EVEmail to the character “CCP Fozzie” expressing your interest, as well as a rough estimate of how many players you expect to get in fleets for such a test and information on your primary timezone(s) before downtime on May 22nd. As we announced at Fanfest, the winning alliance will have their alliance name added to the description of the Entosis Link I blueprint as a permanent testament to your contribution.
The Latest Sovereignty UI Designs
Our team is hard at work implementing the new system as well as refining the UI designs that will connect players with Sovereignty and provide them with the information they need to outplay their enemies. Keep in mind that these are work in progress images and there will be details in some of them that aren't correct or that reflect earlier versions of some designs. Here are a few UI mockups showing the latest versions of the UI design work in progress:
This image shows the updated system info panel, including icons for the three sovereignty structures and the Activity Defense Multiplier:
These mockups provide examples of the kinds of information we plan to share in tooltips for the system info panel:
(click image for a larger version)
This image shows the public show-info panel for a nullsec star system:
This image shows the summary window available to members of an alliance, helping them keep track of the status of their alliance’s sovereignty structures:
(click image for a larger version)
Previously, in the Mosaic Release
Those of you who read the forums, watch the o7 show on our Twitch.tv channel, or read the Mosaic release patchnotes already know that a few important improvements were made to the Sovereignty system last week with the Mosaic deployment. I want to quickly highlight these changes here as well, to ensure that every player is completely up to date.
Infrastructure Hub and Infrastructure Upgrade Volumes and Manufacturing
One area changed in the Mosaic release was the Infrastructure Hubs and their Upgrades. We reduced the volume of Infrastructure Hubs and Infrastructure Upgrades so that they can be deployed more easily, and we also made all of the Infrastructure Upgrades manufacturable by players instead of selling them directly from NPCs.
The volumes of IHubs and Upgrades have been reduced to:
Infrastructure Hubs: 60,000 m3
Military/Industrial upgrades: From 5,000 m3 to 60,000 m3 (depending on the level)
Strategic Upgrades: 200,000 m3
This allows IHubs and Military/Industrial upgrades to all be deployed by a wider variety of ships including Deep Space Transports. Strategic Upgrades still require at least a Jump Freighter or Freighter.
To go along with these changes we have enabled the deploying of all structures (including Starbase Control Towers) from fleet hangars, so that ships like Orcas and Deep Space Transports will have more structure deployment options.
We have also made all of the IHub upgrades manufacturable using PI materials. Blueprints are sold by the Empire Navy corporations, and the material requirements consist of Tier 4 PI Commodities and Capital Construction Parts.
More details about these changes can be found in this forum thread.
Ore, Mineral and Nullsec Mining Anomaly Revamp
For the Mosaic release we deployed a huge set of changes to minerals, blueprints and ores aimed at improving nullsec, lowsec, and wormhole mining and enabling stronger nullsec industry. Anyone who has been watching the mineral markets will have already noticed the major impact this shakeup is having on mineral prices.
These changes are intended to make Nullsec more self-sufficient then it is currently. We continue to believe that no area of space should be completely independent of any other, but there is a lot of room to make nullsec more self-sufficient and improve the opportunities for zero-sec miners and industrialists.
These changes consist of three parts:
Increasing Zydrine and Megacyte consumption in manufacturing
Rebalancing the mineral content of the Null and Lowsec focused ores
Rebalancing the ore content of the mining anomalies generated by the Ore Prospecting Array
Increasing Zydrine and Megacyte consumption in manufacturing.
This is a fairly simple change, but it will have some significant effects. As first mentioned on the o7 show, we are doubled the Zydrine and Megacyte consumption of almost all blueprints in the game. This will bring the universe-wide consumption of Zydrine and Megacyte closer to some of the original designs for overall mineral consumption, and will provide a very significant boost to Nullsec (including wormhole) and to a lesser extent Lowsec mining.
Rebalancing the mineral content of the Null and Lowsec focused ores.
This is the big set of changes that will enable a healthier Nullsec mining environment. Each of the "Nullsec ores" have been rebalanced to focus on one main mineral (except for Spodumain which is more widely distributed between four mineral types). This allows us to adjust the supply of each mineral in Nullsec to bring overall balance closer to the actual mineral consumption from the average industry job. It also makes it much easier for players to decide what ore to mine if they find themselves in need of a specific mineral. We are also making somewhat smaller sets of changes to the "Lowsec ores" to clean up their mineral spread and increase their value.
The following values are for a theoretical 100% refine of a batch of each ore type. The upgraded versions of each ore will continue to contain +5% and +10% minerals as they did before. Volumes of each ore did not change in this pass.
Arkonor:
Tritanium: 22000
Mexallon: 2500
Megacyte: 320
Bistot:
Pyerite: 12000
Zydrine: 450
Megacyte: 100
Crokite:
Tritanium: 21000
Nocxium: 760
Zydrine: 135
Dark Ochre:
Tritanium: 10000
Isogen: 1600
Nocxium: 120
Gneiss:
Pyerite: 2200
Mexallon: 2400
Isogen: 300
Spodumain:
Tritanium: 56000
Pyerite: 12050
Mexallon: 2100
Isogen: 450
Mercoxit:
Morphite: 300
Hedbergite:
Pyerite: 1000
Isogen: 200
Nocxium: 100
Zydrine: 19
Hemorphite:
Tritanium: 2200
Isogen: 100
Nocxium: 120
Zydrine: 15
Jaspet:
Mexallon: 350
Nocxium: 75
Zydrine: 8
Rebalancing the ore content of the mining anomalies generated by the Ore Prospecting Array
With these changes, the total mineral supply gained by mining out an entire Ore Prospecting Array anomaly (other than the small belts) will now more closely match the average mineral consumption across the EVE universe, allowing alliances to more easily source the bulk of their raw minerals locally for industrial activities. The relative compositions of each anomaly are slightly different, allowing each corporation or alliance to decide which best matches their personal industrial activities.
Small:
Arkonor: 9600
Bistot: 12800
Crokite: 30000
Dark Ochre: 16000
Gneiss: 170000
Spodumain: 300000
Medium:
Arkonor: 28000
Bistot: 38700
Crokite: 84700
Dark Ochre: 31000
Gneiss: 340000
Spodumain: 270000
Mercoxit: 2600
Large:
Arkonor: 29900
Bistot: 57000
Crokite: 124000
Dark Ochre: 60000
Gneiss: 313500
Spodumain: 368100
Mercoxit: 3500
Enormous:
Arkonor: 58000
Bistot: 86000
Crokite: 169000
Dark Ochre: 50000
Gneiss: 540000
Spodumain: 542000
Mercoxit: 5200
Colossal:
Arkonor: 60800
Bistot: 114300
Crokite: 225200
Dark Ochre: 115000
Gneiss: 630000
Spodumain: 736200
Mercoxit: 7000
The ore compositions of other mining anomalies found within Nullsec, Lowsec, and Wormhole space have not changed, but the mineral changes will cause the value of mining those anomalies to rise significantly as well.
We have also updated the rate at which mining and NPC killing contributes to the current Sovereignty system indices. Since Mosaic, mining now builds the Industrial Index much more quickly than before, and ratting now builds the Military Index slightly slower than before.
Together, these changes represent a huge shift in how minerals are obtained in Nullsec. We have already seen significant increases in overall Nullsec mining volume in the first week since these changes and we hope that many miners will find themselves free to choose between multiple viable locations to ply their trade.
Thanks for joining us for this update dev blog, and I hope you are all as excited as we are to see the results of our upcoming summer releases. As always, we welcome feedback on all the updates described in this blog, as well as all other aspects of the new designs.
-CCP Fozzie on behalf of Team Five 0