Perhaps instead of a fixed 2 seconds, make it the time it takes for one shot to be fired.
(ect Gat 2, .088 second firing rate, .88 second delay---Orion XGX .2 second firing rate, .2 second delay)
I don't care either way, I don't use autofire on mobile or PC.
#JustThatGood

-1

I've never had an issue with people using AF against me, Roda said it best.

Instead of nerfing it, expand it to PC pilots.

So, what ever happened to trying that 100ms delay?

Can we get this implemented please? I've lost a few ships to strafing in front of a mobile ship to close and instant dying to this insanely fast auto fire

-1

Well, I'm just a newbie playing on mobile, but I guess that means I'm in the affected group. I have a couple points I'd like to make concerning this suggestion, but I do think they can be addressed.

1. I admit I've encountered multiple situations where autofire kicked in much faster than I would have been able to, but in more than three-fourths of these incidents, had I been able to, I would have not ceased fire prior to (spinning on a flanking enemy/momentarily losing lock on a target/being struck by an enemy and forcefully spun to face them/etc.)

2. While I don't believe a delay will have much effect on low-level play, the few more skilled mobile players (who I hope exist) will suffer. I'd hate to be in their shoes.

3. Couldn't a mildly experienced player bypass this delay by manually opening fire just before the target enters effective range?

Fighting other players on mobile is a huge disadvantage. It's hard to overstate just how much of an advantage PC players have against mobile in PvP. Autofire narrows this gap ever so slightly, but it is still large.

To give one example, there is no vertical strafe on vanilla mobile. This basically hamstrings one in PvP; you are losing one entire degree of freedom. A second example would be that you must long press a button to switch between the options of having Activate ready (necessary for chases), and toggling Flight Assist (essential in a dogfight).

Having the ability to instantly fire when a target is in one's firing solution does not make up for these handicaps, neither is it 100% accurate. When using rails, it's not always desirable to fire when one's target is in the solution, due to impulse. One must also consider relative momentum, which the leadoff reticle does not calculate.

This change is over the top in the extreme - if people are so unhappy about rails being used with autofire (and to be fair, i think in the case of rails specifically firing by autofire at all seems wrong) then stop the rails from firing via autoaim.

The blanket usage of this mitigates the only way an android touchscreen pilot can fight, whilst limited to two control points, you must turn and strafe, or strafe and fire, or fire and turn, but never all three, unless autofire is used. Pc players can hold fire and strafe and turn, and do so all before the autoaim reticule turns yellow, this means that they do not sit there waiting for that act before they shoot which is what this change is essentially asking you to believe. They hold fire, and then turn or strafe until it goes yellow. This 0.2 delay is longer than the reload rate on a gauss gun, the slowing firing regular projectiles.

Yes, rails are deadly, and yes, using them with autofire makes them more so, and is a very much unfair advantage for a weapon which is designed and originally used as a timing weapon, you tap a single shot at exactly the right moment to get a hit. That is certainly relevant to have a delay on. Personally, id say not a delay but altogether disabling autifre for them.

But not on other weapons that are fired in salvos, standard energy weapons like neuts/posis/gauss should not be delayed at all.

The reality is that even with the autofire and before without delays, touchscreen pilots face a huge disadvantage trying to simply fire enough shots to ever get far in pvp.

I do think that having some game mechanism disabling autofire if a pad is in use would be very appropriate tho.

Go here: https://www.humanbenchmark.com/tests/reactiontime/

Post your average and if that many ppl can come in in less than a 200ms average I'll plus 1 the change back.

FYI: Measured a Reaction Time of 275.0ms

In fairness those reaction time websites aren't super accurate. 250ms, which is about my average on that site, is a quarter of a second. Comparing that to an audible representation of sounds a quarter of a second apart, its pretty obvious my reaction time is much quicker -- more on the order of 166ms (1/6 second) or faster.

In other words there is processing that obfuscates the actual response time (as stated on the website).

Not being a touch device user I cannot test out the new delay. But if it seems excessively unnatural, I don't have a problem making it less (say 160ms). Best would be a variable delay (i.e. between 0-50ms less) to account for accidental luck. When you lay a static/blanket delay you take out one humanizing factor in pursuit of another.

