BF4 shooting mechanics

3VerstsNorth

Skynet T100

(3,187)

Posts: 1,614

Date of registration
: Apr 12th 2013

Platform: PC

Location: Guilin Peaks, Finland

Battlelog:

Reputation modifier: 14

1

Sunday, October 19th 2014, 10:36pm

How does shooting work in BF4?

Background
“Press LMB and soon a bullet is fired” said someone in the Algorithms thread. Sure, tell me more captain obvious. Kk, ez; “Keep LMB down and more bullets are fired at a rate of “RoF” rpm and at an interval of “60/RoF” seconds in between the shots”. These kinds of implicit assumptions about infinite temporal resolution have always been the basis of time-to-kill comparisons, spread-decrease optimized bursting rates, bullet flight time calculations, etc. We live in a ready world, eh?

Then many clues suggesting that the game might not work this way appeared in a very short time. Miffyli came up with theright-hand side of the recoil decrease equation that turned out to be evaluated frame-by-frame. NoctyrneSAGA said that the game logic loop runs at a fixed 30 Hz. In line with Noctyrne’s comment, G-Sync’d video captures clearly showed that in one 33 ms frame an unknown time after ‘LMB down’, there is a muzzle flash, bullet in air, and no recoil. Systematically in the frame right after this, essentially all V recoil kicks in (you did look at the previous SCAR-H shot frame-by-frame image didn't you...). And really by far most importantly, Miffyli put together a tool for reading game variables directly from BF4 memory, which gave us a chance to get conclusive insight into in-game mechanics and how they relate to ‘LMB down’.

It's not that tl;dr, read on

A note on Methods

I ran Miffyli's memory probe with a wait time of 1 ms, which yielded samples at (known) 1-2 ms intervals. BF4 was run in Windowed mode, all graphics at 'low', at 59.95 Hz with FPS and screen refresh capped to 60 Hz. I struggled for days to identify the source of non-random jitters (and results not predicted by theory) in my recordings. It turned out that the game-logic loop does not run at 30 Hz but rather at 59.95/2 Hz and that the logic loop frames are affected by monitor refresh, which makes 85 Hz FPS fucking bad for this kind of stuff.

Have a look at in-game timings of 'LMB down' and V recoil-up-transients, and remember that before recoil-up, the preceding 33 ms constitute the frame where the shot is fired.

Here 11 mag-dumps were shot with naked SCAR-H and the V recoils (spikes) are visualized with LMB down states (red bar) so that the onset of the first-shot V recoil is at 0 ms and hence the first muzzle-flash/bullet-out frame is at ~-33 ms. There bursts are offset by multiples of 0.5 so that they all can be seen. You can easily see that there is always around 1-32 ms, i.e., less than one frame between LMB down and first-bullet out. This is what I have systematically seen also in other recordings so I think we can safely conclude that if the gun is ready to fire, the shot is out in the frame following LMB down, i.e. with an unpredictable < 33 ms lag.

However, what is really conspicuous in the recoil time series is that every burst follows the same temporal pattern and the bullet output does not correspond to 60/RoF of SCAR-H. So, bullet output is discretized into the game frames and occurs in the same sequence of frames in every burst.

Have a look at how the same looks like for AEK-971:

and for FAMAS (explains why dat FAMAS is loved by some, doesn't it... :whistling:

)

Summa summarum
Hence, all shooting timings are discretized into frames of 33 ms. There is really nothing spectacular in this, games need syncing and computers take finite times for doing things, BUT as you can see, there are some damn serious and interesting implications for our beloved RoFs, TTKs, and DPSs.

Implications in the next post:

"Less is more? How can that be? How could less be more, that's impossible. More is more." Yngwie Malmsten
"Many bullets help." WoopsyYaya
"most rhetorically legitimate ad hominem 2015" ToTheSun!

This post has been edited 1 times, last edit by "3VerstsNorth" (Oct 20th 2014, 12:46am)

3VerstsNorth

Skynet T100

(3,187)

Posts: 1,614

Date of registration
: Apr 12th 2013

Platform: PC

Location: Guilin Peaks, Finland

Battlelog:

Reputation modifier: 14

2

Sunday, October 19th 2014, 10:36pm

The implications of discretized shooting?

Let's make an assumption that the bullet-out frame is always the one wherein the RoF would predict the shot to be fired. So, for example, if the game logic loop frame times (in seconds) are:

	Source code
1 2 3 4 5	0-0.033 0.033-0.067 0.067-0.100 0.100-0.133 0.133-0.167

and the RoF-predicted bullet-out times for the first three shots of ACE 23:

	Source code
1 2 3	0 0.078 0.156

then this model would predict the shots to be fired in frames 1, 3, and 5.

This turns out to be quite in line with in-game recordings with ACE 23 (RoF = 770 Hz):

Here the spikes are the recorded V recoils as in the previous post. The green and black squares above are the bullet-out and no-bullet, respectively, frames predicted by the model.

Picking a few example RoFs, this turns out to works in the same way for SCAR-H (620 Hz):

A-91 (800 Hz):

AEK-971 (900 Hz):

and finally, FAMAS (1000 Hz):

So, the model seems to hold. Below is a list of all possible RoFs in the game (for automatics) and the corresponding bullet-out frame sequences:

The table shows for example that 600 rpm guns spit out the first 2 bullets exactly as fast as the 900 rpm AEK. Likewise, for the first 3 bullets, M416 is as fast as AEK. Finally, up to 5 first shots, A-91 or MG4 at 800 rpm are identical to 900 rpm guns. The implication of this, of course, is that we need to re-adjust our ideas of how the RoF stat plays out in-game. These timings can be exploited for optimal bursting, but remembering that the time it takes for the gun to be able to shoot again is still dependent on RoF - in a way I have not figured out yet. Another implication is, obviously, that all analyses of effective TTKs and optimal mouse tapping rates for bursting need a complete revision, d'oh.

Disclaimer: this table is accurate for BF4 running at 60 Hz (and probably at 120 Hz as well). There are minor frame shifts for FPS = 85 Hz (and probably for 140 Hz as well) as there appears to be an interaction between the game logic loop (~30 Hz) and output FPS choice. I'm trying to check these out for the last post, but I'll need a couple of days minimum for that.

So, what do you think? All feedback is welcome.

"Less is more? How can that be? How could less be more, that's impossible. More is more." Yngwie Malmsten
"Many bullets help." WoopsyYaya
"most rhetorically legitimate ad hominem 2015" ToTheSun!

This post has been edited 2 times, last edit by "3VerstsNorth" (Oct 20th 2014, 12:53am) with the following reason: not reserved anymore :)

