Player Features and Ideas Discussion

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.

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.

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*

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.

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.

reserved 8/7

Come on. Let's keep it going.

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

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! ;)

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.