Impacts of the new Tickrate on Firerate

Messages
2,984
Reaction score
4,526
Points
1,280
Location
United Kingdom
Hello,

As some of you may have noticed, we increased the server from a tick rate of 20 to a tickrate of 33 last night. This is important for many reasons, but the most important will be things such as improved hit registration. However, there are some side effects of this change, most noticeably how often firearms are allowed to shoot bullets.

The reasons for this are complicated, but it means that some guns will now fire at a slightly higher rate when using full auto, and some will fire at a slightly lower rate.

Here is a visualisation of how different guns have been impacted. The "True" position, is what happens if every gun fired at the exact moment that it was allowed to.
fbfe10e8eb.png
The "true" to achieve completely, without being able to use a tickrate that is much higher than the firerate of all of the weapons. If we had a tickrate nearing 1000, it would be closer, but there would still be a noticeable difference.

Warning - Everything below here will be complicated. Skip to the end if you don't care.

I'm going to try and summarise why things have changed, and outline how I think we might be able to improve things.

Firstly, some definitions:
  • Tickrate - The number of times a second the server runs all of the code to calculate what happens next.
  • Tickrate Delay - The number of seconds between each frame occuring = 1/Tickrate
    • The Tickrate Delay for a 33 tick server is 0.0303030303 seconds
    • The Tickrate Delay for a 20 tick server is 0.05 seconds
  • Frame - The single point in time where everything is calculated. The tickrate defines the number of server frames per second.
  • Think - An internal name for the code that defines what happens on a frame
  • RPM - Rounds Per Minute - How the weapon fire rates are calculated in PERP. A higher number means more bullets can be fired every second
  • Firerate Delay - The number of seconds between each round being fired = 60/RPM

There are some very long calculations to determine if a bullet is fired, but the algorithm essentially works like this. I've highlighted the two key areas that are key in bold.
  • A "Think" is called for a gun
  • Check to see if you can fire? If any are not true then stop.
    • Is the player holding left click? (or their +attack bind)
    • Is GetNextPrimaryFire() less than the current time?
    • Is the gun in the hands and ready to fire?
    • Does the gun have enough bullets to shoot?
  • Fire the weapon by
The important thing to note is that the calculation uses the current time of the frame that the bullet is fired. This is the easiest way of doing this, and is also the most inuitive. However, there is a flaw in this method, as when the firerate delay is anything other, than an exact multiple delay, the "true" value of when the bullet "should" have been fired, will always be different to when it was actually fired. This is because if the time when the bullet "should" have been fired is between two frames, it will not fire until the second one, which could be some time later.

An example of why this is a flaw is if a bullet is now allowed to be fired 0.00001 seconds after a frame has finished, it won't fire until the next frame cycles, which would be 0.03 seconds later on a 33 tick server, or 0.05 seconds later on a 20 tick server.

Changing to 33 ticks from 20 ticks means that the weapons that the gap has shifted. Some guns now fire more often on full auto, and some fire less often.
  • If a weapon can be fired every 0.04 seconds (1200 RPM), it would have fired on every frame with 20 ticks, as 0.04<0.05. However, with 33 ticks it will have some frames in between where it does not fire as 0.4>0.303. This means that the gun may now only fire every 0.06 seconds instead of 0.05 seconds.
  • If a weapon can be fired every 0.06 seconds (1000 RPM), it would have fired on every other with frame with 20 ticks as 0.06>0.05, meaning 0.1 second gaps. However, with 33 ticks, it still fires at every frame as 0.06<0.0606 (0.303*2=0.0606). This means the gun may now fire every 0.6 seconds instead of 0.1 seconds.
This is difficult to visualise, but I've attempted to demonstrate it below.
This image represents when an AK-47 should fire. The orange cells are approximately when the frames occur. The key area is in pink, showing the increased delay in the fire rate as the bullet should fire "just" after 4th frame is called on a 33 tick server. However, for a 22 tick server it was called earlier.
42f683de11.png
This image represents when an FAMAS should fire. The orange cells are approximately when the frames occur. The key area is in pink, showing the decreased delay in the fire rate as the bullet should fire just before the 3rd frame is called on a 33 tick server. However, for a 22 tick server it was called much later.
02f7a0e820.png

The FAMAS benefits the most from this, as the RPM is 1000, which is only just above 990, which is half of 33*60.

So, what do we do now?

There are basically 5 options:
  • Change the server back to 20 ticks
    • This will be bad for many things, but might be needed if the server can't handle 33 ticks anyway
  • Change all of the guns to have an RPM that it is a factor of 1980, so they all fire consistently at 33 ticks
    • This is not really a long term solution and would put the guns into bins
  • Change all of the guns to have an RPM that has an "equivalent" value of the 20 tick firerate
    • This does not achieve the goal of making the guns act as they were originally intended to act
  • Change the firerate delay calculation so that it depends on when the gun should have fired, rather than when it did fire
    • This might be very complicated, have unintended side effects, and I have no idea if it will work
  • Just leave it as it is an accept the new world order
Whichever option we go for in the end, several of them may need to be investigated to determine feasibility.

I hope you enjoyed my post, and I'm happy to answer any question that you may have.

tl;dr
  • Changing the tick rate made some guns fire slower and some guns fire faster
  • There are ways to change this, but they will require some development time and things may go wrong or not work at all
  • Go buy a famas
 
Last edited:
Messages
2,984
Reaction score
4,526
Points
1,280
Location
United Kingdom
  • Thread starter
  • Staff
  • #4
  • Change the firerate delay calculation so that it depends on when the gun should have fired, rather than when it did fire
    • This might be very complicated, have unintended side effects, and I have no idea if it will work

I've added a red line to show what the chart would like if we are able to successfully implement the above option.

d6552e10b0.png
 
Messages
8,975
Reaction score
11,335
Points
935
Location
REHAB
Tested the FAMAS on the academy server before a stage 3 for TFU today, idk if the new tickrates a thing on the academy but the famas feels garbage
 
Messages
2,984
Reaction score
4,526
Points
1,280
Location
United Kingdom
I've added a red line to show what the chart would like if we are able to successfully implement the above option.

d6552e10b0.png

I have implemented this code change in the latest update.

This will increase the firerate all of weapons in varying amounts. This will bring all of the rates of fire much closer to what was originally intended when they were the numbers were first coded many years ago. However, it does bring most of these rates to values which haven't been tested through hundreds of shoot outs.

Therefore, I would like to hear your opinions on all weapons over the coming days and weeks, to find out if any weapons have problematic rates of fire.
 
Messages
1,262
Reaction score
3,882
Points
825
nah just got a lot worse for me since i got higher ping. People closer to the german server can see the effect of the new tickrate
 
Messages
2,614
Reaction score
4,226
Points
845
So far most weapons feel pretty good but in very intensive areas, e.g a shootout or just an area with alot of players and cars i notice the server struggling to keep up sometimes, meaning the weapons feel a big laggy. Ive never seen rubberbanding on perp up until this update, and i'm fairly confident it is not a connection issue on my side.
 
Top