Difference between revisions of "SovMechanics"
m (changed from cleanup to update tag) |
(Redirected page to Sovereignty) |
||
(4 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
− | + | #REDIRECT [[Sovereignty]] | |
− | [[ | ||
− | |||
− | |||
== Class Information == | == Class Information == | ||
Line 35: | Line 32: | ||
=== Notes for the Teacher === | === Notes for the Teacher === | ||
Required materials: | Required materials: | ||
− | * | + | * Lecture.E-UNI chat channel, to receive questions and post relevant links |
* Minimum of one sovereign system claimed by EVE University to demonstrate sov benefits, and another claimed by the "enemy" corp | * Minimum of one sovereign system claimed by EVE University to demonstrate sov benefits, and another claimed by the "enemy" corp | ||
* Sufficient enemy forces for a simulated battle against students (these can be assistants or the teacher's alts--I have previously used this as a demonstration of capital and supercapital ships when available, which has a couple of added benefits in that it allows a small number of characters to be a major threat to the students, and it's just plain fun) | * Sufficient enemy forces for a simulated battle against students (these can be assistants or the teacher's alts--I have previously used this as a demonstration of capital and supercapital ships when available, which has a couple of added benefits in that it allows a small number of characters to be a major threat to the students, and it's just plain fun) | ||
This class is intended to be used with a simulation of a simple sov warfare scenario. As such, it is meant to be held on the Singularity test server to allow the students to participate in combat that would violate the EVE University Rules of Engagement if done on the live server. If the simulation is eliminated, the lecture-only class may be held on the live server. | This class is intended to be used with a simulation of a simple sov warfare scenario. As such, it is meant to be held on the Singularity test server to allow the students to participate in combat that would violate the EVE University Rules of Engagement if done on the live server. If the simulation is eliminated, the lecture-only class may be held on the live server. | ||
+ | |||
== Class Contents == | == Class Contents == | ||
Latest revision as of 10:28, 11 January 2017
Redirect to:
Class Information
Sovereignty Mechanics 1 (Original class design by Zevin Rialto)
Summary:
- What is sovereignty/what benefits does it grant?
- How can I claim sovereignty? What do I need?
- How can I take a system away from someone else?
- How can I defend my system when someone tries to take it from me?
- What is an Infrastructure Hub? What does it do for me?
General Information
Nullsec Infrastructure I: The Mechanics of Sovereignty is an introduction to the mechanics of the sovereignty system in claimable nullsec space. Upon completing this class, students should be able to understand the benefits of sovereignty, identify where it can and cannot be claimed, determine how to claim an unclaimed system, and understand the basics of sov warfare.
- Duration: 2-3 hours
- Location: Sovereign nullsec systems to be determined by the instructor (ON SINGULARITY)
Class contents:
- What is sovereignty?
- Benefits of sovereignty
- Claiming an unclaimed system
- Capturing a system claimed by someone else
- Defending your space from attack
[* Practical exercise]
Student requirements:
- Mumble registration and access - make sure you have Mumble sorted out and operational well before the class begins. Use this guide for set-up: http://wiki.eveuniversity.org/Mumble
- Access to the Singularity test server (needed to take part in the practical simulation, but those who can't access SiSi can still listen to the lecture)
Notes for the Teacher
Required materials:
- Lecture.E-UNI chat channel, to receive questions and post relevant links
- Minimum of one sovereign system claimed by EVE University to demonstrate sov benefits, and another claimed by the "enemy" corp
- Sufficient enemy forces for a simulated battle against students (these can be assistants or the teacher's alts--I have previously used this as a demonstration of capital and supercapital ships when available, which has a couple of added benefits in that it allows a small number of characters to be a major threat to the students, and it's just plain fun)
This class is intended to be used with a simulation of a simple sov warfare scenario. As such, it is meant to be held on the Singularity test server to allow the students to participate in combat that would violate the EVE University Rules of Engagement if done on the live server. If the simulation is eliminated, the lecture-only class may be held on the live server.
Class Contents
Introduction
Welcome to Nullsec Infrastructure I: The Mechanics of Sovereignty. Over the next 2-3 hours we'll learn about what sovereignty is and how it works in relation to game mechanics. This class will not cover the politics or diplomacy of sovereign space. Nullsec Infrastructure II: Outposts and Jump Bridges will cover those topics in more detail, since they're a bit too complicated to fit into an introductory class.
Sovereignty is one of the great driving forces in the relationships among powerful entities in nullsec space. Its benefits motivate massive wars between the largest alliances and coalitions in New Eden, all vying for sovereignty over the most lucrative systems in nullsec. An understanding of sovereignty is vital for anyone who wants to live in nullsec or simply has an interest in the politics and workings of nullsec alliances.
This class involves a concept that's not often used in Uni classes: a scripted series of events in which you, the students, will participate in order to experience for yourselves as much as possible of the information covered in the class. This amounts to a simulation of dealing with a particular situation that will allow us to see much of what this class discusses first-hand (though admittedly one or two of the events you see may be a little far-fetched).
The fictional situation is as follows: the Uni's leaders have decided to take another try at claiming sovereignty. (For those who weren't aware, the Uni used to be part of a sov-holding alliance known as The Big Blue, but ran afoul of some of the bigger nullsec powers of the time and was eventually forced out). Our fleet has been instructed to learn about the basics of sovereignty and then look into the possibility of expanding our territory by taking nearby systems from their current owners. I am your fleet commander, and am authorized to exercise my judgment in deciding whether to attack. Are there any questions on this before we start?
What is Sovereignty?
Sovereignty, put simply, is official control of a system, recognized by the EVE client. In in-universe terms, non-Empire alliances use Territorial Claim Units to assert their control over systems not claimed by any major faction, and can continue to control such systems as long as no one acts to stop them. Along with making the system owners' POS structures use 25% less fuel, sovereignty allows an alliance to publicly declare its ownership of a system, to construct outposts, and to install powerful upgrades in the Infrastructure Hub. These upgrades can cause a system to become a better source of income, give the alliance new options for defense, and even allow the construction of mighty supercapital ships.
How Can I Claim Sovereignty?
- The entity that controls an online Territorial Claim Unit (TCU) in a system owns that system.--This is really important, we'll return to it throughout the class
Requirements to claim a system
- You must be in a player corporation (not an NPC corp)
- Your corp must be in an alliance
- You must have the appropriate corp roles: Config Starbase Equipment or Station Manager
- You must have the skill Anchoring trained to at least Level I
- You must have a target system that is in sovereign nullsec and is not currently claimed by someone else (we'll talk about taking sovereignty later, but the system must be unclaimed before you can claim it--sov warfare revolves around making the system unclaimed so you can then take it for yourself)
- Once this is completed, anchor a Territorial Claim Unit anywhere in the system and online it. Once it's online, your alliance and corporation hold sovereignty over that system. Note that a sovereignty bill will be charged to your corporation while the TCU is onlining, and if it isn't paid by the time it's online the process will fail and you'll have to start over.
So What? What Does It Do for Me?
Now that you control the system, all of your POS towers in this system use 25% less fuel. More importantly, you can anchor an Infrastructure Hub to install upgrades that improve different aspects of your system. There are three categories of upgrades: Industrial, Military, and Strategic. Each category has a Development Index of the same name, and you must have a high enough level of the appropriate index to install each upgrade. Note that these indices can only be improved if there is an active I-Hub in the system, so don't try to build them up before you anchor the Hub. Once installed, upgrades cannot be removed without destroying them. If the relevant index drops below the required level, the upgrade is turned off, but not destroyed, and it will automatically start working again once the index is increased.
Industrial
- Index is based on the amount of ore mined in the system each day (from downtime to downtime), averaged over the last several days. It doesn't matter who mines the ore, which type(s), or where in the system it's mined (e.g. belts vs. grav sites).
- Both types of Industrial upgrades have five levels, one for each level of the index. Along with the appropriate index level, all lower levels of the same upgrade are required (e.g. you can't install an Ore Prospecting Array IV unless you have an Industrial Index of IV or higher and Ore Prospecting Arrays I-III installed).
- Ore Prospecting Array--creates gravimetric sites (hidden asteroid belts that can be found with core scanner probes). Each level creates one specific belt that's always the same (e.g. Ore Prospecting Array I creates a Small Asteroid Cluster, which always spawns with the same number and type of asteroids). All five contain all ores up to and including Arkonor, and levels 3 and above also contain Mercoxit. If one belt is completely mined out, an identical one will respawn in the same system within a few minutes. (It can be fun to take the students to the Small Asteroid Cluster to see the gigantic Spodumain asteroid nicknamed "The Spod." This is the largest asteroid that appears anywhere in the game, and contains more ore than can fit in a maxed-out Charon, the largest cargo capacity of any ship in the game.)
- Survey Network--increases the chance of mini-profession (salvaging, hacking, archaeology) sites spawning in the system.
Military
- Index is similar to Industrial except based on the number of NPCs killed in the system.
- Pirate Detection Array--increases the number of active combat sites in the system (specifically, each level creates at least four additional sites). The term "active" means that if one site is completed, a replacement spawns immediately. Note that this is affected by the truesec level of the system, so a -0.1 system will still never have Sanctums. However, the higher-level upgrades will tend to produce higher-level sites within the constraints of truesec.
- Entrapment Array--increases the chances of DED complexes spawning in the system. Along with the Military Index requirement, the Entrapment Array I also requires a Pirate Detection Array III installed.
- Quantum Flux Generator--increases the chances of wormholes spawning in the system. These tend to be very unpopular due to the risk of enemies arriving behind the alliance's defensive lines without warning.
Strategic
- Based solely on the amount of time the alliance has continuously held sov. As such, this is the only one of the three indices that can never go down unless you lose sov (in which case it instantly resets to zero). This one also does absolutely nothing beyond Level 3, so the only purpose of having Level 5 is bragging rights.
- Supercapital Construction Facilities--allows the alliance to anchor a Capital Ship Assembly Array and/or Capital Ship Maintenance Array at POS in the system (despite the name, these are not necessary for dealing with regular capital ships--they're for construction and storage of supercapitals). This is the only way to build supercarriers and titans, making the CSAA a prime target in any invasion.
- Cynosural Navigation--allows the anchoring of Cynosural Generator Array at a POS (this is an always-on cyno that can be used by the owning alliance).
- Cynosural Suppression--allows the anchoring of a Cynosural System Jammer at a POS. This jams all standard cynos, both modules fitted to ships and the Cynosural Generator Array, in the system (including those owned by the sov-holding alliance). It does not affect the Covert Cynosural Field Generator.
- Advanced Logistics Network--allows the anchoring of a Jump Bridge, which essentially allows the alliance to create a private stargate network. More details on Jump Bridges in a related class.
Someone Has the System I Want. How Do I Take It From Them?
- You can only claim a system if it's unclaimed, so we need to cause the enemy to lose control of the system before we can take it.
- Remember our important statement: whoever controls an online TCU owns the system. We can break that into three simpler statements, all of which have to be true for the enemy to control the system:
1) There is a TCU in space in the system. 2) The TCU is online. 3) The enemy controls the TCU.
- Let's start with the last statement and work our way back up to the first. There is only one way for control of a TCU to change hands while it remains online: the CEO of the controlling corp can give it to another corp within the same alliance. In theory we could join the enemy corp's alliance or get them to join ours, then convince their CEO to turn over the system to us; given that we're enemies, though, this seems doubtful. If we can't do that, time to move to the second statement.
- How can we put the TCU offline? If we have a spy in the enemy corp who has the Station Manager role, that person can simply fly to the TCU and take it offline directly. Since not paying the sov bills will cause the TCU to go offline, a spy with access to corp wallets could empty them right before the bill is to be paid. This still requires a highly-placed person on the inside, though, and getting someone there is not easy. If we have to take the system by force, we need to go back to our first statement.
- Our last option is to cause there to not be a TCU here at all; in other words, to destroy it. (Do the “target the TCU, oops you can't, ha ha” demonstration). Unfortunately for us, this is easier said than done. There are two statements that must both be true for the TCU to be vulnerable:
1) The controlling alliance does not hold an outpost or an Infrastructure Hub in the system. 2) There are Sovereignty Blockade Units anchored and online at more than half of the gates in the system.
The next class in this sequence will go into more detail on outposts and how to deal with them; for now, we can see that there isn't an outpost here, so that condition is fulfilled. The SBU can be anchored by anyone with the roles to anchor a TCU, so if we were preparing an attack we could anchor them here. Note that this results in an evemail being sent to members of the corp that owns the system, so you don't want to do it too early if the enemy doesn't know you're coming. SBUs are needed to make an I-Hub vulnerable also, so in this case, we'd need to anchor them, then destroy the I-Hub, and finally destroy the TCU.
Important Points About the SBU
- SBUs must be anchored between 30KM and 150KM from a stargate, with one per gate.
- They can be put online by anyone, regardless of who launched them (this is different from all other anchorable structures). Once onlined, they belong to the corp of the person who put them online.
- If all sovereignty structures the SBUs would make vulnerable are in reinforced mode, the SBUs will go into reinforced as well. They will be vulnerable again when any of the other structures are.
- Reinforced mode works differently for sov structures than for POS towers; a brief discussion can go here, though it will also be covered in Nullsec Infrastructure II when discussing outposts.
At this point the simulation kicks into high gear. Since some of the events are intended to be a surprise, anyone wishing to run this class should contact the author, Zevin Rialto, for details of how to handle the simulation.