[2.0.55] Usable items cooldowns depend on latency in multiplayer
Posted: Sun Jun 29, 2025 4:33 pm
Hello there,
While playing a competitive scenario called Biter Battles, we noticed that grenades and all other usable items (that is capsule prototypes) cooldowns are not consistent in multiplayer and depends on the user's latency. Moreover if the expected cooldown is less than the latency then the observed cooldown is expected cooldown + latency. If the expected cooldown is greater than the latency then the observed cooldown will alternate between the expected cooldown and the latency.
For instance, if one throws grenades (which have a cooldown of 30 ticks) with a latency of 16 ticks, they will actually throw one every 30 + 16 = 46 ticks. And if one does the same with a latency of 35 ticks, the second grenade will be thrown 35 ticks after the first one, the third 30 ticks after, the fourth 35 ticks, the fifth 30 ticks...
This means that if one has 29 ticks of latency their grenade DPS, their destroyer bot spawning rate or even their fish healing speed are almost half of what they should be!
Additionally, I'm almost sure that the behaviour changes again when the latency is greater than twice the expected cooldown, but since it is hard to get someone that high in latency, I'm not sure what that behaviour actually is.
We have also tried with other stuff that has a cooldown, such as weapons, but we did not observe this buggy behaviour.
Here is a video demonstrating the bug:
https://youtu.be/lp6IaxHrUD0
The following command was used to print in chat the time since the last grenade throw:
We can see that the server host does throw a grenade every 30 ticks, but the other player who has 17 ticks throws one every 47 ticks. Meaning his DPS is 1.5x lower that the host's.
Here is another video that uses the same command and demonstrate the second behaviour. In this video the player also goes under 30 ticks of latency at the end, which makes the behaviour change abruptly.
https://youtu.be/eE6JALrgEa0
The attached log file is from the game session during which I recorded those videos. It contains a lot of trash since I also played a scenario that logs a lot of stuff, the section where we did the testing is from 9538.353s to 14664s.
While playing a competitive scenario called Biter Battles, we noticed that grenades and all other usable items (that is capsule prototypes) cooldowns are not consistent in multiplayer and depends on the user's latency. Moreover if the expected cooldown is less than the latency then the observed cooldown is expected cooldown + latency. If the expected cooldown is greater than the latency then the observed cooldown will alternate between the expected cooldown and the latency.
For instance, if one throws grenades (which have a cooldown of 30 ticks) with a latency of 16 ticks, they will actually throw one every 30 + 16 = 46 ticks. And if one does the same with a latency of 35 ticks, the second grenade will be thrown 35 ticks after the first one, the third 30 ticks after, the fourth 35 ticks, the fifth 30 ticks...
This means that if one has 29 ticks of latency their grenade DPS, their destroyer bot spawning rate or even their fish healing speed are almost half of what they should be!
Additionally, I'm almost sure that the behaviour changes again when the latency is greater than twice the expected cooldown, but since it is hard to get someone that high in latency, I'm not sure what that behaviour actually is.
We have also tried with other stuff that has a cooldown, such as weapons, but we did not observe this buggy behaviour.
Here is a video demonstrating the bug:
https://youtu.be/lp6IaxHrUD0
The following command was used to print in chat the time since the last grenade throw:
Code: Select all
/c script.on_event(defines.events.on_player_used_capsule, function(e) if not storage.last then storage.last = 0 end game.print(game.get_player(e.player_index).name .. " " .. e.tick - storage.last, {skip=defines.print_skip.never}) storage.last = e.tick end)
Here is another video that uses the same command and demonstrate the second behaviour. In this video the player also goes under 30 ticks of latency at the end, which makes the behaviour change abruptly.
https://youtu.be/eE6JALrgEa0
The attached log file is from the game session during which I recorded those videos. It contains a lot of trash since I also played a scenario that logs a lot of stuff, the section where we did the testing is from 9538.353s to 14664s.