Looks like your connection to Bethesda.net Community Beta was lost, please wait while we try to reconnect.

Weapon fire rates are linked to frame rates... Clip included.


Log in to reply

... And I thought not being able to make bridge to rail in old quake because your FPS was too low was bad... now your guns do less damage because your FPS is too low...

https://www.youtube.com/watch?...

Edit: So I also wanted to confirm whether the slower fire rates were also directly tied to your ability to do damage, just in case there isn't any funny prediction business on the server end mitigating this, so as expected there isn't and your damage is in fact directly effected.

https://www.youtube.com/watch?...

So turbotortoise43 went to the trouble of doing this in a more professional manner which illustrates the same problem:

https://www.youtube.com/watch?...

Update: I've removed the previous results and cleaned up my testing method big time from what you can see in the clip... and the results are shocking as hell. I thought we were pretty much safe playing in the 110-144 FPS region, but this is not the case.

 So now as opposed to just setting out to prove that frame rate and fire rate are correlated, I set out to determine exactly what kind of fire rates we get at the most commonly set FPS and what frame rates we actually need to be getting to see the fire rates that we expect.

So I created a macro with my roccat software that simply holds the fire key in for 4000 MS. I push the button while limiting the game to different frame rates and measure how many shots we're shooting in 4000 MS and then repeat 5-7 times because there is a margin of error here of between 0 and 99 MS over 4000 MS which I see in QL as well, which results in a difference of 1 shot every now and then over the 4 seconds, so I think it's slight imprecision in the roccat software. 

As a control test, in QL this test yields the same fire rates for LG regardless of whether the game is running at 30 FPS or 300 FPS.

Anyway, the results are bonkers crazy, because even at 144 FPS we're not getting our expected fire rates. If you want your expected fire rates, you need to be up in the 200+ region.

In 4000 MS.

LG:
200 FPS: 80 cells, 20 per second [140 DPS]
144 FPS: 72 cells, 18 per second [126 DPS]
120 FPS: 69 cells, 17.25 per second [120.75 DPS]
60 FPS: 61 cells, 15.25 per second [106.75 DPS]

MG:
200 FPS: 40 rounds, 10 per second [80 DPS]
144 FPS: 37 rounds, 9.25 per second [74 DPS]
120 FPS: 37 rounds, 9.25 per second [74 DPS]
60 FPS: 35 rounds, 8.25 per second [66 DPS]

HMG:
200 FPS: 40 rounds, 10 per second [100 DPS]
144 FPS: 37 rounds, 9.25 per second [92.5 DPS]
120 FPS: 37 rounds, 9.25 per second [92.5 DPS]
60 FPS: 35 rounds, 8.25 per second [82.5 DPS]

Zoomed HMG:
200 FPS: 20 rounds, 5 per second [75 DPS]
144 FPS: 19 rounds, 4.75 per second [71.25 DPS]
120 FPS: 20 rounds, 5 per second [75 DPS]
60 FPS: 19 rounds, 4.75 per second [71.25 DPS]

SNG:
200 FPS: 40 rounds, 10 per second [200 DPS]
144 FPS: 36 rounds, 9 per second [180 DPS]
120 FPS: 37 rounds, 9.25 per second [185 DPS]
60 FPS: 35 rounds, 8.25 per second [165 DPS]

Anecdotally I found during the 200 FPS tests that if I was accidentally in an area where I wasn't quite getting 200, but rather 180ish, I would still see drops in fire rates...

Consider the fact that when playing a game, with players in it, with 144hz and 120hz monitors being all the rage, that is our most common FPS, there probably isn't anybody around that is getting consistently max firing rates @ 200 FPS+.

Thinking about the effect this has particularly on LG, it's not only the drop in DPS that hurts so much, it's the fact that with less shots being sent out per second, a sweep over a target has less chance to yield a hit at all, combine that with the speedy/tiny/pixel perfect hit boxes and you have one really crappy LG.


Log in to reply

Crazy...will test here as well and report back.


Log in to reply

Client tickrate should be disconnected from the framerate.


i7 7700K 4.2 / ASUS Formula IX / 16GB Corsair 3200 Dom Plat
EVGA 1080 FTW Hybrid 8GB / ASUS 279Q / Phanteks Luxe
SteelSeries Rival 310 / Corsair K70


Log in to reply

Being that I was on a 60hz monitor and a capped fps for my first 3 months of QC, I had a feeling this was happening. Is anyone surprised? I think not.


