• SWEP SetNextPrimaryFire affected by server tickrate.
    7 replies, posted
So, when using SetNextPrimaryFire to control the fire rate of a SWEP I've noticed that the delay is affected by the servers tickrate, this was expected but I'm at a bit of a loss trying to find a good way to scale it so that the fire rate is somewhat consistent regardless of tickrate.
I would use a timer.Create Other than that I'm out of ideas
I'm aware of all this and making weapons. The issue I'm having is pretty universal and seems to affect most weapon packs. Because of how CurTime() is affected by the tickrate and timescale of the game it means that the delay becomes dependent on the tickrate of the server. As the tickrate gets lower it takes longer for CurTime() to progress to the point of which the SWEP can fire again. I've been toying around with modifying the added delay based on engine.TickInterval() but even then the delay added doesn't seem consistent with the decrease in server ticks.
It should really only be noticeable when the tickrate starts dipping below 22 or so - this is expected behaviour since the server will only simulate weapons/update CurTime the number of ticks you set per second. The recommended Source tickrate is 33 or above, and anything below will is not optimised internally.
Wouldn't it still be possible to find a decent value to adjust it by to attempt to mitigate this?
Well if your server has a 22 tickrate that means it will step forward every 0.045ms, so if your weapon fires at least 23 bullets per second or odd numbers, then you're going to have a bad time Imagine like using floats in HUDs, it will show ok but you will find some gaps on it after repeating few tiles
I'm not sure what "decent value" you mean - PrimaryAttack is checked every tick the mouse button is down.
If a gun shoots fast enough to be above the tickinterval, shoot multiple bullets at a lower frequency. This is what TF2's Heavy does.
Sorry, you need to Log In to post a reply to this thread.