These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

Player Features and Ideas Discussion

 
  • Topic is locked indefinitely.
123Next page
 

Power Projection: A Brighter Future

First post
Author
Alexis Nightwish
#1 - 2014-10-13 18:40:28 UTC  |  Edited by: Alexis Nightwish
Greetings,

Yes, this is another proposal to fix power projection. Yes, I am aware that CCP has a solution they are working on, and I truely believe that that magnitude of nerf to power projection (among other things) is absolutely necessary to the long term health of the game as a whole and nullsec in particular.

However I strongly disagree with the mechanics changes proposed by CCP. I do not believe that any pilot should be penalized for using a ship he or she has trained into. It is my opinion that jump fatigue is ham-handed way to nerf power projection, and unjustly punishes players for using jump capable ships.

With that in mind, I present my proposal to CCP and the EVE Community. I must warn you it is a bit long. If there was a short, simple solution it would have been done ages ago. The notes that I make in italics are may rationale behind the changes.



CYNOSURAL FIELDS

Deployable Cynosural Seeds
Cynos would no longer be 'Push button, receive beacon.' Instead, there would be a new unscoopable deployable. I call it a Deployable Cynosural Seed, but the name isn't important. The Cyno Seed would be small: just 10m3, 25m sig radius, a sensor strength of 20~23ish to make it hard to probe, 2000 structure, 0 armor, and 0 "brightness" (which I'll explain below). Cyno Seeds could not be lit closer than 250km to another lit non-covert cyno field, a station, a gate, a control tower, an outpost, a wormhole, or any other celestial. It would have an activation time of 15 seconds, and would decay after a while like most deployables. Once active the launching pilot can activate his/her redesigned cynosural field generator module on it. The generator module would have a range of 15km. While the cyno generator module is active the generating ship CAN move, a weapons timer is gained, the pilot can NOT use any offensive modules, nor can they use bastion/triage/siege/etc., the ship's max locked targets drops to 1, and gains a +100% signature bloom. The ship could not deploy drones, and any drones deployed would become abandoned. As soon as the generator module starts cycling on the Seed, the cyno beacon appears on the system overview because the brightness would be > 0. If the brightness falls to 0, the beacon would no longer appear on the overview.

Cyno Seeds have "brightness" which basically replaces shields. In fact, locked cynos would show brightness in the place of the shield bar. Running the cyno generator module makes the cyno brighter. The module would have a short cycle time, consume liquid ozone at a set rate, and "heals" the brightness in a special way.

The natural "shield" regen on a Cyno Seed when it does NOT have a cyno generator module being cycled on it would be the inverse of normal shield/capacitor regeneration. So it goes DOWN, rather than up. When the generator is used on the Seed, this regen flips to 'normal' and the "shield"/brightness starts to regenerate at a positive rate. Slowly at first, but quite fast at around 30% of maximum, and again slowing down as it grows even larger, just like shields and capacitors. Additionally, the generator gives flat "heals" to the brightness each cycle. If the module is deactivated for any reason (module turned off, ship destruction, lack of liquid ozone, ECM jammed, cyno jammer effect, etc.), then the brightness would decay again rather than grow. It would decay quickly if around 30%, and more slowly the further from this level. So the opposite of how shields and capacitors charge.

The reason I don't call it shields is because shield reps would have no effect on it. However, brightness basically = "shield" HP, and it also determines the cyno's current signature radius: 25m + brightness/500. Brightness would have a damage resistance of 0%. Attacking the cyno results in loss of brightness and its concomitant sig radius. There would be no damage bleedthrough from brightness to the Seed's structure. Higher brightness means more HP, but also a larger sig radius so it's easier to lock and do damage with larger weapons. It also determines the jumping ship(s) cyno lock percentage.

The brighter the cyno is, further the safe jump range. A larger brightness would be required to maintain a 100% cyno lock at longer ranges. The longer the jump, the longer it would take for a jump drive to achieve a "targeting solution" for the cyno. Cyno brightness also determines the 'jamming' characteristics of the cyno (more on that below).

Using a "firm" max jump range of 7.5LY for all of New Eden, then the max brightness allowed should be whatever amount would give a 100% jump chance at 7.5LY. I propose a max brightness of 750,000 = 752,000EHP (750k brightness HP + 2k structure) = 1,525m sig radius (750k/500 + 25 base) = 7.5LY max range at 100% chance to land at cyno. Conversely, if a pilot is making a short 1.5LY jump, then for 100% chance to land at cyno they'd need 150,000 brightness = 152,000EHP = 325m sig radius = 1.5LY. These numbers like all of them in this proposal could be modified for balance, but I think they're in the ballpark and do a good job of illustrating the idea.

CCP approaches problems in one of two ways: nudge or cludge

EVE Online's "I win!" Button

Fixing bombs, not the bombers

Alexis Nightwish
#2 - 2014-10-13 18:41:10 UTC  |  Edited by: Alexis Nightwish
If a jumping ship jumps with the cyno lock having dropped or started below 100%, then extreme deviation from the cyno, deviation from the target system, or even ship loss could result. This is why I said a "firm" limit before as it would be possible, but risky, to jump further than the 7.5LY max safe range. For each 1% below 100%, there's a 0.8% chance of deviation, and a 0.2% chance of ship loss. The calculation would be based on the lowest lock percentage during the jump cycle (jumping is no longer instantaneous; see below). So if the lowest percentage the cyno lock reached during the jump drive's calibration was 75%, then upon jumping the ship would have a 5% chance of destruction, a 20% chance of landing in a random system near the target, and a 75% chance of landing in the correct system (which itself has a 25% chance of being in a random location w/in the correct system instead of near the cyno). Should ship loss occur, the same roll would be made again for the pod. So in the above example if the ship was lost there's an additional 5% chance of pod loss, and a 20% chance the pod would end up in a random, nearby system, and a 75% chance of the correct system, with a 25% chance of being in a random location in the correct system instead of near the cyno. I hope that makes sense.

