Upcoming Feature and Change Feedback Center

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. It’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.

Theres a player in alliance who runs 37 procurer with a boosting rorqual, he mines the 5 rorquals in ore a hr.
Nerfing the mineral faucet of the rorqual wont do a thing, players will either still mine in rorquals or have massive mining barge fleets aka a mineral faucet.

Bit of a draconian nerf, isn't it Fozzie? Nerfing so many aspects simultaneously results in greater unpredictability regarding the results.

Might it be better to take a series of smaller steps and perhaps to address some underlying issues promoting their excessivs employment?

One of the big issues is that Rorquals favour the largest alliances who can defend them at the drop of a hat (cyno). This is problematic because it allows massive economy of scale to those alliances. As usual, power projection is a major underlying cause. While I am a fan of the Rorqual being able to defend itself, I would suggest review of the PANIC button as follows:

Panic module protects mining fleet, but no longer protects the Rorqual. Rorqual and protected mining ships may not light cyno while PANIC active.

Mining mechanics are too mundane to prevent players from up-scaling operations. We have all heard about the guy in Goonswarm running 30 Rorquals. Maybe it's time to look at the fundamental mechanics of mining to encourage active gameplay rather than 'assign mining drone to rock x'.

I totally support resizing of Ore rocks in space. Pls make them larger. That would change the feeling when you are in asteroid belt. It will look like you are in a real mining field

Youv'e said a few times now that you're not worried so much about the Excavator costs - because the cost is due to demand. But given the whole nerf to yield is in part due to the affect on the economy - surely you can see that it's because the only way to get the parts for an Excavator drone is from L4 missions or Drone Regions (or the rare drone site outside drone regions).

It's a problem with the resources needed to make, not demand itself. There needs to be significant increases in the drop rates of the parts required to make an Excavator. Similar to how you guys rescued the Nestor from being a 1.5bn isk battleship hull.

Surely you guys have teh market data to see that.

RE:



At the moment the Rorqual only gets brought out if I have a few logistics pilots available, no interceptor gangs roaming (read uncatchable hit and run tactics with almost no counter) within 5 jumps and a good few friends out mining to benefit from the boosts. Because honestly - 9bn isk worth of hull, locked in space, compared to just using a porpoise or jetcan mining from a hulk seems like the answer is pretty obvious.

This.

When you're doing these mining output balance changes, are you actually doing a breakdown of the mineral faucet? Are rorqs producing too much ore, or are the command bonuses in general? Do you have a target rate for "mineral inflation" like you would have for isk inflation?

And, here comes CCP not sobriety testing their Dev's again. You know there's an app for that now?

CCP Fozzie, for the amount of training time & investment it takes to get into a well skilled Rorqual, the yield is perfectly fine. If the drones are getting nerfed, you should cut the build requirements in half for them and decrease Rorqual trains too, or leave things alone. Im sorry an industrialis bullied you as a child but please dont take it out on my rorq pilots. Im also terribly sorry that people overused combat rorq's but there are better ways of dealing with that than taking away their only viable defense should they, say, get caught in a bubble. Why not make them immune to bubbles, then? You're a fan of awful ideas so that one should catch right on...

I think PANIC should just deactivate any active module on Rorqual other than PANIC and prohibit their activation. And that would be sufficient.

Someone didn't read Fozzie's post...



That's absolutely doing something. There's still a massive difference between someone out mining with 38 accounts one of which is in a Rorqual, and someone out mining with 38 accounts all in Rorquals (or 7, to reference a recent killboard event...).

You'll note that they actually buffed Rorqual boosts with this change so your friend is clearly in the minority of players right now and is playing in a way CCP would rather encourage over massed Rorqual-hoovers.



First off, #2 very much is an issue I can assure you, it just may not be an issue for you...

Your solution doesn't actually work for #2 since you can still fit an Entosis on a Mining Barge and then PANIC, protecting both you and the barge, when you come under attack.

If I can't present an actual threat to someone on grid then they have a lot more freedom and a lot more options to threaten me and my mining fleet. The point is to protect the miners, not only bubble up and wait for rescue. Killing, jamming, webbing, ect a small group of aggressors absolutely counts as protecting a mining fleet.

Plus nothing here guarantees that players won't find something else to abuse (like we're already starting to see in small amounts with Rorqual Logi) at which point CCP then need to find another thing to restrict to keep PANIC from being abusable outside of mining applications, or they could just go with what they've done here.