3VerstsNorth

Skynet T100

(3,187)

Posts: 1,614

Date of registration
: Apr 12th 2013

Platform: PC

Location: Guilin Peaks, Finland

Battlelog:

Reputation modifier: 14

3

Sunday, October 19th 2014, 10:36pm

First of all, I think all recordings I have seen, and those shown later in this post (look at the relationship of red crosses in figures and the large V recoil spikes), support this shooting onset/offset rule:

A bullet is always fired at frame “i" when ‘LMB down’ is detected in any part of the frame “i-1” if the gun is capable of firing at frame "i". If this condition is not met, automatic shooting is terminated.

Here the earliest frame at which the shot can go out is specifically defined by the bullet-out “frames” seen in the frame sequences (see post above). Note also that the sequence always starts from the beginning at the onset of a new burst IF there is no conflict with the previous sequence (too early shots), so no ‘cheating’ possible. I don’t know how this is implemented and whether it is intentional in the first place, but this is what the data show.

So, I did recordings with different kinds of bursting patterns. Let’s look at SCAR-H first and remember that the frame sequence for SCAR-H is x-o-x-o-o-x-o-o-x-o-o-… so that the first two bullets are fired with an interval of only 66 ms.

In the plot below, red crosses indicate 1-2 ms samples where ‘LMB down’ = TRUE, blue lines show the V recoil transients, and green lines the total amount of spread. For V recoil, large upward spikes are the first shots, small ones the subsequent shots, and the negative spikes reflect recoil (under)compensation that I did to not hit the recoil ceiling. Vertical gridlines are spaced one frame apart.

The lowest row shows optimal 2-shot bursting: when the gun would be ready to fire three frames after the second shot, one empty frame resets the spread, and a new quick (66 ms interval) pair of bullets can be sent out.

The middle row shows the two classes of derps that can happen at intended steady 2-shot bursting: 1. If the LMB down comes too close to the previous, a new first-shot is triggered (see large V recoil) but without the spread reset and without the 66 ms interval (see the IF condition above!). 2. An LMB down coming too late introduces extra frames and slows down the effective RoF – no news here.

The top row shows an example of 3-shot bursting and the 3rd class of derp: a failure to hold LMB down long enough will terminate the burst prematurely, which will then mess up recoil compensation etc.