A single pilot could only have one deployed Cyno Seed per system at a time. Pilot, not ship, so switching ships wouldn't get around this. I'm aware that alts could be employed, but since beacons aren't fire and forget any longer I don't see this as an issue really. If it is, it could be restricted to one per pilot, period (though I'm not a fan of that). Other pilots could not use their generators on your Cyno Seed (lit or not); it is locked to the pilot who created it. The cyno would show who created it: on the overview the type would be Cynosural Field, the name would be Pilot Name's Cynosural Field, and the corp and alliance would be populated with those of the pilot. If the pilot is not in your alliance, he/she must be in your fleet for you to jump to his/her cyno, but you don't have to be fleeted when the cyno is lit, only during the jump. If the pilot is in your alliance (or corp, if not in an alliance) then the pilot who lit the cyno would not have to be in fleet (or even online). In either case, the pilot would NOT have to be physically at the cyno when you jump, but it may be a good idea to help defend it by pumping more liquid ozone into it to increase its brightness (and thus, HP), or to simply maintain it at its current level by pulsing the module so the jumping ship doesn't fall below 100% cyno lock. Sticking around also gives you some eyes on the ground to make sure you're not jumping into an ambush.

NPCs would attack cynos/seeds, but the 'threat level' of a cyno/seed would be at the bottom of the list. Thus they'd only attack it if there's nothing else to shoot at, and would immediately switch targets if anything else showed up. A ship generating a cyno would be just one level above the cyno itself in regards to 'threat level.'

Attacking a cyno would have no effect on security status, and would not trigger any crimewatch flags other than a weapons timer.

Cynos could be lit inside a Deployable Scan Inhibitor, in which case they would NOT show up as beacons on the overview or on D-scan. However, they also could NOT be jumped to while under the effects of a Deployable Scan Inhibitor, so the cyno lighter (or friend) would have to destroy the DSI before anything can jump to the cyno. The option to jump to the cyno simply wouldn't appear until the DSI is gone. Once the DSI is destroyed, the cyno would show up as a beacon in the overview and ships could jump to it, like normal.

Non-covert cynos would disrupt bubbles. If the center of a bubble is within 2*brightness meters of the cyno, its warp disruption effect would be negated. Should the cyno be reduced below that (or in the case of a HIC, the bubble moves outside of range), the bubble reactivates immediately.

In addition to cyno jammers, a cynosural field's own brightness would override other cynos within a (brightness^2)/2 meter radius. The brighter one effectively obfuscates the dimmer one from jump ships, but doesn't deactivate it, so a dimmer one can still obfuscate an even dimmer one that was outside the range of the first. 'Obfuscated' cynos would not appear in the jump ship's list in the same manner as cynos under the effect of a DSI wouldn't. Reducing the brightness of an interfering cyno below yours would cause yours to instead 'obfuscate' the first one and allow yours to be jumpable. So a cyno at 750,000 brightness would obfuscate any other cyno within 281,250,000,000 meters (1.88AU) radius that has a brighness less than 750,000. Covert cynos would be subject to this 'obfuscation' effect from regular cynos, but covert cynos would never cause the effect on any other cyno (regular or covert). If two cynos have the exact same brightness they would cancel each other out, making neither jumpable.

Covert cynos would function like regular ones, except for the perks of not showing up on D-scan or as a beacons on the overview, not counting as celestials when lit, immunity to cyno jammers, and would have hidden sensor stats equal to a proportion of the signature radius of a covert cyno. Perhaps sensors equal to 85-95% of the current sig radius? This way they cannot be probed down easily. Covert cynos would NOT disrupt bubbles the way regular ones do. Covert cyno deployment is still restricted to no closer than 250km from another cyno seed, station, gate, control tower, wormhole, or any other celestial just as regular cynos are.

CCP approaches problems in one of two ways: nudge or cludge

EVE Online's "I win!" Button

Fixing bombs, not the bombers

Alexis Nightwish
#3 - 2014-10-13 18:41:58 UTC  |  Edited by: Alexis Nightwish
Cynosural Generator Arrays
Cynosural Generator Arrays would function the same as ship-generated cynos above, except its Seed's structure would have 100% resists so long as the CGA is online. The CGA and its cyno would be two separtate objects. The CGA Seed would only be destroyable if the CGA is destroyed, offlined, or unanchored. The CGA's cyno would always be considered lit (unless cyno jammed), and would increase to a max brightness of 750K at the regular rate after onlining the array. The CGA-produced cyno could be attacked to reduce its brightness, but the CGA would continually try to increase it. POS turrets would NOT automatically fire on pilots who attack only the cyno itself (assuming of course that the turrets wouldn't fire on him/her anyway). The cyno could not be destroyed so long as the array is online, but it could be reduced to 0 brightness and held there with continual attacks. In the event of the CGA being destroyed, offlined, or unanchored, the cyno itself would start to lose brightness and the structure resists would immediately become 0%.

WHY: The principal reason for this is to severly limit hot dropping. An alt in a rookie ship being able to summon 250 supercaps on top of an enemy virtually instantaniously is a horrible mechanic. Hot dropping discourages undocking because anyone nearby can insta-whelp you, and thus loss avoidance and lack of content. This will also prevent an AFK cloaker from locking down a system because it can't drop all of New Eden on someone's head without them having a chance to react. By needing to charge up the cyno you put a delay before the fleet can land on top of the target, and you give the target options like fleeing, or attacking the cyno or generating ship. Perhaps this will force the attacker to pin the targets down before attemping to cyno in their fleet? It would also be more difficult to build a cyno chain in areas that aren't safe, which slows down jumping in/through hostile territory. A cyno chain in your own safe territory would be as easy to establish as it is now. While not a big deal right now, I hope that SOV changes will break apart the blue dounut and this will become something that must be considered when deploying.

Due to the signature radius mechanics, not having smaller ships with your capital fleet to take out tackles and destroy the cyno/generating ship you will still leave yourself open to being hot dropped, especially if the enemy fleet is nearby and thus doesn't need a very bright cyno. This is of course in anticipation of carriers having their drone bay removed and/or sentries being changed so they act like BS sized weapons and thus can't murder cruisers so easily.

I think that the cyno lock mechanic will add a lot of depth to jumping, especially in a combat sense. Say the lock was dropped to 90% by the defenders, would the attacking FC consider that an acceptable margin of safety (2% chance of ship loss, 10% chance of deviation), or would he cancel the jump?
Being able to put cynos in Scan Inhibitors will open up sneaky tactics like deploying 10 DSIs in the system and lighting cynos in only one which will slow down response time of the defenders as they have to check them all to see if there's a cyno inside.

Because of the new delay in cyno generation, I thought that there'd need to be a way to prevent the defender from just dumping a bunch of bubbles on the cyno and calling it a day. That's why cynos would disrupt the bubbles. This and the obfuscaion mechanic also opens up cyno warfare tactics.



CYNO JAMMING
System Cyno Jammers
System Cyno Jammers would prevent new cynos like they do now, but currently active ones would simply begin to 'lose brightness'. Upon activation a cyno jammer would break the link between the cyno generating ship and the cyno seed resulting in the cyno generator module turning off. Attempts to activate the module again would result in an error message and the generator module would not be usable while within the jammer's area of influence. Cynosural Generator Arrays would stop energizing their cyno, but the CGA itself would not go offline and the CGA's cyno would begin to decay, not immediately disappear.


Deployable Cyno Jammers
There would be three sizes of DCJs, each with larger activation and decay timers and radii (see the items area below for stats). Jammers of the same or larger size would prevent the activation of a new one within their area of effect. A System Cynosural Jammer would be considered the largest and when activated offlines and prevents online of any and all DCJs. All cyno jammers would have zero effect on any type of bridge, nor would they prevent jumping OUT of the system to a cyno elsewhere.

WHY: I believe that cyno jammers should be used in a precautionary way, not a reactionary way. Using a jammer should not instantly blow away any existing cynos.

CCP approaches problems in one of two ways: nudge or cludge

EVE Online's "I win!" Button

Fixing bombs, not the bombers

Kaerakh
Obscure Joke Implied
#4 - 2014-10-13 18:42:24 UTC
Alexis Nightwish
#5 - 2014-10-13 18:42:45 UTC  |  Edited by: Alexis Nightwish
JUMP DRIVES

Jump Drive Mechanics
The way jump drives work would change. Jump drives would have a "spin up time" to calibrate to the cyno based on the distance to the target cyno. While the jump drive is engaged (calibrating) the ship cannot move, change fittings, or enter siege/triage/bridging-mode/etc. All jump ships would be normalized in the distance they can jump because their jump range would be determined by the brightness of the cyno they are jumping to and the distance of the jump. 100,000 brightness per LY would be needed to achieve a 100% lock. Ships could jump with less than 100%, but risk deviation from target and ship destruction. The percentage used would be whatever the lowest point the percentage reached during the jump drive's calibration.

Jump ships would have the ability to bring a small escort of fleetmates with them when they jump. Doing so adds their mass to the jump ship's for calculating fuel cost. BLOPS could only bring cloakies with if jumping to a covert cyno. BLOPS would be able to jump to standard cynos and could bring non-cloakie ops ships with in such cases.

A pilot would be able to cancel a jump at any point before they enter the jump tunnel without loss of capcacitor by right clicking their ship > Jumping... > Cancel Jump. If they cancel, and then start another jump, the spin up time would start over at zero even if the same cyno is selected as the target.

All jump ships would use 10% of their max capacitor/LY jumped (reduced by the JDO skill) at the time of the jump out, not at the time that the jump drive was initiated. If they lack sufficient capacitor for the distance when the timer reaches zero, the jump fails and no capacitor would be consumed just as if the jump had been canceled manually. While it is spinning up, the jump ship's pilot would have a timer on the HUD showing the countdown until the jump initiates along with the capacitor cost, listed as a percentage of max cap, as well as the minimal point the cyno lock has reached thus far.

To initiate a jump, jump ship pilots would right click their ship > Jumping... > [list of pilots' cynos, distance, system name, Standard/Covert, and current cyno lock percentage sorted by distance] for example: John/3.4LY/UW0T-M8/Std/187%

Jump Ship Changes
Most jump ships would have a fuel bay size change. All jump ships and bridges would have a new attribute: Jump Fuel Efficiency. This stat would be used in the new fuel calculation:

Fuel cost = [(LY*Jump Fuel Efficiency)^2*(Mass/(1,000,000*LY))]+[(Mass/1,000,000)*LY*Jump Fuel Efficiency*(1-(JFC*0.15))]
Downloadable fuel cost google doc.

Jump ships would have the ability to bring a small escort of fleetmates with them when they jump. By having your fleetmates targeted at the time of jumpout, you could 'pull' them with you into the jump tunnel. Fleetmates could disable this with a new "Jump out with fleet member" option, similar to the "Follow squad leader into warp" option. The server would simply run through the list of targeted ships starting with the closest and check if they're in fleet, are flagged as willing to jump, if the mass limit hasn't been exceeded, and if there's enough fuel to jump with the added ship. If all this checks out, he/she comes with. If not, it moves to the next closest targeted ship and runs the same checks until there are no more targeted ships.

Summary of changes to jump ships:
Type____Max Fuel___JFE___Jump Delay___Escorts' mass___Notes
BLOPS___1,000____1.75___10s/LY______2.5 million_______(can utilize covert and standard cynos)
JF_______5,000____1.50___30s/LY______10 million
CapIndy __7,500____1.50___30s/LY______50 million
Dread____3,000____1.00___4min/LY______15 million
Carrier___7,750____1.75___4min/LY______75 million
SuperC___11,000___1.75___5min/LY______50 million
Titan_____100,000__1.75___5min/LY______50 million

Please see the changes to skills and items section below for ship specific changes.


BRIDGING

There would be a change to how bridges work as well. All ships would be able to utilize non-covert bridges. All bridges would cause ships that use them to gain a debuff that prevents them from using another bridge or initiating their jump drive until it wears off. We can just call it some made up tech reason like "quantum polarization" or something. An icon for it would show up on the HUD where all the other effects do. A mouseover would show the time left. Also this bridge debuff would prevent a ship from being repackaged. "Your ship cannot be repackaged due to dangerous levels of quantum polarization. We estimate it will be safe to do so in X seconds." So while jumping to a cyno you have to wait up front, jumping across a bridge means you have to wait to use another bridge or jump drive afterwards.

All bridges would require two ends to function. POS bridges would require the module at each system and they'd be tied to each other. Titans and BLOPS would require a ship at each end and they'd require a high slot Jump Bridge Generator (or Covert Jump Bridge Generator) to be activated on each ship to form the bridge. A cyno would not be used. POS and covert bridges would have a max range of 5LY, titan bridges would have a max range of 7.5LY. Bridges would be two way streets. For example, ships at titan B could jump across the bridge to titan A at the same time as ships at titan A are bridging over to titan B.

EDIT: Failed to mention that the lowest cyno lock would appear on the HUD while the JD is spinning up. *derp*

CCP approaches problems in one of two ways: nudge or cludge

EVE Online's "I win!" Button

Fixing bombs, not the bombers

Rowells
Blackwater USA Inc.
Pandemic Horde
#6 - 2014-10-13 18:43:22 UTC
Kaerakh wrote:
Reserved 5/7

C-C-C-COMBO BREAKER

(I'm sorry OP I couldn't resist)
Alexis Nightwish
#7 - 2014-10-13 18:43:32 UTC  |  Edited by: Alexis Nightwish
Titan Bridging
Would require a titan at each end of the bridge. The bridge will not form if either titan is within 250km of any celestial. The remote titan wouldn't use fuel. The local titan would for each ship that actually jumps across the bridge. The amount of fuel would be determined by distance and the mass of the ships using the bridge (similar to the jump drive mechanics). However the titan bridge would be much less fuel efficient than jumping directly to a cyno.

Just like regular cyno jumping, the further the distance, the more fuel it would take, going up exponentially, and it increases with the amount of mass being sent. Activating the Jump Bridge Generator would put the titan into 'bridging-mode.' The generator would give the titan the "quantum polarization" debuff and the end of each cycle. Any titan in 'bridging-mode' could not use their jump drive or a cloaking module. Bridging-mode would be similar to the Marauder's Bastion mode: cannot move, no remote assistance, locked into possition for the cycle duration, cannot eject, and cannot move fuel into its fuel tank. The titan pilot could elect to let the bridging-mode module continue to cycle if desired. The module itself would consume capacitor, not fuel of any kind. The amount of capacitor consumed would be cap stable at ~60% with nothing else running on an all V character with no cap boosting modules. After ending the bridging-mode, the titan would not be able to jump, utilize a bridge, or activate a cloak for 1 minutes.

To make things easier on the titan pilots and FCs, a new right click option for the titan would be added: "Calculate Bridge". Using it would bring up a calculator tool where it shows all the members of the fleet (pilot, ship type (ex: Dominix), mass). The calc would let the titan pilot enter the target system name and the LY would automatically populate, or he/she could manually enter the number of LY to bridge. The pilot could also select/deselect members of the fleet to be used in calculation which is useful if there are ships in the fleet that won't be using the bridge. Fleet members on-grid would automatically be selected, and those off-grid/out of system/offline and the pilot's titan itself would not be. It would automatically populate the fuel amount the titan currently has, but this too could be changed manually if desired.

The calculation would show if the jump is possible with the current inputs, and would show how much fuel would remain after bridging the fleet. It would also show the total mass of the selected ships in the fleet. Fields such as mass, pilot name, and ship type would be sortable. If the titan pilot is also the fleet commander, he/she could right click members in the calc and boot them from the fleet in order to get under the mass limits. There would a "Reset" button which would reset all fields to defaults: refreshing and autopopulating fleet mass based on fleet members on-grid selected according to defaults, and the fuel in the tank.

To actually create the bridge the local and remote titan would engage their 'bridging-mode' modules. Once in 'bridging-mode' the local titan would right click his/her ship > Bridging... > Bridge to Remote titan > [list of pilots, their titan's type, distance, and system name (ex: John/Avatar/3.4LY/UW0T-M8) which are in bridging-mode and in fleet]. Alternetively one could right click them in fleet or in the Bridge Calculator and select Bridge to Remote Titan. Titans which are currently in bridging-mode AND are already actively bridging would be listed, but greyed out with "currently bridging with X" listed after their name. (ex: John/Avatar/3.4LY/UW0T-M8 currently bridging with Phil/Erebus/2.7LY/OH-NOE5). Once the target has been selected, the remote titan pilot would get a pop-up asking for confirmation of the link. Selecting Yes establishes the bridge and ships could then jump across it.

Note: Cyno Jammers, bubbles, points, and HIC focused points do NOT stop a titan bridge. Only capping out or destroying the titan will. HIC focused points would prevent a ship from utilizing the bridge, however.

In the event that either one of the titans is destroyed or one of their 'bridging-mode' modules is deactivated while ships are jumping across its bridge, any ships that are in the jump tunnel would end up in the target system in random locations. Jump Bridge Generators would be limited to 1 per ship.

Like cyno jumping, if a titan in 'bridging-mode' is inside a DSI, no other titans would be able to link to it. If the link is already established, and a DSI onlines nearby, the link is broken and any ships that are in the jump tunnel exit at random locations within their target system. Unlike cyno jumping, there wouldn't be a 'spinup time' like a jump drive nor cyno lock that you'd want to wait till it was at least 100%. However, there would be a cooldown after the jump during which the ship cannot be repackaged or utilize their jump drive or another bridge of any kind. There would be a hard range limit of 7.5 LY for a titan bridge.


Black Ops Bridging
Functionally the same as titan bridging: requires two BLOPS, and the local battleship would use fuel for each cloakie ship that jumps across the bridge. BLOPS cannot be cloaked while in 'bridging-mode' of course. Covert Jump Bridge Generators would have a shorter cycle time than the ones titans use, and consume the same relative capacitor over time as well (still cap stable around 60% on an all V). The jump cooldown for BLOPS bridges would be lower than titan or POS bridges, but of course only cloakies can use them. This debuff will prevent these ships from utilizing any other bridge, covert or standard, and from being repackaged. The range limit for BLOPS bridges would be shorter than titan bridges: 5LY.

CCP approaches problems in one of two ways: nudge or cludge

EVE Online's "I win!" Button

Fixing bombs, not the bombers

Alexis Nightwish
#8 - 2014-10-13 18:44:19 UTC  |  Edited by: Alexis Nightwish
POS Jump Bridge
Similar to a ship bridges, a POS Jump Bridge would consume fuel from the POS structure's fuel tank to send ships to the remote POS bridge end. The bridge calculator would be available to anyone by right clicking the POS bridge end and selecting "Calculate Bridge" so you could see how much fuel will be consumed to jump your ship to the destination. POS Jump Bridges could have only one link to another POS Jump Bridge at any one time. To change the link, someone with appropriate permissions would access the control tower or POS bridge module, and offline the bridge. This will offline the modules on both ends. Before a bridge end could be brought online, a target must be selected, which would be another anchored but offline POS bridge end. With a valid target selected the POS manager could then online both of these ends with a single click. Onlining time would be 1hr. POS bridges would be the least fuel efficient jump technology, especially when you factor in skills/modules/implants/etc that would reduce fuel cost on a jump capable ship, but do nothing for bridges. The range limit for POS bridges would be 5LY. Just like other bridges, ships using them would have a debuff of sorts that prevents them from using another bridge, jump drive, or from being repackaged.

Summary of changes to bridges:
Type_______Max Fuel___JFE___Jump Delay__Escorts' mass___Notes
BLOPBridge__1,000_____1.25___2min/LY_____n/a_________(not affected by skills, delay is after the jump, only cloakies can use)
TBridge_____100,000___2.25___4min/LY_____n/a_________(not affected by skills, delay is after the jump)
POSBridge___250,000___2.5____5min/LY_____n/a_________(not affected by skills, delay is after the jump)

WHY: Similar to jump drives there needs to be a slow down on bridging. Since bridges can send any ship, they cost more to use and are a bit more restricted in their use. Ship bridges are a bit better than POS because they risk more.

MEDICAL CLONES
Regarding the remote placement of your medical clone, I would instead make it so you could only remotely move your medical clone once per 24hrs, and have this cooldown shared with your jump clone cooldown. So you would not be able to remotely move your medical clone if you are on jump clone cooldown, and when you remotely move your medical clone, you would not be able to remotely move it again *or* clone jump for 24hrs. The 24hr cooldown from moving your medical clone would not be affected by Infomorph Synchonizing. Changing your medical clone to a station with medical services that you are docked in would always be an option.



CHANGES TO SKILLS AND ITEMS

Skills:

Advanced Cynosural Field Theory: new skill
Rank 6
INT/MEM
Prereq skills required: Cynosural Field Theory IV
+7.5% per level to the amount of flat "healing" done to a cynosural field's brightness.

Jump Drive Calibration
Reduces the time it takes to jump by 5% per level
Ex: A JF which can jump after 30 seconds per LY has a pilot with JDC at V. A 5LY jump would take 1.875 minutes instead of 2.5 minutes.

Jump Fuel Conservation
15% reduction in factor of the non-exponential component of the jump fuel calculation for all jump ships Does not affect fuel consumption of bridges.
Fuel cost = [(LY*Jump Fuel Efficiency)^2*(Mass/(1,000,000*LY))]+[(Mass/1,000,000)*LY*Jump Fuel Efficiency*(1-(JFC*0.15))]

Jump Drive Operation
Reduces capacitor cost to jump by 5% per level.
Ex: At level V it would cost 7.5% of your max capacitor per LY to jump.

Jump Bridge Generation (renamed from Jump Portal Generation for clarity of function)
10% reduction in Jump Bridge Generator cycle time and capcacitor need per level.


Ships:

All ships would be able to use all gates, with the exeption of capitals still being unable to use gates leading to highsec.

Jump Freighters
JFs get role bonus: 100% reduction in CPU costs of Capacitor Flux Coils
The JF bonus to fuel consumption would instead become a 5% bonus to agility per level.

Force Recons
Falcon and Rapier
+5% to all base shield resistences per level of Recon ships while a standard or covert cynosural field generator module is active.
Pilgrim and Arazu
+5% to all base armor resistences per level Recon ships while a standard or covert cynosural field generator module is active.


General Items:

Liquid Ozone
A database change would be made so that LO is only 0.01m^3 in size and every current instance of it is multiplied by 40, and refining ice results in 40x more.


New Implants:

Eifyr and Co. 'Rogue' Jump Drive Calibration DC-601/DC-603/DC-605
Reduces the time it takes to jump by 1%/3%/5%

Eifyr and Co. 'Rogue' Jump Fuel Conservation DC-807/DC-814/DC-821
7%/14%/21% reduction in factor of the non-exponential component of the jump fuel calculation.

Inherent Implants 'Squire' Jump Drive Operation DO-901/DO-903/DO-905
Reduces capacitor cost to jump by 1%/3%/5%


Modules:

Cynosural Field Generator I
CPU: 138
PG: 31
Volume: same as now
Cycle time: 1 second
Overheat: 10% bonus to cycle time
HP: 40
Max modules of this category allowed: 1
Range: 15km
Consumes 100 units of liquid ozone per cycle (1m^3)
Each cycle "heals" the brightness of the cynosural field by 1000.
While active the target cynosural field's natural rate of growth is set to positive.
While active the ship:
Cannot initiate self destruct, and current self destruct sequences are canceled.
Cannot activate any offensive module. (similar to having your saftey set to green)
Cannot launch drones, and any drones in space become abandoned.
Cannot cloak.
Gains a +100% signature radius.
Has its max targets reduced to 1.

Meta levels:
Compact - CPU: 103 and PG: 22
Enduring - Double the structure HP to 80HP
Ample - 20% Reduced ozone usage
Scoped - 40km range
Restrained - +25% signature radius instead of +100%

CCP approaches problems in one of two ways: nudge or cludge

EVE Online's "I win!" Button

Fixing bombs, not the bombers

Alexis Nightwish
#9 - 2014-10-13 18:45:06 UTC  |  Edited by: Alexis Nightwish
Jump Bridge Generator I and Covert Jump Bridge Generator I (formerly called (Covert) Jump Portal Generator I, renamed for clairty of function)
Changes include: these only use cap (enough to keep the ship stable at around 60% on an all V pilot), can cycle continuously, and target another ship using a bridge generator instead of a cyno. Cycle speed is 1 minute for titans, and 15 seconds for BLOPS. They also apply the jump bridge debuff to the generating ships for 1 minute for titans, and 15 seconds for BLOPS at the end of each cycle, and cannot be used within 250km of a station, gate, control tower, wormhole, or any other celestial.


Fuel Conservation Module I
Low Slot
PG: 0
CPU: 0
Required skills: one of the jump skills at level 1; whichever one everyone who jumps MUST have trained (incl BLOPS)
5% reduction in mass for the purposes of calculating jump drive fuel cost. Includes mass of escorts. Does not affect bridges.

Meta levels:
Upgraded 7% reduction in mass for the purposes of calculating jump drive fuel cost. Includes mass of escorts. Does not affect bridges.
Tech2 10% reduction in mass for the purposes of calculating jump drive fuel cost. Includes mass of escorts. Does not affect bridges.


Deployables:

All unscoopable deployables would have the word "Mobile" changed to "Deployable" (honestly these things are as "mobile" as trees; you plant them once and that's where they stay)


Deployable Cynosural Seeds
Requirements: Cynosural Field Theory I, Anchoring I
Volume: 10m3
Sig Radius: 25m
Omni sensor strength: approx 20~23
Structure: 2000
Armor: 0
Shield: n/a
Activation time: 15 seconds
Decay: 30mins/8hrs/48hrs
Notes: Limited to one per system per pilot. Appears on overview only when brightness is greater than zero. Can only be used by the launching pilot.
Disables all bubbles whose centers are within 2*brightness meters.
Obfuscates all cynos whose brightness is less than it, and whose centers are within (brightness^2)/2 meters.
When under the influence of a Deployable Scan Inhibitor, the cynosural field will not appear as a beacon, nor will it appear for pilots to jump to.
When the deployable decays, the cyno disappears instantly, it does not remain and slowly lose brightness.

Meta levels:
All Seeds would have a range:
Short Range: 100% lock achievable up to 2.5LY, 250K max brightness, base natural regen/degen is 600 seconds
Medium Range: 100% lock achievable up to 5LY, 500k max brightness, base natural regen/degen is 1200 seconds
Long Range: 100% lock achievable up to 7.5LY, 750K max brightness, base natural regen/degen is 1800 seconds
and they would all have a rate of entropy:
Unstable: 4x the natural regen/degen rate of brightness, deployable decays after 30mins
Standard: 1x the natural regen/degen rate of brightness, deployable decays after 8hrs
Stabilized: 0.25x the natural regen/degen rate of brightness, deployable decays after 48hrs

All Seeds would be a combination of one of each of the above categories (range and entropy) so there are nine different types of Seeds.
Example: Long Range Stabilized would have a 100% lock achievable up to 7.5LY, 750K max brightness, and a natural regen/degen of 14400 seconds (4*1800 which is 2hrs), and the seed will despawn 48hrs after being launched.
Example2: Short Range Unstable would have a 100% lock achievable up to 2.5LY, 250K max brightness, and a natural regen/degen of 150 seconds (600/4 which is 2.5mins), and the seed will despawn 30mins after being launched.
The Standard version of the Seed BPO would be seeded (see what I did there) to NPC markets. The Unstable and Stabilized meta variants are only from 50 run BPC drops in low and null. Base cost to build is determined by the range, with a longer range being more expensive to build:
SR: 5m ISK
MR: 25m ISK
LR: 125m ISK


Small/Medium/Large Deployable Cynosural Jammer
Requirements: Anchoring II/III/IV
Volume: 5/10/50m^3
Sig Radius: 50/100/500m
Omni sensor strength: 45
Structure: 500/1000/5000
Armor: 50/100/500
Shield: 0/0/0
Activation time: 5/10/30min
Decay: 4/12/48hrs
Radius: 250km/500,000km/2AU
Notes: When deployed it will automatically attempt to activate. If it is within the area of effect of another cynosural jammer of the same or larger size, the activation fails. If a larger cyno jammer is activated whose area of effect would encompass this DCJ, this DCJ deactivates. To reactivate it, the pilot or someone in the corp or alliance (if deployed for self, corp, or alliance respectively) has to fly to it, right click, choose online, and wait the activation time (which of course only works if the interfering cyno jammer is gone).

Meta levels:
none at this time

Approx cost to build:
2.5m/7.5m/25m



If you managed to read the whole thing I thank you! I realize it's long, but like I said this is not a simple problem with a simple solution.

Please leave constructive feedback! I very much want to see how it stands up to the scrutiny of thousands of players. If you love it, please say so and why. It will give weight to the proposal. If you hate it, please say so and why. Perhaps I missed something, or was ambiguous in my explanation, or we have different ideas on how nullsec should be.

CCP approaches problems in one of two ways: nudge or cludge

EVE Online's "I win!" Button

Fixing bombs, not the bombers

Ama Scelesta
#10 - 2014-10-13 18:46:45 UTC  |  Edited by: Ama Scelesta
Wolf Incaelum
Sebiestor Tribe
Minmatar Republic
#11 - 2014-10-13 18:47:02 UTC
reserved 8/7

Come on. Let's keep it going. Big smile

ANARCHYFOREVAAARRRRRRRRRR!!!!!!!

Paranoid Loyd
#12 - 2014-10-13 18:56:01 UTC
Posting in what will eventually be known as the great wall of text. Ugh

"There is only one authority in this game, and that my friend is violence. The supreme authority upon which all other authority is derived." ISD Max Trix

Fix the Prospect!

Mike Azariah
The Scope
Gallente Federation
#13 - 2014-10-14 00:49:40 UTC
wow, I have to admit . . . this is not an 'off the cuff' proposal.

Culd the OP please include a couple of examples that are common to power projection? Specifically how this effects a logisitic ship like a jump freighter making supply runs to Jita, how a lartge attack force on its way to a BR-5 is slowed, how hotdropping now works.

m

Mike Azariah  ┬──┬ ¯|(ツ)

Jack Carrigan
Order of the Shadow
The Revenant Order
#14 - 2014-10-14 03:33:17 UTC
Holy text.

Interesting concept, but seems very tedious.

I am the One who exists in Shadow. I am the Devil your parents warned you about.

||CEO: Order of the Shadow||Executor: The Revenant Order||Creator: Bowhead||

Alexis Nightwish
#15 - 2014-10-14 04:08:22 UTC  |  Edited by: Alexis Nightwish
Mike Azariah wrote:
wow, I have to admit . . . this is not an 'off the cuff' proposal.

Culd the OP please include a couple of examples that are common to power projection? Specifically how this effects a logisitic ship like a jump freighter making supply runs to Jita, how a lartge attack force on its way to a BR-5 is slowed, how hotdropping now works.

m

Thanks for the reply Mike. I'll do my best but I will freely admit that I am a null sec outsider. Reading about life there made me not want to go. Given that, I would invite nullvets to correct me if I am mistaken on my impression of how it currently operates. I'm assuming you want examples of how they run now vs how I envision they would after these changes.

Jump Freighters
Currently pre-staged disposable cyno alts are set up in systems along the supply line. Their job is to light a cyno just close enough to a station that the JF won't bump away, but is still within the docking ring. The cyno alts are often doomed because they're locked into place for 10 minutes so there's no motivation to use anything but alts in the cheapest ships and empty clones.

The instant the cyno goes up the JF can jump to it without any delay and can dock right up for full cap so they repeat it for the next hop. The allows for completely risk free logistics. It's actually more dangerous to move cargo through highsec because you aren't immune to attack.

With my proposed changes cynos would not be able to be lit near celestials like stations and jump drives would have a spinup time. With cynos also being attackable and requiring time to build up they would be a nexus of content generation. These changes would remove the JF's immunity to attack, and they'd require escort. Organized convoys could actually become a thing.

JFs (and all other jump ships) would be able to bring a small escort with them. This escort can web the JF into warp, rep their recently buffed armor/shields, and fight off attackers (especially tacklers). New tactics would emerge. Instead of one cyno, perhaps you'd light several, and have the cyno lighting pilots tell you which is safe to land at. Due to the interference caused by nearby cynos, the JF's fleet's cyno would prevent attackers from just lighting their own nearby to drop the hammer. Cyno jammers just cause cynos to degen, they don't wipe em out, and they take time to online. Bubbles would be disrupted by cynos preventing a bubble bath at the landing zone. Attackers would have to deal with your cyno directly.

By giving the Force Recons a huge tanking buff while lighting a cyno, it would encourage something more than throwaway ships and alts. I could totally see FRs equipped with nothing but tank, cyno, and probes piloted by actual players rather than being "alt tab, click button" characters. FRs would do well to have guards who could rep them up and buff their sensors so they can keep pumping that cyno.

I believe the system would be hugely dynamic and breathe new life into logistical transport. Also do not forget that CCP has the intent of making nullsec less reliant on imports, and so eventually every system w/in 7.5LY of Jita won't be a bloodbath. ;)



Hotdropping
How I understand it works now:
Fly HIC to enemy fleet.
Bubble.
Cyno.
Archons blot out the sun.
Enemy fleet explodes with zero chance to fight back or escape.
Both sides leave unsatisfied.

What a broken, content-killing mechanic!


How hotdropping would work in my proposal:
It wouldn't.

See, even if the fleet was really close by so they didn't need that bright of a cyno, it would still take some time for the cyno to be bright enough to have an acceptable level of loss, and only then could the ships activate their jump drives so best case scenario with the fleet only 1LY away it would probably take 3-4 minutes to get in there via jumping. Faster to take the gate I would think.

However.... If you prestaged a titan in there and had it cloaked, then sent some tackle to hold them down, the titan could warp on top of them and form a bridge with another titan in another system allowing a bunch of dudes through the instant the bridge formed!

Okay so hotdropping wouldn't be possible but HOTBRIDGING would be epic! :D

CCP approaches problems in one of two ways: nudge or cludge

EVE Online's "I win!" Button

Fixing bombs, not the bombers

Alexis Nightwish
#16 - 2014-10-14 04:09:11 UTC
Transporting large forces
The way it currently works as I understand it is that the coalitions have massive jump networks built by POS and Titans placed all over. Using the disposable cyno alts I mentioned before the coalitions can jump around massive amounts of ships. 250 ship fleets of Archons are not uncommon (and I believe are called the Slowcat?) or even Aeons (Wrecking Balls?) and multiple fleets of Megathrons (Baltecs, right?) can be zipped around with total ease and lack of risk because all the titans do is nose out of the POS shield, bridge everyone over, and gets bumped back inside, or jump ships will simply all jump to the cyno, cap up (dock if they can, remote cap boosting if not), and continue covering all of New Eden in around 15 minutes.

Traveling from say YA0-XJ to B-R5RB (a distance of just under 60LY) in a carrier fleet (assuming all V pilots) would cost 41,946 fuel per ship and take less than 10 minutes.

In the system I propose, with all V pilots, making the same trip, (I used dotlan and set everthing to 0 to give the carrier a 6.5 LY range; not perfect but close enough), assuming cynos were lit in advance (no Batphone nonsense, but a planned deployment), would take at least 3hrs to travel (due to it being 3mins per LY with JDC maxed). It would also cost approximately 256,000 fuel.

Before any of you flip out like a ninja, remember that CCP wants it to be about 3mins per LY anyway, and I agree with their sentiment. At least with my proposal can't screw your pilots out of being able to jump for literal weeks. If using a bridge network for subcaps, remember that they can warp faster than caps, and don't have to remain immobile while the debuff wears off so they can use gates. These smaller ships could get to a hotzone quicker than caps could. Imagine that, smaller ships being faster than larger ones.

For the fuel costs, remember that I was making larger jumps and I believe that such large and powerful ships should have large operating costs. Expensive toys, right? One nice thing about exponential fuel costs is that it doesn't violate Malcanus' Law. Little guys with a small area don't need to jump very far. Big guys do, and can pay for it.

Now, because of the jump drive spin up and the jump bridge debuff slowing jumping down, it may in fact be faster to take gates sometimes. Especially regional ones. I see systems with regional gates as being hotspots as you are sometimes forced to use them, and even if you're not forced to they'd shave lots of time off the trip. However if someone hellcamped a chokepoint system, my proposed cyno lock mechanic would allow for some RISKY extremely long range jumps. I calculated that at max skills and implants (cap is the true limiting factor) a hard max jump range of 14.2857LY could be reached which would allow a max cyno lock of 52.5% so if you want to lose around 10% of your ships, and have half of them end up who knows where, more power to you! But it may be the only way to flank them...

CCP approaches problems in one of two ways: nudge or cludge

EVE Online's "I win!" Button

Fixing bombs, not the bombers

Alexis Nightwish
#17 - 2014-10-14 04:20:28 UTC
Jack Carrigan wrote:
Holy text.

Interesting concept, but seems very tedious.

I know I know! It's long and pretty complex, but I think it is also pretty intuitive. Cynos get brighter, like a light. The brighter they are, the more accurately a jump ship can target it and land there. Jump drives spin up in order to facilitate the massive energy cost of launching you light years across space instantly w/o a gate. Bridges coat you in bridge goo prevening use of another bridge till it wears off. You can still use gates in the meantime.

The cyno warfare introduced by way of cynos disrupting bubbles and other cynos, jammers disabling cyno generators, and of course bubbles trapping ships opens up new and dynamic gameplay options. Cyno warfare could be the new meta! ;)

CCP approaches problems in one of two ways: nudge or cludge

EVE Online's "I win!" Button

Fixing bombs, not the bombers

Sigras
Conglomo
#18 - 2014-10-14 07:55:00 UTC
I have two problems with your idea, one from a lore perspective, and one from a game design perspective.

From a lore perspective most stars would be brighter than any cyno you could practically make. why would you not simply lock on to the star of the system?

From a game design perspective, randomness is a terrible game mechanic and randomly losing your ship is even worse...
Sugar Kyle
Middle Ground
#19 - 2014-10-14 13:11:54 UTC
Hi Alexis,

Why would I want to continue doing jump logistics with your changes as a solo person, a member of a shipping group, or a small corporation that often only has 3-5 people in space? What reason do I have to become the prey and loot pinata? Are you interested in moving people away from deep areas and into fringes with more viable routes?

With this proposal all usage of dropping vanishes. Situations where a group decides to use a carrier for triage in a battle and the other group decides to do the same or use dreads to remove that triage, where said battle started from a subcapital engagement, will vanish due to mechanics and your decision that cynos must be out in dead space. Do you feel that is the type of content that you wish to see removed from Eve?

Eve is a game best played with people but when the solution to a problem is have more people, I am not motivated to back it. The null sec focus of your proposal seems to focus on the concept of more with exclusion of other, more flexible uses by small organizations and even solo pilots who use their jump ability to move around in space and chase after content.




Member of CSM9 and CSM10.

Tabyll Altol
Viziam
Amarr Empire
#20 - 2014-10-14 14:39:35 UTC
I like the idea, but i dislike the randomness of the shiploss, it would be better if i only can jump when the beacon is bright enough or i will land in a diffrent system.

But never the less a big thank you that you for the hard work you put into this idea.

+1

mfg Tabyll
123Next page