1.8

An issue in vanilla and modded.

Mods I run currently:

05983673D5D0AED4

65AD7C379CBD394D

65AD7BCC9F6B3B4E

65AD7CF69FAF1FDD

65AD7D0D9941A380

65AD7D1E9EEAFA53

68EAA4B96976D557

65AD7D2E9866FA6E

65AD7D4099944EBD

6586079789278413

65B343F799FB521B

65AD7C75826B46C6

65AD7CB89F219E38

65AD7CD09CAEC4E2

65AD7CE59E8DB349

667B230F9505C8BA

62CCD69DD17E4F2F

662EB83AB3F8CAE3

5C721177A220B42F

5D1880C4AD410C14

63120AE07E6C0966

61B84088181A8FA4

64900A5A31F5DCB5

1337C0DE5DABBEEF

BADC0DEDABBEDA5E

595F2BF2F44836FB

5E389BB9F58B79A6

59EAA899751805DF

61ECB5EFAA346151

6122DD5CCF5C59E6

64CB39E57377C861

6303360DA719E832

6326F0C7E748AB8A

6273146ADFE8241D

62AE96D92179F7A0

629B2BA37EFFD577

61E42AE6714A3CC2

615CC2D870A39838

61C74A8B647617DA

6152CB0BD0684837

6602C1EC7E5A4A87

61A25BD1C99515B5

64610AFB74AA9842

612F512CD4CB21D5

6148289172F86E7A

6146FAED5AAD7C55

672D432E181E6807

614D1A3874A23AD9

6528B3CE24C85120

64CB35D07BAEE60F

6508EDDEF93B2B29

61D57616CAFBB23D

628933A0D3A0D700

6608EB45061AFC69

6503091A7B264FC3

615806DC6C57AF02

65F929DF622BAD50

615818DA7C0343FD

65DD60A16AE0FF73

62A668F513428630

648B595F6C72B4CB

631C3C1AEE9C90BC

614C00DA7F8765F6

66A513FA8DEEB7C0

685EDA5A6ACD53C5

61BA4EB5C886D396

615A80027C5C9170

69333B6C7C8BE8AB

68F006D910E7546F

65CF7AE8574E06D2

63294BA2D9F0339B

62F364B35E9B51B0

2220CE607EC47786

9F38A425547B929F

6073553B80F16EDE

B5D83690437A1206

DD2B83DD166DD4B9

BA11A9E5D0C74F32

6276E6E3CC97A22B

Weapon fire rate is quantised to the 30 Hz frame and the remainder is discarded,
so the engine delivers only 1800/n rates. Between 450 and 1800 rpm there are
exactly four: 1800, 900, 600, 450. A rifle configured at 800 rpm fires at 600.

Between 900 and 1800 rpm there is no rung at all, so every weapon configured
from 901 to 1799 delivers 900. The MP7's real 950 delivers 900. A 1200 rpm
submachine gun delivers 900.

The behaviour matches nextShot = now + interval snapped to the next frame, where
a correct implementation accumulates nextShot += interval.

Two further consequences:

1. Weapons configured exactly on a frame boundary have a framerate-dependent
rate. One configured at 928 rpm delivered 764 rpm with frames uncapped and
895 rpm with them capped at 120, nothing else changed. This half reproduces on a
clean vanilla install with any 900 or 600 rpm weapon.

2. The muzzle is capped at one round per frame, which is 1800 rpm. A 4000 rpm
minigun delivered 1796.

Measured over 1,290 shot events. 84 weapons audited across vanilla, RHS and a
large weapons mod.

Full write-up is in the attached PDF, BA-reforger-fire-rate-report.pdf.
It covers the mechanism, the distribution proof, scope, the four changes with
implementation code and the failure modes to avoid, why SalvoSize is not a
substitute, and the script API that would let mods work around this if none of
it is planned.

The fix, as four independent changes. The smallest useful one is a single
character.

A. nextShot += interval instead of =. Every rate below 1800 becomes exactly
deliverable and the framerate dependence disappears. This alone resolves the
defect for all 84 weapons that are not miniguns.
B. while instead of if. Adds the five vehicle weapons above 1800 rpm.
C. Evaluate the shot schedule faster than 30 Hz. This is about first-shot
latency, currently 16.7 ms average and 33 ms worst case.
D. Let the shot sound, the projectile spawn, the recoil curve and the muzzle
flash use the shot's intended time rather than the frame's. Under sustained
fire this is indistinguishable from full sub-frame scheduling, and nothing
has to run off-tick.

Recommended: A, B and D.

None of this is novel. Valve's weapon base class already does all three.
CBaseCombatWeapon::PrimaryAttack accumulates with +=, loops with while, and
passes the intended time into WeaponSound. Its comment gives the same reason
this report does: "To make the firing framerate independent, we may have to fire
more than one bullet here on low-framerate systems, especially if the weapon
we're firing has a really fast rate of fire."

Related: DayZ T161727 (November 2021), where the 30 Hz constraint was confirmed
on the record and closed with "we currently do not plan to change this
behaviour". This is not a re-filing. It adds the framerate dependence, the empty
900 to 1800 band, the turret cap, the measurements, and a specific set of asks.