Upcoming Feature and Change Feedback Center

#864 - 2017-03-14 20:42:12 UTC
Deleted some off-topic posts as well as some posts with offensive language.



Please remember to be respectful!

And so the long awaited Rorqual rework is undone in less than 6 months time returning it to purely a boosting role stuck on grid for 5 minutes at a time.

So Fozzie, when do we get our capital mining barge with short range mining lasers?

I was being serious believe it or not. Since the players have shown they want a capital level mining vessel.
Mining lasers are more easily balanced than mining drones, this is a fact.
Short range means they have to move around rather than sit in one place vacuuming everything in sight.
Making it a whole new ship will allow for them to avoid allowing it to use the panic module and industrial core meaning no super tank or invulnerability shenanigans.

Mineral market will adjust and strike a balance with other activities, it always does. Which is why these nerfs never made sense to me in the first place other than to protect high sec miners who refuse to move to null where it would be more lucrative and just as, if not more, safe than their current venue.

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.

Well to be fair mining is mostly AFK anyway.
You just sit there scooping up asteroids with 2 fingers in an orifice (I'll pick "Nose" this time)