- Staff
- #1
Hello,
As some of you may remember, I made a detailed post in May when we experimented with changing tick rates on the server.
As a result of this post, we made a change to the fire rate, resulting many weapons being moved closer to their true fire rate. This can be seen in the below chart, where the Famas was changed considerably for a server running at 20 tick.
Later in the summer, the 33 tick rate was causing issues on the server, we made the decision to change the server back to a 20 tick rate. However, it became apparent that were some other differences between the tick rates that we had not uncovered. In particular, there were some guns that had different recoils depending on the tick rate.
This was confusing for a while, as there was no difference in the actual code, and nothing that was tick dependent. After some investigation, We found the troublesome function: ViewPunch. This function is what gives players a temporary kick back after firing a bullet, but had some different behaviour depending on tick rates. When I ran the view punch code individually on two different servers, I found that the recoil took longer to reset on a lower tick rate server. This was a mild problem for a single bullet, but causes massive issues when using the automatic firemode. This can be seen in the below chart:
While the problem was now apparent, the solution was not. ViewPunch is source engine function that we have no real control over. We considered a few options that could be investigated to resolve this issue:
Within the view punch decay code there are the following lines:
The mathematical issue was not obvious at first, but once I started typing up the formula into a spreadsheet I realised that the spring force was being clamped to 2 for all servers with a tick rate below 33. (This is because 65 * (1/20) = 3.25, which then gets clamped). When we plot how single line changes the view punch angle by tick rate, we can see it has a considerable impact:
Now we had a good idea of the root problem, I decided to try an experiment of manually adding the velocity spring force that had been clamped out of the original equation. To my genuine surprise, this worked without much hassle. I used an M4A1 with a muzzle brake and an M16 stock to produce the comparison below:
Just like the change I made as a result of my previous thread, the amount of new could is fairly small, but the time it took to determine what the code should be took an painfully long amount of time. The update will be pushed onto the server in the next patch (which may not be tomorrow).
I hope you enjoyed my post, and I'm happy to answer any question that you may have.
tl;dr
As some of you may remember, I made a detailed post in May when we experimented with changing tick rates on the server.
As a result of this post, we made a change to the fire rate, resulting many weapons being moved closer to their true fire rate. This can be seen in the below chart, where the Famas was changed considerably for a server running at 20 tick.
Later in the summer, the 33 tick rate was causing issues on the server, we made the decision to change the server back to a 20 tick rate. However, it became apparent that were some other differences between the tick rates that we had not uncovered. In particular, there were some guns that had different recoils depending on the tick rate.
This was confusing for a while, as there was no difference in the actual code, and nothing that was tick dependent. After some investigation, We found the troublesome function: ViewPunch. This function is what gives players a temporary kick back after firing a bullet, but had some different behaviour depending on tick rates. When I ran the view punch code individually on two different servers, I found that the recoil took longer to reset on a lower tick rate server. This was a mild problem for a single bullet, but causes massive issues when using the automatic firemode. This can be seen in the below chart:
While the problem was now apparent, the solution was not. ViewPunch is source engine function that we have no real control over. We considered a few options that could be investigated to resolve this issue:
- Write our own view punch method
- Increase the tick rate of the server again
- Scrap the entire recoil system and replace it with something more akin to Rainbow Six Siege or Counter-Strike: Global Offensive
- Override the view punch calculations with our own code
Within the view punch decay code there are the following lines:
C++:
#define PUNCH_SPRING_CONSTANT 65.0f // bigger number increases the speed at which the view corrects
...
float springForceMagnitude = PUNCH_SPRING_CONSTANT * gpGlobals->frametime;
springForceMagnitude = clamp(springForceMagnitude, 0.f, 2.f );
player->m_Local.m_vecPunchAngleVel -= player->m_Local.m_vecPunchAngle * springForceMagnitude;The mathematical issue was not obvious at first, but once I started typing up the formula into a spreadsheet I realised that the spring force was being clamped to 2 for all servers with a tick rate below 33. (This is because 65 * (1/20) = 3.25, which then gets clamped). When we plot how single line changes the view punch angle by tick rate, we can see it has a considerable impact:
Now we had a good idea of the root problem, I decided to try an experiment of manually adding the velocity spring force that had been clamped out of the original equation. To my genuine surprise, this worked without much hassle. I used an M4A1 with a muzzle brake and an M16 stock to produce the comparison below:
Just like the change I made as a result of my previous thread, the amount of new could is fairly small, but the time it took to determine what the code should be took an painfully long amount of time. The update will be pushed onto the server in the next patch (which may not be tomorrow).
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 all guns have worse recoil, this impacted some guns more than others
- It was Valve's fault all long, but I stumbled on a hacky fix
- Go buy a L85A2