It certainly shouldn't be zero though.

"this means that they do not sit there waiting for that act before they shoot which is what this change is essentially asking you to believe. They hold fire, and then turn or strafe until it goes yellow."

This is a good point. I usually don't do that since that technique is only viable for rapid-fire weapons and I normally use gauss. However, even a delay of zero would not accomplish that; it's an orthogonal concept. I'll go make a new suggestion thread with a solution for that.


"One must also consider relative momentum, which the leadoff reticle does not calculate."

You mean relative velocity, not momentum, and I'm pretty sure that relative velocity is exactly what the leadoff indicator uses. What it fails to account for is acceleration, which is why a simple barrel roll defeats it.

+1 adjust the delay regarding weapon type or remove completely this delay: cos keeping it disadvantages the majority of vo players and removing it or adapting it only bruises a few egos.
I only met one new player using rails effectively on a mobile. You may die once then you adapt and apply flares.
And if you really want a delay it should be on the weapon consecutive shots like a cooling delay and it should apply to everybody.

Wash, have you ever tried to PvP someone on mobile?

You mean relative velocity, not momentum

I definitely meant momentum, although I could be wrong. My point is, even with zero delay, autofire doesn't help rails as much as much as it does blasters since it doesn't take into account how much the target can change course in any given situation and rails are very sensitive to when you pull the trigger. I don't think adding a delay will help at all, and as I pointed out above mobile users are already at an extreme disadvantage against PC.

While deploying rails on PC, sometimes a target's vector will be drifting toward me relatively speaking. The reticle may turn yellow although it's not advisable to take a shot. If I had had autofire enabled, I would have just wasted a rail shot. The best time to fire a rail is if I'm moving directly at the target and the target is moving directly toward me. This ideal situation is modified by the target's mass.

Furthermore, there are other visual indicators which allow pilots to predict when a reticle will turn yellow. Knauf and Wash's experiment is flawed because it does not give any predictors to the subject. It's not simply a matter of reaction time: prediction is involved.

A more accurate representation would be to start a stopwatch and try stopping it at 1 second, as Roda Slane suggested.

Firstly the delay should be on the firing script not on the aim portion, they should have the option to manual fire with the same auto aim as pc.

Secondly the testing knauf and I did we alternated between platforms and loadouts. On mobile using auto fire we were both able to land instant quad rail kills as well as energy streams that were exremely if not impossible to strafe out of that couldn’t be done when firing manually on PC.

Thirdly it is an optional platform not required. Just because the default UI is not condusive to instant combat is not a reason for them to get instant fire reflexes from the game client. It creates a crutch that is relied upon instead of forcing them to actually learn to fly and fire.

Fourth. The combination of a game controller & auto fire is stupidly op. The detection of a controller should have disabled auto fire.

Did you try mobile versus PC without a controller? Also, try fighting random people in b8 rather than just each other?

I'm not sure what platform you mean when you write "not required". Are you saying mobile is not a required platform? Most of Guild's traffic comes from mobile, if I'm not mistaken.

Yes we did mobile vs pc without controllers for the testing. I cdid a controller for one fight just to see.

It is not required to play on mobile. Its just popular because it is free.

The combination of a game controller & auto fire is stupidly op. The detection of a controller should have disabled auto fire.

^ The area of most concern. Touch-based platforms with controllers are superior to PC with the same controllers because of auto fire.

The question is can GS more exclusively target this particular type of user rather than "all touch based systems"? Or, if they can, why did they choose not to?

The problem is not the average newb with autofire (they can have instant autofire all day long and nobody would care), it's the experienced long term player who gains the unfair insta-shooting ability, all other things being fairly equal.

"The problem is not the average newb with autofire (they can have instant autofire all day long and nobody would care), it's the experienced long term player who gains the unfair insta-shooting ability, all other things being fairly equal."

I will agree with that.

+1 this is especially OP when the mobile player is automatically firing perfectly place cap rails from their goli or dent.

thanks, this solved the nasty autofire rails. that got out of hand... skilled mobile players dont use AF later anyway.