Interim Conclusion

All in all, this preliminary analysis shows that 600-650 rpm guns (x-o-x-o-o-x-o-o-x-o-o-… pattern) can be two-shot bursted at min spread by using a x-o-x-o-o-*-x-o-x-o-o- pattern with so that essentially the only cost to output RoF is the shift of each the third shot by the frame (*) used to reset spread. Ofc the extra FSM might not be desirable, but that’s another issue.

...more later, gotta run nao...

"Less is more? How can that be? How could less be more, that's impossible. More is more." Yngwie Malmsten
"Many bullets help." WoopsyYaya
"most rhetorically legitimate ad hominem 2015" ToTheSun!

This post has been edited 4 times, last edit by "3VerstsNorth" (Oct 21st 2014, 3:29pm) with the following reason: Data!

VincentNZ

Holy War? No Thanks.

(2,368)

Posts: 2,791

Date of registration
: Jul 25th 2013

Platform: PC

Battlelog:

Reputation modifier: 16

4

Sunday, October 19th 2014, 11:23pm

Yeah that the recoil seemed to hit after the second bullet was my assumption from the start and in BF3 as well. At least for the FAMAS. I thought they were supposed to fix that though?

So does this mean that some ROFs are more suited for the ingame mechanics than others, as a conclusion?

3VerstsNorth

Skynet T100

(3,187)

Posts: 1,614

Date of registration
: Apr 12th 2013

Platform: PC

Location: Guilin Peaks, Finland

Battlelog:

Reputation modifier: 14

5

Monday, October 20th 2014, 12:45am

Quoted from "VincentNZ"

Yeah that the recoil seemed to hit after the second bullet was my assumption from the start and in BF3 as well. At least for the FAMAS. I thought they were supposed to fix that though?

So does this mean that some ROFs are more suited for the ingame mechanics than others, as a conclusion?

Re conclusion, yeah, that's pretty much it. Recoil with awkward frame timing is perhaps more difficult to compensate than that with smooth timing. And "what is worth and what not" with respect to the trade-off between increasing RoF and decreasing accuracy/ease-of-use really has to be considered in the light of the in-game bullet timings.

Re FAMAS, I don't know if the second bullet is shot before or after the application of first-shot V recoil to the aimpoint (both happen in the same frame). Outside of this, FAMAS works as it should

...alternating between 2 shots fired at 1800 rpm and then 3-4 shots at 900 rpm.

"Less is more? How can that be? How could less be more, that's impossible. More is more." Yngwie Malmsten
"Many bullets help." WoopsyYaya
"most rhetorically legitimate ad hominem 2015" ToTheSun!

NoctyrneSAGA

PvF 2017 Champion

(10,252)

Posts: 7,275

Date of registration
: Apr 3rd 2012

Platform: PC

Battlelog:

Reputation modifier: 19

6

Monday, October 20th 2014, 1:06am

Quoted from "3VerstsNorth"

The table shows for example that 600 rpm guns spit out the first 2 bullets exactly as fast as the 900 rpm AEK.

Cognitive Dissonance abound.

I find this hard to accept, but would be really pleased if it was true.

QBZ-95-1 double tap would be king would it not?

Data Browser

Passive Spotting is the future!

"Skill" may indeed be the most magical of words. Chant it well enough and any desire can be yours.

Are you a scrub?

Quoted from "blahdy"

If it flies, it dies™.

3VerstsNorth

Skynet T100

(3,187)

Posts: 1,614

Date of registration
: Apr 12th 2013

Platform: PC

Location: Guilin Peaks, Finland

Battlelog:

Reputation modifier: 14

7

Monday, October 20th 2014, 1:26am

Quoted from "NoctyrneSAGA"

Quoted from "3VerstsNorth"

The table shows for example that 600 rpm guns spit out the first 2 bullets exactly as fast as the 900 rpm AEK.

Cognitive Dissonance abound.

I find this hard to accept, but would be really pleased if it was true.

QBZ-95-1 double tap would be king would it not?

SAR-21, 600 rpm, tadaa:

...this stuff is incredibly sensitive to getting the FPS and various variable value rounding aspects right. At 600 rpm, the second shot is out exactly at 100 ms, but if the logic-thread (whatever it actually is) runs at 29.975 Hz, the third frame ends at 100.083 ms and hence the shot is fired there and not in the fourth frame as one would expect. And this is what the recordings show, but that said, we need to figure out what happens at other FPS rates.