No one gives credit to skill but instead they blame the game for the reason they are losing.


Log in to reply

So if I'm understanding this correctly, the higher your framerate the more likely in a face to face with same character, same weapon, constant hit contact, the player with a low frame rate will always receive more damage. Wow how can this be allowed...! 


Log in to reply

Well, i was expecting differences in hits in movement - that would be normal that on lower fps less frames are beeing registered and you can miss. But c'mon, WTF? On static shooting , there should be no difference in ammo usage, thats total desync for this kind of game

It is unacceptable and needs to be repaired as quickly as possible, as it can lead to other errors...


Log in to reply

@cqeflash said:

So if I'm understanding this correctly, the higher your framerate the more likely in a face to face with same character, same weapon, constant hit contact, the player with a low frame rate will always receive more damage. Wow how can this be allowed...! 

 Well up to a point yes it seems that way, but it's not like 300 FPS gives your guns super fire rates, they are clearly capped to the fire rates intended and that cap seems to start somewhere around 100-120 FPS. But yea this is what it seems like, if you're getting 60 FPS in an LG v LG fight against someone with 100-120 FPS you're at a huge disadvantage. Your gun is 20% weaker than his basically, although you'll be able to fire for longer before running out of ammo, awesome!


Log in to reply

i would like to hear about this will be corrected. many of us talked about it happening but it was never proven with numbers before. at the very least have it cap at 60fps which is the standard for most monitors still


Log in to reply

I've just wanted to complain in another topic about that. I'm sure it's related.

https://bethesda.net/community...

Why the hack the amount of network data depends on your graphics FPS? So if you want to lower network load to avoid regular 104 error, you have to sacrifice your smooth game play.


Log in to reply

@shaseofbase said:

... And I thought not being able to make bridge to rail in old quake because your FPS was too low was bad... now your guns do less damage because your FPS is too low...

https://www.youtube.com/watch?...

So as your frame rate drops below 90, your LG fire rate decreases with it... Actually... all your weapon fire rates drop ... I thought this was LG only at first since it was my focus after the last patch I noticed some weird $@#! going on, but this is for all weapons, though LG seems most effected. I don't think anyone is too concerned with their fire rates at 10 FPS, but this is the clearest display of the fact that it changes with FPS since the rates are so vastly different. But what is really alarming is that you start to suffer from this effect if your FPS drops to around 90 or below, from 90 to 60 there seems to be a sharp drop off. At 60 FPS you're firing LG about 20% slower than a 110ish FPS+ player, and 60-90 FPS is probably a very standard sort of frame rate range.
Tested on an empty DM server to my local DC with ~ 3ms ping.
160 FPS: 70 cells used 
144 FPS: 70 cells used (Based on this + 160fps result we know the walk I'm using lasts about 3.5 seconds since the fire rate caps here and we know it's 20 shots per second.)
90 FPS: 67 cells used
60 FPS: 57 cells used (~16 shots per second, ~20% drop)
30 FPS: 55 cells used 
10 FPS: 36 cells used (~10 shots per second, ~50% drop)
Anecdotally, I've found the same deteriorating fire rates for HMG and rail, so I assume it applies to all weapons, but they are effected to somewhat different degrees

 Same thing, happened in Doom MP.  


spec: intel i7 6 cores 4930k @4,4 ghz, 8 gb DDR 3, gtx 1080 @2100mhz, ssd 250 mb, windows 7 64 bit


Log in to reply

the whole netcode is connected to graphic card ?

should be other way around ? ( if possible)

or make servers with different FPS 60, 90 , 120, 144 if now we mixed all with different FPS this is the lag coming from !!!


Log in to reply

I feel this has more to do with how physics is being calculated based on frametime than the fire rate being slower,  would suggest you try and record at 60fps on every framerate and count how many shots are being fired under 1 second durations.

The reason why i say this is because there is currently a bug in physics acceleration that makes people move in different speeds while running and jumping, this makes calculating shots fired  based on run distance very inaccurate.


Log in to reply

@pitchatan said:

I feel this has more to do with how physics is being calculated based on frametime than the fire rate being slower,  would suggest you try and record at 60fps on every framerate and count how many shots are being fired under 1 second durations.
The reason why i say this is because there is currently a bug in physics acceleration that makes people move in different speeds while running and jumping, this makes calculating shots fired  based on run distance very inaccurate.

Firstly, you can work out the time taken for the walk by looking at the time in the clips, or use your stop watch on your phone. The times taken to complete the walk are the same.

