What's the point of a 10 billion + investment for a ship and even more for a character if you can make the same amount now in a carrier which can be nearly fully insured and 1/5th of the cost or AGAIN NEARLY RUNNING INCURSIONS THE SAFEST THING IN THE ENTIRE GAME.

Stop making changes to things that require people to actually have some risk as a side to their isk making.

TBH that's not saying much.

Hey everyone. Thanks for the passionate feedback so far!

I'm going to go through a bit of Q&A from the thread so far, but first let's spend a little time diving into the specifics of the proposed PANIC module changes:

There are three separate use cases that we are at least somewhat concerned about with the PANIC module:

1. The use of the PANIC module alongside tackle modules (such as the Heavy Warp Scrambler) to provide very durable tackle for capital fleets.
2. The use of the PANIC module alongside cynosural field generators to provide very durable secondary cynos for capital fleets.
3. The use of the PANIC module as a survival mechanism for entosis Rorquals that come under significant attack.

Use case #1 is the one that we've heard the most concern about from players and the one that many people have been suggesting alternate fixes for in this thread. However use case #3 is probably the most important one to study to help identify the best possible solution to all three problems.
In the context of use case #3, simultaneous use of the PANIC module and entosis link isn't the problem as that is already disallowed. You can't activate the entosis link while the PANIC module is running and activating the PANIC module breaks the entosis connection and halts the capture progress. However even with these restrictions the sequential use of entosis links and the PANIC module can be very powerful. A Rorqual can start capturing the node and only activate PANIC if it comes under too much fire to tank normally. Then the PANIC module provides the time needed for a reinforcement fleet to arrive at the command node and drive off the attackers. In this case the issue isn't that the PANIC module can be used at the same time as the entosis link, but that the Rorqual can use the entosis link and keep the PANIC module as a "get out of jail free" option as needed.

Keeping the three troublesome use cases above in mind, there are three core reasons we were attracted to the idea of approaching the problem with a situational PANIC activation restriction rather than through a similar restriction to what we already use with triage and the networked sensor array. I'll list them below in order from least important to most important:

• There's value in trying to reach the same goal through a smaller number of rules that players will have to remember. Three separate rules (one for ewar, one for cynos and one for entosis) could probably be used to solve these problems but if we have an opportunity to reach the same goal with fewer exceptions we'll generally prefer the single rule.
• If possible, we would like to preserve the use of both cynos and ewar by mining Rorquals while they are defending their fleet with the PANIC module. Cynos serve a valuable purpose in helping them get support fleets to their position, and ewar helps them present an actual threat to their attackers during the PANIC period.
• Most importantly, we were concerned that if we tried to solve the tackle and cyno use cases by restricting those functions while the PANIC module is running (similarly to how ewar is restricted while triage is active) or even by removing the ability to lock targets while the PANIC module is active, we would simply shift the problem into something more similar to what we're seeing with entosis right now. Although such restrictions would prevent a Rorqual from tackling or cynoing with PANIC active, it would not prevent a Rorqual from tackling or cynoing and then saving the PANIC activation as a "get out of jail free" card in case they come under too much fire. Considering the fact that people have the option of using multiple Rorquals and that even threatening a Rorqual's tank requires a fair amount of DPS to start with, this end result would be only a slight improvement on the current situation.

As for the reasoning for this proposal including a target lock restriction instead of a proximity check, the main motivation is to avoid the server load associated with large area proximity checks. For people concerned about jams and damps, remember that the Industrial core provides 100% ecm resistance and 75-80% damp resistance while active. This proposal does mean that Rorquals will be more vulnerable after finishing the last rock in a belt and while moving, but our current impression is that those limited periods of extra vulnerability have the potential to generate interesting gameplay. ItGÇÖs also worth remembering that the Rorqual has a very significant set of defenses even without the PANIC module.
We are very interested in hearing suggestions of alternate concepts for solving these problems, but I'd caution against assuming that this question is a particularly simple one.

There has always been a premium for more powerful ships and abilities in EVE. As power increases, cost increases faster.
We'll be happy with Rorq balance someday when players have interesting choices to make when deciding how many Rorquals to bring and how many Hulks to bring.

The Rorqual represents the most powerful version of all three mining foreman pillars by itself; capable of providing strong Mining Foreman Bursts, repairing allies and fighting off enemies, and vacuuming up ore faster than any other ship in New Eden.

Your math is off. The paper yield got chopped by 25% once, then that remaining 75% got chopped by 25%, which leaves you with ~56.25% of the original post-changes level.



Yes, and those people in massive coalitions make up the vast majority of Rorqual users and thus the majority of mineral influx that is causing market problems.

A smaller group that only has 1-2 Rorquals and still uses Exhumers actually benefits from this change because now those boosted Exhumers are mining more compared to a Rorqual, and this will likely push some people out of Rorqual Mining, meaning that demand and price for the Excavators should drop and the mineral price should recover.

On top of that this makes it more viable, relatively, to just boost with a Rorqual and mine with Hulks, since the hull itself is only ~3B and pays out ~2.2B with full insurance.

Balancing mining.... are you having a laugh? Why on earth do you need to spread out ores in sites even more? Its already difficult enough getting everyone close enough for boosting (as rocks die off). Not all of us have rorq's you know....

To solve the problems stated by CCP over the PANIC mode on Rorq's, why not just get rid of it all together. This solves the problem of invulnerable tackle, entosos or combat cyno etc.
To compensate for this make the industrial core not anchor the ship in place. This way a Rorq mining can align and warp out if needed. The Rorq is a capital class ship so it still has a strong tank which can fend of small gangs which it currently can with out the PANIC mode.

But...mah yields!

(I'm not disagreeing with you, just pointing it out before someone else does....)

Tangent: It's interesting to speculate about why CCP thought the rorqual numbers were reasonable in the first place. Perhaps they expected a spike in mineral demand from alpha clones, who buy/lose ships but have pathetic mining abilities? Or maybe they made predictions based on miners switching from hulks to rorquals, without (sufficiently) factoring in players who had never mined switching into the profession and away from other income streams?

There were posts (like mine ) predicting rorquals would be multiboxed to death within minutes of the changes being announced in October, and I'm sure they saw that coming themselves, but for some reason they underestimated the total economic disruption.

CCP should refund isk spent on a fitted rorqual/drones in proportion equal to the percentage amount of the nerf. IE. reduce yield by 25%, give us a 25% refund on the amount of isk spent to build one of these things.