Rate Limits
What the resource sets
On start, rm_dualgun raises the state bag flood limiter:
rateLimiter_stateBagFlood_rate 500 # default 150
rateLimiter_stateBagFlood_burst 750 # default 175rate
Sustained state bag updates a client may send per second
burst
Short spike allowed before the limiter starts dropping
Without this, a player aiming and firing continuously can exceed the default 150/s and be kicked with a state bag flood message.
SetConvar is process-wide. This raises the limit for your entire server, not just for rm_dualgun. That is a deliberate trade, since the limiter cannot be scoped to one resource, but you should know it applies globally.
Setting it yourself instead
If you would rather control the value centrally, put it in server.cfg:
set rateLimiter_stateBagFlood_rate 500
set rateLimiter_stateBagFlood_burst 750The resource writes the same values at start-up, so a matching server.cfg entry is harmless. If you set a higher value in server.cfg, the resource will lower it back to 500/750 when it starts, so set cfg values you are happy with, or raise them again after ensure rm_dualgun.
When to raise it further
The defaults shipped here are sized for normal play. Consider raising them if:
You run other resources that write state bags heavily (vehicle systems, large HUD frameworks, sync scripts) alongside this one.
You see state bag flood kicks in your logs while players are dual-wielding.
You have raised fire rates in
cfg.weaponswell below the stock 30 ms floor.
Reasonable next step:
Do not disable the limiter. It exists to stop a modified client flooding your server. Raise it to fit your workload, never remove it.
Other limiters worth knowing
State bags are not the only path FiveM rate-limits. If you see kicks that are not state bag related, these are the usual suspects:
netEventFlood
TriggerServerEvent calls from a client
msgReliable
Reliable network messages
entityCreation
How fast a client may create entities
rm_dualgun does not modify any of these. Its own server events are throttled internally so they stay well inside the defaults. See below.
Built-in throttles
Rather than relying on a raised limiter alone, the resource throttles its own traffic at the source. These are the ones worth knowing about because they have visible gameplay effects:
Ammo sync: once per 1.5 seconds
While firing, the client pushes its ammo count to the server at most once every 1500 ms, and forces a push immediately on reload and on unequip.
Effect: a hard server crash mid-burst can lose up to 1.5 seconds of spent rounds. This is deliberate: a dual minigun would otherwise send ~66 updates per second per player.
Aim sync: 20 Hz, with a movement threshold
The aim angle is sent at most 20 times per second, and only when it has actually moved by a meaningful amount. Holding still sends nothing.
Effect: none visible. Remote players see smooth aim tracking.
Equip cooldown: 2 seconds
A player may only request a new dual gun once every 2 seconds.
Effect: spamming an item shows a Slow down, try again in a moment notification instead of equipping.
Scaling notes
The heaviest cost is per dual-wielding player, not per player online. A 200-slot server with 5 active dual guns costs roughly the same as a 20-slot server with 5 active dual guns.
Two consequences:
Traffic scales with how popular the weapons are, not with your slot count. If you sell them cheaply and 40 people carry them, plan accordingly.
The fastest weapons dominate the cost. A dual minigun (
shot_interval = 30) produces roughly 20x the shot traffic of a dual pistol (shot_interval = 80) and 100x that of a launcher.
Diagnosing a flood kick
Confirm the kick message mentions state bag flooding. If it names events or entities, this page is not your problem.
Check whether the kicked players were dual-wielding at the time.
Confirm the convars actually took effect. Another resource starting later may have overwritten them:
If the value is not 500 (or higher), find what is resetting it and move your setting after that resource in
server.cfg.
Last updated