Secondly, If you were right, then the 36 cell (10 FPS) walk should be almost twice as fast as the 67 cell (90 FPS) walk. It would look totally ridiculous, the character would have to be walking at almost twice the speed. 

This is very obviously not the case.


Log in to reply

Oh my god. Good work !

I was testing the network upload at different framerate recently, totally crasy. Trying to figure out, why on an empty server ( custom game ), I can slide around with Slash no sweat and why in a TDM, I'm really struggling to move around smootly because of the micro stutter and warping of players. ( I was planning on making a high FPS recording with an action cam )

You would think they learned not to link something to framerate after the Q2/Q3A trickjumping issue, but no. It's even worse now, they managed to link damage to FPS somehow. 

This is definitely something for the Q&A video's ! @Community-Manager    


i7 4790 @ 3.6Ghz / Asrock z97m / 16 GB Corsair XMP 1866 / Sapphire RX Vega 64 / Mushkin 480 GD Triactor SSD / Corsair RM 650 / Bitfenix Phenom mATX / LG 29UM58-P / vDSL Scarlet 50mbit down/4mbit up


Log in to reply

Nice work my friend. 

Its almost November but critical bugs count just increase every day. Not sure they will be able to fix them all till 2018Q1 with current speed. 

PS: Now children can blame that they lost because mom haven't bought new computer)


Log in to reply

@shaseofbase said:

@pitchatan said:
I feel this has more to do with how physics is being calculated based on frametime than the fire rate being slower,  would suggest you try and record at 60fps on every framerate and count how many shots are being fired under 1 second durations.
The reason why i say this is because there is currently a bug in physics acceleration that makes people move in different speeds while running and jumping, this makes calculating shots fired  based on run distance very inaccurate.
Firstly, you can work out the time taken for the walk by looking at the time in the clips, or use your stop watch on your phone. The times taken to complete the walk are the same.
Secondly, If you were right, then the 36 cell (10 FPS) walk should be almost twice as fast as the 67 cell (90 FPS) walk. It would look totally ridiculous, the character would have to be walking at almost twice the speed. 
This is very obviously not the case.

Where exactly did you get "twice as fast" from?

The difference come  from float precision,  every physics step is calculated by the timebetween physics frame, or in the clients case the time between every frame.

No one said anything about things going twice as fast, thats something you came up with yourself.

Your walks are also not exactly the same for the simple reason that you started shooting faster/slower before you started walking. 

It's literally 20 shots per second, meaning any time difference in your walk/shoot timing will offset the amount of shots being fired.

This is why counting shots in a duration is better as you can time it with the firing animation and go frame by frame if you have to.


Log in to reply

@pitchatan said:

@shaseofbase said:
@pitchatan said:
I feel this has more to do with how physics is being calculated based on frametime than the fire rate being slower,  would suggest you try and record at 60fps on every framerate and count how many shots are being fired under 1 second durations.
The reason why i say this is because there is currently a bug in physics acceleration that makes people move in different speeds while running and jumping, this makes calculating shots fired  based on run distance very inaccurate.
Firstly, you can work out the time taken for the walk by looking at the time in the clips, or use your stop watch on your phone. The times taken to complete the walk are the same.
Secondly, If you were right, then the 36 cell (10 FPS) walk should be almost twice as fast as the 67 cell (90 FPS) walk. It would look totally ridiculous, the character would have to be walking at almost twice the speed. 
This is very obviously not the case.
Where exactly did you get "twice as fast" from?
The difference come  from float precision,  every physics step is calculated by the timebetween physics frame, or in the clients case the time between every frame.
No one said anything about things going twice as fast, thats something you came up with yourself.
Your walks are also not exactly the same for the simple reason that you started shooting faster/slower before you started walking. 
It's literally 20 shots per second, meaning any time difference in your walk/shoot timing will offset the amount of shots being fired.
This is why counting shots in a duration is better as you can time it with the firing animation and go frame by frame if you have to.

You are trying to be too smart for your own good.

The logic in this is very simple, The walk is roughly 3.5 seconds for every test, yet the amount of cells spent is vastly different. 

"this makes calculating shots fired  based on run distance very inaccurate"

Run distance is simply used to measure a repeating period of time, and you can use a stop watch to do the same thing, and it's clear that the runs take roughly the same amount of time no matter the frame rate. Whether it takes 3.5s for one test and 3.4s for another is of no consequence given how massive the fire rate difference is between top case and bottom case.


Log in to reply