EDIT, I tested SAR with BF4 and the monitor running at 120 Hz. The results were identical to previous ones and suggest that the logic-thread indeed runs at <30 Hz (probably 29.975 Hz). Check this out:

"Less is more? How can that be? How could less be more, that's impossible. More is more." Yngwie Malmsten
"Many bullets help." WoopsyYaya
"most rhetorically legitimate ad hominem 2015" ToTheSun!

This post has been edited 1 times, last edit by "3VerstsNorth" (Oct 20th 2014, 1:38am)

Rezal

Rezmer

(10,391)

Posts: 4,259

Date of registration
: Apr 6th 2012

Platform: PC

Location: From the heart of Europe.

Battlelog:

Reputation modifier: 17

8

Monday, October 20th 2014, 2:12am

Are you using HPET?
For CMD:
bcdedit /set useplatformclock true (use HPET)
bcdedit /deletevalue useplatformclock (no longer use HPET, default)

[Aristocrat's Shoes]

Quoted from "Darktan13"

TLDR -
Teamwork is where players function by themselves, but their effectiveness is multiplied when they work together. Not a checklist of "did we bring a healer so we can start playing?"

Miffyli

Symthic Developer

(6,841)

Posts: 3,735

Date of registration
: Mar 21st 2013

Platform: PC

Location: __main__, Finland

Reputation modifier: 17

9

Monday, October 20th 2014, 6:43am

Quoted from "Rezal"

Are you using HPET?
For CMD:
bcdedit /set useplatformclock true (use HPET)
bcdedit /deletevalue useplatformclock (no longer use HPET, default)

I used clock() which's resolution on windows is "better than one microsecond" according to Python. Should be enough as we're dealing with game frames which have quite a bit of delay between frames relatively speaking.

Links to users' thread list who have made analytical/statistical/mathematical/cool posts on Symthic:

3VerstsNorth - Analysis of game mechanics in BF4 (tickrates, effects of tickrate, etc)
InterimAegis - Weapon comparisons/scoring.
leptis - Analysis of shotguns, recoil, recoil control and air drag.
Veritable - Scoring of BF4/BF1 firearms in terms of usability, firing and other mechanics.
pmax - Statistical analysis of BF4 players/games.
Miffyli - Random statistical analysis of BF4 battlereports/players and kill-distances. (list is cluttered with other threads).

Sorry if your name wasn't on the list, I honestly can't recall all names : ( . Nudge me if you want to be included

JSLICE20

(2,444)

Posts: 3,292

Date of registration
: Apr 26th 2013

Platform: PS4

Location: Arizona, USA

Reputation modifier: 15

10

Monday, October 20th 2014, 7:06am

I knew rate of fire wasn't as important as others made it out to be! This is pure gold! Does this mean low rate of fire weapons have a sizable chance against high rate of fire weapons if the user is super accurate?

Haha, an analysis of this magnitude leads me to believe a DICE employee will see what you (and all those involved) have discovered and make it their mission that this information does not leak to the public. That they'll recruit hackers, computer gurus, or even some from our staff to suppress or even eliminate this thread and all its contents.

To Aim Assist or not to Aim Assist, that is the question.

Nope. Aim Assist or bust; here's why:

Default Aim Assist Data

Source code

AccelerationInputThreshold 0.98
    AccelerationMultiplier 5.0
    AccelerationDamping 4.0
    AccelerationTimeThreshold 0.15
    SquaredAcceleration 0.0
    MaxAcceleration::Vec2
        x 2.0
        y 2.0
    YawSpeedStrength 1.0
    PitchSpeedStrength 1.0
    AttractDistanceFallOffs::Vec2
        x 1.0
        y 1.2
    AttractSoftZone 0.75
    AttractUserInputMultiplier 0.45
    AttractUserInputMultiplier_NoZoom 0.5
    AttractOwnSpeedInfluence 0.0
    AttractTargetSpeedInfluence 0.85
    AttractOwnRequiredMovementForMaximumAttract 0.0
    AttractStartInputThreshold 0.1
    AttractMoveInputCap 0.0
    AttractYawStrength 1.0
    AttractPitchStrength 0.34
    MaxToTargetAngle 45.0
    MaxToTargetXZAngle 45.0
    ViewObstructedKeepTime 0.0
    SnapZoomLateralSpeedLimit 1000.0
    SnapZoomTime 0.2
    SnapZoomPostTimeNoInput 0.2
    SnapZoomPostTime 0.2
    SnapZoomReticlePointPriority 999
    SnapZoomAutoEngageTime 0.0
    SnapZoomBreakTimeAtMaxInput 0.2
    SnapZoomBreakMaxInput 0.2
    SnapZoomBreakMinAngle 90.0
    SnapZoomSpamGuardTime 1.2
    SoldierBackupSkeletonCollisionData *nullGuid*
    CheckBoneCenterOnlyDistance 40.0

No Slowdown Data

Source code

AccelerationInputThreshold 0.98
    AccelerationMultiplier 5.0
    AccelerationDamping 4.0
    AccelerationTimeThreshold 0.15
    SquaredAcceleration 0.0
    MaxAcceleration::Vec2
        x 2.0
        y 2.0
    YawSpeedStrength 1.0
    PitchSpeedStrength 1.0
    AttractDistanceFallOffs::Vec2
        x 1.0
        y 1.2
    AttractSoftZone 0.0
    AttractUserInputMultiplier 1.0
    AttractUserInputMultiplier_NoZoom -1.0
    AttractOwnSpeedInfluence 0.0
    AttractTargetSpeedInfluence 0.0
    AttractOwnRequiredMovementForMaximumAttract 0.0
    AttractStartInputThreshold 0.0
    AttractMoveInputCap 0.0
    AttractYawStrength 0.0
    AttractPitchStrength 0.0
    MaxToTargetAngle 45.0
    MaxToTargetXZAngle 45.0
    ViewObstructedKeepTime 0.0
    SnapZoomLateralSpeedLimit 1000.0
    SnapZoomTime 0.2
    SnapZoomPostTimeNoInput 0.0
    SnapZoomPostTime 0.0
    SnapZoomReticlePointPriority 999
    SnapZoomAutoEngageTime 0.0
    SnapZoomBreakTimeAtMaxInput -1.0
    SnapZoomBreakMaxInput 0.2
    SnapZoomBreakMinAngle 90.0
    SnapZoomSpamGuardTime 0.5
    SoldierBackupSkeletonCollisionData *nullGuid*
    CheckBoneCenterOnlyDistance 40.0
    DisableForcedTargetRecalcDistance 7.0

No Auto Rotation Data

Source code

 AccelerationInputThreshold 0.98
    AccelerationMultiplier 5.0
    AccelerationDamping 4.0
    AccelerationTimeThreshold 0.15
    SquaredAcceleration 0.0
    MaxAcceleration::Vec2
        x 2.0
        y 2.0
    YawSpeedStrength 1.0
    PitchSpeedStrength 1.0
    AttractDistanceFallOffs::Vec2
        x 1.0
        y 1.2
    AttractSoftZone 0.75
    AttractUserInputMultiplier 0.45
    AttractUserInputMultiplier_NoZoom 0.5
    AttractOwnSpeedInfluence 0.0
    AttractTargetSpeedInfluence 0.85
    AttractOwnRequiredMovementForMaximumAttract 0.0
    AttractStartInputThreshold 0.1
    AttractMoveInputCap 0.0
    AttractYawStrength 1.0
    AttractPitchStrength 0.34
    MaxToTargetAngle 45.0
    MaxToTargetXZAngle 45.0
    ViewObstructedKeepTime 0.0
    SnapZoomLateralSpeedLimit 1000.0
    SnapZoomTime 0.2
    SnapZoomPostTimeNoInput 0.0
    SnapZoomPostTime 0.0
    SnapZoomReticlePointPriority 999
    SnapZoomAutoEngageTime 0.0
    SnapZoomBreakTimeAtMaxInput -1.0
    SnapZoomBreakMaxInput 0.2
    SnapZoomBreakMinAngle 90.0
    SnapZoomSpamGuardTime 0.5
    SoldierBackupSkeletonCollisionData *nullGuid*
    CheckBoneCenterOnlyDistance 40.0
    DisableForcedTargetRecalcDistance 7.0

Prepare your laughbox

Quoted from "Zer0Cod3x"

the Sebstalder is quiet good since it can 3hit kill at any distanc ,but In my opinion i actually thikn the sweeper is better, its got a really really fast firerate that can beat alll those Noobmaticos, Helregall adn shitguns in close quarters , and its also really accurate out to like l;ong range,. overall great allround gun, jsut my 2$ tho

My "Contributions"

Gun Sway Modifiers (Hidden Attachments in Variants)
Gadget, Stationary, and Vehicle Weaponry Stats (Pre-Official)