Are there any plans to reduce rate of fire's dependency on framerate? It's been getting worse, and is a significant game balance issue at this point. I understand it's likely difficult to fully fix, but any improvement would be welcome. * It puts anyone with a subpar computer (such as one at your recommended system requirements) at a much harsher disadvantage than would naturally happen. Even given all headshots, dropping from 67 fps to 40 fps is an extra 30-40 ms of TTK disadvantage at 143 damage. * Veterans are much more likely to be on the good side of this for several reasons, which makes the average new player experience even more challenging. * It hurts some guns much more than others, and throws off their balance. On average, the 1st-gen battle rifles are particularly powerful right now at any range, and guns that have 800+ RoF as their biggest advantage are very weak. * VS and TR weapons' DPSes and TTKs are on average affected noticeably more by this than NC's. On NC, I have plenty of weapon options that don't feel unreasonably hurt by this, but for CQC on VS the stuff I would like to be using clearly isn't performing as it should (and previously did) at framerates I can maintain (60-80 in moderately large fights). * Neutrally, this means TTKs are noticeably longer right now than you would expect by looking at stats. Changing that back to nominal may have other, less-direct effects. I didn't pin down the magnitude of the effect in the late DX9 era of Planetside, but either MaximumFPS or smoothing could get around the worst of it without too much trouble regardless of someone's typical framerates. As I recall, if the actual framerates were at least half of MaximumFPS everything tended to work out well enough. (I wish I'd kept notes and could be misremembering something about the early DX11 era.) After the DX11 update, I wasn't able to get smoothing to do anything useful and MaximumFPS tweaks had to be weapon-specific, but the effect size was manageable at half a frametime (average) added to each refire delay. It seemed like each frame it was just checking if it had been at least [refire delay] ms since the gun had last fired, and would therefore delay by up to a frame too much, but if you knew what RoFs you were optimizing for and could stay capped at MaximumFPS you could make sure the overshoot was small. Now, it's consistent at one frametime average per refire delay, MaximumFPS does nothing, and smoothing is awkward. If you're alright with a 60 fps cap and can consistently get more than 60, enabling smoothing makes everything good, but any time you drop below 60 it goes back to improving nothing, and it's still an unpleasant solution for anyone with a high refresh rate monitor and decent performance to back it up. (Smoothing always caps at 60 regardless of refresh rate.)
THERE IS A WORKAROUND FOR THIS! Tl;dr: add these three lines to your UserOptions.ini under [Rendering], where max is a framerate you can stay above about half of the time and min is 2-5 fps below max: Code: Smoothing=1 SmoothingMaxFramerate=90 SmoothingMinFramerate=88 The Workaround It's as described in the last paragraph of the first post, except that smoothing doesn't actually always cap your framerate at 60. You can adjust that cap with SmoothingMaxFramerate and SmoothingMinFramerate in UserOptions.ini (you'll have to add them yourself under [Rendering]). Max is the cap, and I recommend keeping Min within 5 fps of Max so that it doesn't feel like smoothing (smoothing with a wide range will hurt you in infantry gameplay). It's still tough to figure out where to put the cap. To some extent it's a choice to optimize for large or small fights. If you set the cap high, you get the best of both worlds in small fights where you can reach the cap, but your RoF drops again as soon as there's much going on. If you set it low, RoF is usually good, but the low framerate holds you back in smaller fights where it should be much higher. In my case, 90 lets me spend at least half the time capped (including almost all of it in highly competitive environments such as Desolation) and still feels comfortable, where if I wanted to almost never leave the cap I'd have to drop to more like 55 or 60. If you use generic adaptive-sync (freesync or g-sync compatible hardware) and your cap would be at or slightly above your monitor's max refresh rate, you may want to set the cap a bit below your refresh rate to keep it from falling out of the adaptive-sync range and tearing (smoothing's cap isn't the tightest). If you use vanilla vsync or the Nvidia-specific form of g-sync, the cap should be a bit below your refresh rate so the limit imposed by syncing doesn't keep the smoothing cap from doing its thing. If you don't use any form of vsync, none of this matters. You should make sure no other caps get in the way though (for instance MaximumFPS in the ini should be well above SmoothingMaxFramerate). If you want to test if your current configuration is good, go to VR, get a Promise with a smart feeder (extended mag) or Pulsar LSW with an extended mag, and use a stopwatch or video to time how long it takes to empty the mag (probably three times since there are some opportunities for error). Be aware that smoothing sometimes takes a few seconds to lock in, overshooting the target at first (I've accidentally started tests before it locks to the target framerate). Right now you should expect to see: Code: condition seconds --------------------------- nominal 12.8 no fix 125 fps 14.0 no fix 80 fps 14.7 no fix 60 fps 15.3 no fix 40 fps 16.5 fix applied 80 fps ~13.1 fix applied 40 fps ~13.8 Replicating The Testing An actual refire delay in given conditions is the number of milliseconds to empty the magazine divided by one less than the number of rounds in the magazine (the -1 is because there's no delay on the first round). Compare these against nominal refire delays, which are [60,000 / rounds_per_minute]. You'll also want to know your frametimes (milliseconds per frame), which are [1,000 / frames_per_second]. With smoothing turned off, I've been unable to find any situation for infantry weapons in March 2020 in which [actual_refire_delay = nominal_refire_delay + frametime] doesn't hold true, to within 2 milliseconds. This includes varying framerates over a very wide range, guns with varying rates of fire, varying framerate limiting factors (CPU / GPU / MaximumFPS), varying strengths of each framerate limit factor (weakly GPU-bound could potentially be different from strongly GPU-bound etc), and varying CPU-GPU buffering behavior (RAL enabled versus disabled). I also haven't been able to find any traces of the discontinuities that existed shortly after the DX11 update. With smoothing turned on while the computer is NOT able to generate as many frames as SmoothingMaxFramerate, I mostly see behavior as if smoothing is turned off, but have not run very many or conclusive tests. A couple of tests 10-15 fps away from SmoothingMaxFramerate resulted in lower refire delays than expected, while others 5 fps away behaved as if smoothing was turned off. I don't have a theory on this. More notable things I haven't tested include vehicle weapons and being strongly CPU-bound by different factors (core count / clocks / memory latency / memory bandwidth). I have tested occasionally as recently as late May 2020, but the most thorough testing was done in March. Miscellaneous I'm now trying to spread knowledge of the workaround far and wide. This will be even harsher on the new player experience if someone comes in at 50 fps not knowing about the workaround and their GR-22 is only dealing damage to match many veterans' NS-15M2s, but it'll mitigate the rest of the issues. With smoothing turned on while the computer is otherwise able to generate more frames than SmoothingMaxFramerate, I still see a smaller penalty to refire delays, on the order of 1/6th to 1/4th of a frametime. I don't have any theories on this, and it could be a signifcant penalty itself in some cases. I don't know whether RoF is good when smoothing's range is wide (min is low) and smoothing is limiting the framerate to something less than the cap. You'll spend a lot of time in this situation if you regularly have very slow frames but most are fast. Keeping the range narrow is safe either way. Smoothing does affect input latency more than MaximumFPS. It feels more like being CPU-bound at the specified framerate rather than a pre-input cap. Combine that with the extra frame or more of delay PS2 has on non-mouselook inputs and it's worth keeping the cap as high as feasible. I didn't investigate thoroughly, but sometime in the relevant timeframe (for the last time RoF behavior changed) it looks like PS2 fixed something about how it measures time. My system (R7 1700) has a problem with using HPET when it shouldn't (HPET is slow and some games run faster when I directly disable it), and PS2 used to be affected by this but isn't anymore. This can be seen both in CPU-bound framerates and in the kernel time it uses as reported by Process Explorer. What I haven't done is confirm that this is a change in PS2's behavior rather than something else about my system, as I don't have a good enough baseline for other games' behavior. If this is a change in PS2, it's likely to be relevant.
Since the DX11, frame rates have been extremely inconsistent, only to be worsened by the Escalation update. However, frame rates aren't the worst thing tat impact ttk. Low frame rates prevent you from accomplishing certain maneuvers, and can make simple tasks like turning around or simply running seem sluggish and difficult unless the player is used to it. What I find drastically increases ttk is the lat/ping spikes and the headshot multiplier. Lat causes some shots to not register, poor hitreg and the drastic headshot multiplier + nanoweave means that veterans who are familiar with how to leverage the game's mechanics in their favor will be at a significant advantage. Ofc, cranking up the frames through good hardware and potato settings can only improve your effectiveness in game, but since it is an issue that affects everyone randomly, and can be fixed by smoothing (allegedly, this would give you unrestricted ROF for frame rates as low as 5fps)! There is an advantage to low frame rates however, in the sense that they reduce the affects of recoil. https://www.reddit.com/r/Planetside/comments/7o3dq7/weapon_fire_rate_still_fps_restricted/
Today's update did something good. In times to empty a Promise extended mag, I now see 14.5 when I would have seen 14.9 (70 fps GPU-bound) and 13.8 when I would have seen 14.0 (120 fps CPU-bound).
After today's patch (which called out some changes in the area), I see ~1x frametimes added instead of ~0.8x. This is back to early 2020 behavior. I recently upgraded my CPU from a 1700 to a 5800X (and 1R RAM to 2R), didn't check the RoF bug on the 5800X pre-patch, and in principle this could be the relevant change instead of the patch. I would like to recheck this on the 1700, but might not get back to it anytime soon.
My framerate drops to 30FPS in huge battles, I am using a Laptop with 5800H which runs at 3.7 GHZ. They didn't add Multithread workloads in the DX11 update. Basically they're lazy. DX11 has Multithread workload support and this update has only improved the graphical side of performance issues so I still suffer performance hits regardless.