Good find ShaseOfBase.


Log in to reply

@shaseofbase said:

... And I thought not being able to make bridge to rail in old quake because your FPS was too low was bad... now your guns do less damage because your FPS is too low...

https://www.youtube.com/watch?...

So as your frame rate drops below 90, your LG fire rate decreases with it... Actually... all your weapon fire rates drop ... I thought this was LG only at first since it was my focus after the last patch I noticed some weird $@#! going on, but this is for all weapons, though LG seems most effected. I don't think anyone is too concerned with their fire rates at 10 FPS, but this is the clearest display of the fact that it changes with FPS since the rates are so vastly different. But what is really alarming is that you start to suffer from this effect if your FPS drops to around 90 or below, from 90 to 60 there seems to be a sharp drop off. At 60 FPS you're firing LG about 20% slower than a 110ish FPS+ player, and 60-90 FPS is probably a very standard sort of frame rate range.
Tested on an empty DM server to my local DC with ~ 3ms ping.
160 FPS: 70 cells used 
144 FPS: 70 cells used (Based on this + 160fps result we know the walk I'm using lasts about 3.5 seconds since the fire rate caps here and we know it's 20 shots per second.)
90 FPS: 67 cells used
60 FPS: 57 cells used (~16 shots per second, ~20% drop)
30 FPS: 55 cells used 
10 FPS: 36 cells used (~10 shots per second, ~50% drop)
Anecdotally, I've found the same deteriorating fire rates for HMG and rail, so I assume it applies to all weapons, but they are effected to somewhat different degrees.

 It is looks like lead developers are amateurs.


exeshe4ki.com


Log in to reply

@shaseofbase said:

@pitchatan said:
@shaseofbase said:
@pitchatan said:
I feel this has more to do with how physics is being calculated based on frametime than the fire rate being slower,  would suggest you try and record at 60fps on every framerate and count how many shots are being fired under 1 second durations. The reason why i say this is because there is currently a bug in physics acceleration that makes people move in different speeds while running and jumping, this makes calculating shots fired  based on run distance very inaccurate.
Firstly, you can work out the time taken for the walk by looking at the time in the clips, or use your stop watch on your phone. The times taken to complete the walk are the same. Secondly, If you were right, then the 36 cell (10 FPS) walk should be almost twice as fast as the 67 cell (90 FPS) walk. It would look totally ridiculous, the character would have to be walking at almost twice the speed.  This is very obviously not the case.
Where exactly did you get "twice as fast" from? The difference come  from float precision,  every physics step is calculated by the timebetween physics frame, or in the clients case the time between every frame. No one said anything about things going twice as fast, thats something you came up with yourself. Your walks are also not exactly the same for the simple reason that you started shooting faster/slower before you started walking.  It's literally 20 shots per second, meaning any time difference in your walk/shoot timing will offset the amount of shots being fired. This is why counting shots in a duration is better as you can time it with the firing animation and go frame by frame if you have to.
You are trying to be too smart for your own good.
The logic in this is very simple, The walk is roughly 3.5 seconds for every test, yet the amount of cells spent is vastly different. 
"this makes calculating shots fired  based on run distance very inaccurate"
Run distance is simply used to measure a repeating period of time, and you can use a stop watch to do the same thing, and it's clear that the runs take roughly the same amount of time no matter the frame rate. Whether it takes 3.5s for one test and 3.4s for another is of no consequence given how massive the fire rate difference is between top case and bottom case.

I am suggesting a sane method of testing this that isn't down to your execution, yet somehow you are still trying to instigate a pissing contest. :P

Your method of counting time based on the run distance doesnt work well for the simple reason that you cannot time it exactly the same every single time and you will end up with an offset between shooting and moving every time.On top of that there is also the float precision issue i mentioned that will affect it further.

20 shots per second is 50ms, 50ms is enough time fire off 4-5 shots before you even start moving.  This will affect your end result as it did with your second test where you were off by roughly 10 shots as you started shooting later.

I am also not saying you are wrong about the shots being fired at different rates, though this should only be happening when you are getting to the point of dropping below 20fps/20packets per second. 

The reason for this is very simple as every frame sent contains your input(angles,buttons etc), if you are missing input you are not shooting as fast. 

This is the case in every server authoritative game that are not using fire/shoot switches (boolean value determined by input).

I'll reiterate, your testing method is flawed and you are presenting your results based off a flawed method. 

If you end up with the same results using my method then so be it, i just want it to be accurate.