Upvote Upvoted 10 Downvote Downvoted
Current year net settings
posted in Customization
1
#1
0 Frags +

So I've been using the same net settings since like 2012 since back then these were regarded as "the best"

Projectile classes:

cl_updaterate 66
cl_cmdrate 66
cl_interp 0.0152
cl_interp_ratio 2

Hitscan classes:

cl_updaterate 66
cl_cmdrate 66
cl_interp 0.033
cl_interp_ratio 1

Over the years I've seen many different suggestions but no actual consensus on what would be the new "best" so I never bothered changing them. Every thread I've seen has some half baked theory being disputed by others without ever reaching a consensus, and people with actual expertise in the field (don't quote me on this but I think I've seen setsul/mastercoms/comanglia in different threads) just say "it depends".

My questions are, what does it depend on? Like, can I post a screenshot of my net graph or my speedtest/pingtest info and have someone tell me what the ideal net settings would be for me? Do they really need to differ for projectile and hitscan? Are my current ones outdated as fuck? Sometimes I feel like I have better hitreg on scout on 150 ping NA servers than I do on 30 ping european ones. Halp please

So I've been using the same net settings since like 2012 since back then these were regarded as "the best"

Projectile classes:

[code]cl_updaterate 66
cl_cmdrate 66
cl_interp 0.0152
cl_interp_ratio 2[/code]

Hitscan classes:

[code]cl_updaterate 66
cl_cmdrate 66
cl_interp 0.033
cl_interp_ratio 1[/code]

Over the years I've seen many different suggestions but no actual consensus on what would be the new "best" so I never bothered changing them. Every thread I've seen has some half baked theory being disputed by others without ever reaching a consensus, and people with actual expertise in the field (don't quote me on this but I think I've seen setsul/mastercoms/comanglia in different threads) just say "it depends".

My questions are, what does it depend on? Like, can I post a screenshot of my net graph or my speedtest/pingtest info and have someone tell me what the ideal net settings would be for me? Do they really need to differ for projectile and hitscan? Are my current ones outdated as fuck? Sometimes I feel like I have better hitreg on scout on 150 ping NA servers than I do on 30 ping european ones. Halp please
2
#2
1 Frags +

mastercomfig has something on his site to determain your best results based upon factors i believe.
check it out there

mastercomfig has something on his site to determain your best results based upon factors i believe.
check it out there
3
#3
14 Frags +

cl_interp 3.141592 for hitscan

sorry invite illuminati the people must know

cl_interp 3.141592 for hitscan

sorry invite illuminati the people must know
4
#4
28 Frags +

Well, first off, you have conflicting values of cl_interp and cl_interp_ratio. cl_interp and cl_interp_ratio are used to determine the client interp value, which is a single decimal value measured in seconds.

cl_interp_ratio sets the client interp value to be cl_interp_ratio divided by cl_updaterate, while cl_interp is a direct value for the client interp value. The client chooses the highest value among these two for the final client interp value.

You've seemed to flip the cl_interp_ratio value that is used conventionally for projectile and hitscan classes.

Now, let's talk about what interp actually is. Interpolation is an actual word, not just a Source Engine term. You may have also seen lerp in the net graph. This simply is short for linear interpolation, which is something you probably did in school when you calculated a line equation from the rise over run of two points. This is a way of determining a linear, continuous path from one discrete point to the next.

Now, in the real data that you recorded those points from, the actual continuous path might have been a zig zag, might have curved down, anything really. There's a large amount of realistic possibilities, but how large that amount is depends on the distance between the two points on some difference on an axis, let's call this delta x. For smaller and smaller delta x's, you can imagine approaching the point where the distance between the two points along that path is so small, where the delta x between the two points is practically zero and so the path could only really be a straight line (what we call dx).

For any delta x larger than that, there is a possible path error that could occur, and that possible error gets larger and larger as the delta x increases. So, when we do linear interpolation, we don't want to do it at a large delta x that would result in this kind of error. That will get us the best result.

Now, how does this stupid math stuff relate to Team Fortress 2? Well, the server runs its game logic every 0.015 seconds, and the results of the game running logic at those discrete steps get sent to your PC through the Internet at an interval of cl_updaterate times a second. So you're (theoretically) getting discrete points of data at a delta x of 0.0151515151 seconds if you have cl_updaterate set to 66.

The result would be players teleporting around from point to point at a refresh rate above 66Hz. So, interpolation needs to be done by the game so that these players smoothly travel along a linear path from point to point. But, people with even 60Hz monitors need interpolation at this amount, because the Internet isn't perfect. Sometimes packets are sent out of order, delayed, or dropped completely and the server can even slow down its own tick interval from 0.015 seconds to something higher that results in maybe even 40 packets a second instead of the commonly requested 66 due to high CPU load. In addition to interpolation being needed for rendering updates, interpolation also smooths out these irregularities in update intervals.

Let's expand on this imperfection in the Internet further. Interpolation requires two points to estimate the linear equation between two points, obviously. So, these delays where the effective update rate drops below 66 will change when you'll get these two points of data to do your interpolation. If you have your client interp set to 0.0151515151, and the next packet doesn't arrive in that time, then your game has no second data point to interpolate between the last one and this one. So instead, it has to entirely guess the second data point through a process known as extrapolation. Source uses linear extrapolation, where it takes the current velocity of the player and just assumes that the player continues with that velocity for the next required seconds. Since this can have a huge error, it's limited to 0.25 seconds of extrapolation, after which it just freezes movement.

Interpolation is obviously better than extrapolation, because of what we discussed previously about delta x's. These update intervals within TF2 are small enough, with velocities slow enough, for the linear approximation between two real data points to not have a large error. However, extrapolation is not going off of any real data of where the player is in the future for its prediction, so it will have a much larger error.

In order to avoid this issue, you need enough packets in your buffer queued up for interpolation so that the game can use a spare packet instead of guessing very inaccurately. This is why it's generally recommended nowadays to have your interp above 0.01515151, so that there is that extra packet if you need it at least some of the time. To guarantee a spare packet in the interpolation buffer all the time, you'll need your interpolation at 0.0303030303.

Now, a lot of people argue that interpolation adds a visual delay on where players are and that you need the lowest delay possible, ignoring any extrapolation risks. This is true for projectiles, but the visual delay is fully lag compensated for hitscan. This is why they recommend 0.01515151 interp for projectiles and the far safer 0.03030303 interp value for bullets.

However, I'd argue that the accuracy in current position that you get from a lower interp is far less valuable for projections than accuracy in trajectory, because predicting where people are GOING is going to be much more important than seeing a time accurate representation of where they exactly are right now. In addition to this, interpolation will always result in an accurate position history because its following what's happening on the server, albeit delayed, whereas extrapolation will be wrong in both trajectory and position.

So, I recommend a cl_interp of 0.030303 and a cl_interp_ratio of 2, if possible. However, I've also tuned a value based on what I've measured on normal packet jitter + drops on servers. This is cl_interp 0.0178571 and cl_interp_ratio 1.178571. Use whatever works for you.

Now there are other network settings as well. I recommend cl_updaterate 66 and cl_cmdrate 65. Why? This is because of client prediction. For your own player, the client will just simulate your actions locally using its own server code because that's probably what the result is going to be from the server anyway. However, there is a bug in this where if the two value are equal, client data is preferred over server data. So, I set the server update rate to the highest, and the client update rate to one lower to avoid this issue.

I also recommend different packet size/compression settings.

net_compresspackets 1;net_compresspackets_minsize 128;net_maxroutable 1200;net_maxfragments 1200

The net_maxroutable and net_maxfragments is based on Valve's updated metrics on good packet sizes in CS:GO and Dota 2. The compression settings are to revert a change by Valve made in TF2 many years ago which bumped up the compression threshold to reduce load on servers. For clients however, this value should be much lower since you're compressing much smaller client update packets and generally have less load than a server.

I also recommend cl_smooth 1 and cl_smoothtime 0.1 to reduce client view position jitter when you get juggled or pushed by being in front the payload cart.

Finally, probably the most important of the bunch is your rate settings. These were set in 2007 to 80,000 bytes per second, which was a reasonable value back then. However, since then, Internet speeds have gotten better and although CS:GO has updated its default rate to 196608, TF2 has stuck with that same old default rate.

So, I recommend rate 196608; net_splitpacket_maxrate 196608;net_maxcleartime 0.020346.

Well, first off, you have conflicting values of cl_interp and cl_interp_ratio. cl_interp and cl_interp_ratio are used to determine the client interp value, which is a single decimal value measured in seconds.

cl_interp_ratio sets the client interp value to be cl_interp_ratio divided by cl_updaterate, while cl_interp is a direct value for the client interp value. The client chooses the highest value among these two for the final client interp value.

You've seemed to flip the cl_interp_ratio value that is used conventionally for projectile and hitscan classes.

Now, let's talk about what interp actually is. Interpolation is [url=https://en.wikipedia.org/wiki/Interpolation] an actual word,[/url] not just a Source Engine term. You may have also seen lerp in the net graph. This simply is short for [url=https://en.wikipedia.org/wiki/Linear_interpolation]linear interpolation[/url], which is something you probably did in school when you calculated a line equation from the rise over run of two points. This is a way of determining a linear, continuous path from one discrete point to the next.

Now, in the real data that you recorded those points from, the actual continuous path might have been a zig zag, might have curved down, anything really. There's a large amount of realistic possibilities, but how large that amount is depends on the distance between the two points on some difference on an axis, let's call this delta x. For smaller and smaller delta x's, you can imagine approaching the point where the distance between the two points along that path is so small, where the delta x between the two points is practically zero and so the path could only really be a straight line (what we call dx).

For any delta x larger than that, there is a possible path error that could occur, and that possible error gets larger and larger as the delta x increases. So, when we do linear interpolation, we don't want to do it at a large delta x that would result in this kind of error. That will get us the best result.

Now, how does this stupid math stuff relate to Team Fortress 2? Well, the server runs its game logic every 0.015 seconds, and the results of the game running logic at those discrete steps get sent to your PC through the Internet at an interval of cl_updaterate times a second. So you're (theoretically) getting discrete points of data at a delta x of 0.0151515151 seconds if you have cl_updaterate set to 66.

The result would be players teleporting around from point to point at a refresh rate above 66Hz. So, interpolation needs to be done by the game so that these players smoothly travel along a linear path from point to point. But, people with even 60Hz monitors need interpolation at this amount, because the Internet isn't perfect. Sometimes packets are sent out of order, delayed, or dropped completely and the server can even slow down its own tick interval from 0.015 seconds to something higher that results in maybe even 40 packets a second instead of the commonly requested 66 due to high CPU load. In addition to interpolation being needed for rendering updates, interpolation also smooths out these irregularities in update intervals.

Let's expand on this imperfection in the Internet further. Interpolation requires two points to estimate the linear equation between two points, obviously. So, these delays where the effective update rate drops below 66 will change when you'll get these two points of data to do your interpolation. If you have your client interp set to 0.0151515151, and the next packet doesn't arrive in that time, then your game has no second data point to interpolate between the last one and this one. So instead, it has to entirely guess the second data point through a process known as [url=https://en.wikipedia.org/wiki/Extrapolation]extrapolation[/url]. Source uses linear extrapolation, where it takes the current velocity of the player and just assumes that the player continues with that velocity for the next required seconds. Since this can have a huge error, it's limited to 0.25 seconds of extrapolation, after which it just freezes movement.

Interpolation is obviously better than extrapolation, because of what we discussed previously about delta x's. These update intervals within TF2 are small enough, with velocities slow enough, for the linear approximation between two real data points to not have a large error. However, extrapolation is not going off of any real data of where the player is in the future for its prediction, so it will have a much larger error.

In order to avoid this issue, you need enough packets in your buffer queued up for interpolation so that the game can use a spare packet instead of guessing very inaccurately. This is why it's generally recommended nowadays to have your interp above 0.01515151, so that there is that extra packet if you need it at least some of the time. To guarantee a spare packet in the interpolation buffer all the time, you'll need your interpolation at 0.0303030303.

Now, a lot of people argue that interpolation adds a visual delay on where players are and that you need the lowest delay possible, ignoring any extrapolation risks. This is true for projectiles, but the visual delay is fully lag compensated for hitscan. This is why they recommend 0.01515151 interp for projectiles and the far safer 0.03030303 interp value for bullets.

However, I'd argue that the accuracy in current position that you get from a lower interp is far less valuable for projections than accuracy in trajectory, because predicting where people are GOING is going to be much more important than seeing a time accurate representation of where they exactly are right now. In addition to this, interpolation will always result in an accurate position history because its following what's happening on the server, albeit delayed, whereas extrapolation will be wrong in both trajectory and position.

So, I recommend a cl_interp of 0.030303 and a cl_interp_ratio of 2, if possible. However, I've also tuned a value based on what I've measured on normal packet jitter + drops on servers. This is cl_interp 0.0178571 and cl_interp_ratio 1.178571. Use whatever works for you.

Now there are other network settings as well. I recommend cl_updaterate 66 and cl_cmdrate 65. Why? This is because of client prediction. For your own player, the client will just simulate your actions locally using its own server code because that's probably what the result is going to be from the server anyway. However, there is a bug in this where if the two value are equal, client data is preferred over server data. So, I set the server update rate to the highest, and the client update rate to one lower to avoid this issue.

I also recommend different packet size/compression settings.
[code]net_compresspackets 1;net_compresspackets_minsize 128;net_maxroutable 1200;net_maxfragments 1200[/code]

The net_maxroutable and net_maxfragments is based on Valve's updated metrics on good packet sizes in CS:GO and Dota 2. The compression settings are to revert a change by Valve made in TF2 [url=http://www.teamfortress.com/post.php?id=10635]many years ago[/url] which bumped up the compression threshold to reduce load on servers. For clients however, this value should be much lower since you're compressing much smaller client update packets and generally have less load than a server.

I also recommend cl_smooth 1 and cl_smoothtime 0.1 to reduce client view position jitter when you get juggled or pushed by being in front the payload cart.

Finally, probably the most important of the bunch is your rate settings. These were set in 2007 to 80,000 bytes per second, which was a reasonable value back then. However, since then, Internet speeds have gotten better and although CS:GO has updated its default rate to 196608, TF2 has stuck with that same old default rate.

So, I recommend rate 196608; net_splitpacket_maxrate 196608;net_maxcleartime 0.020346.
5
#5
15 Frags +

You can also use my rate calculator and confirm the values with me to further adjust your rate settings according to your specific Internet connection speed. These values are used to determine the rate at which Source can send packets to and from your PC without overloading your connection. I use net_maxcleartime, which is basically a cap on the packet delay between sent packets that doesn't depend on packet size like rate. This means you can effectively get higher send rates for client packets if they are larger. This is what CS:GO refers to as "surge rate", and they've implemented this functionality on the server as well. Unfortunately, this trick only works client side on TF2.

You can also use [url=https://mastercomfig.com/rate]my rate calculator[/url] and confirm the values with me to further adjust your rate settings according to your specific Internet connection speed. These values are used to determine the rate at which Source can send packets to and from your PC without overloading your connection. I use net_maxcleartime, which is basically a cap on the packet delay between sent packets that doesn't depend on packet size like rate. This means you can effectively get higher send rates for client packets if they are larger. This is what CS:GO refers to as "surge rate", and they've implemented this functionality on the server as well. Unfortunately, this trick only works client side on TF2.
6
#6
12 Frags +

Honestly, you and people like you are the reason this game has survived for so long. Putting in so much effort in passion projects with no financial gain and typing up essays just because some dude asked a question on a forum. I greatly appreciate the lengthy and in-depth reply and I'll try out your values tomorrow <3

Show Content
P.S. my slightly customized mastercomfig 4.2.7 gets me about 12% more fps than the current very low config that you have up on your site (version 6 I believe), if you want to see it tell me

EDIT: nvm, just saw that you're no longer working on it
Honestly, you and people like you are the reason this game has survived for so long. Putting in so much effort in passion projects with no financial gain and typing up essays just because some dude asked a question on a forum. I greatly appreciate the lengthy and in-depth reply and I'll try out your values tomorrow <3

[spoiler]P.S. my slightly customized mastercomfig 4.2.7 gets me about 12% more fps than the current very low config that you have up on your site (version 6 I believe), if you want to see it tell me

EDIT: nvm, just saw that you're no longer working on it[/spoiler]
7
#7
8 Frags +
SylentHonestly, you and people like you are the reason this game has survived for so long. Putting in so much effort in passion projects with no financial gain and typing up essays just because some dude asked a question on a forum. I greatly appreciate the lengthy and in-depth reply and I'll try out your values tomorrow <3
Show Content
P.S. my slightly customized mastercomfig 4.2.7 gets me about 12% more fps than the current very low config that you have up on your site (version 6 I believe), if you want to see it tell me

EDIT: nvm, just saw that you're no longer working on it

thankss <3. i honestly could have gone more in depth on the other stuff but I'm glad you liked it!!

and I would be glad to hear about it. I'm no longer working on mastercomfig, but that doesn't mean I'm stopping work on TF2 configs.

[quote=Sylent]Honestly, you and people like you are the reason this game has survived for so long. Putting in so much effort in passion projects with no financial gain and typing up essays just because some dude asked a question on a forum. I greatly appreciate the lengthy and in-depth reply and I'll try out your values tomorrow <3

[spoiler]P.S. my slightly customized mastercomfig 4.2.7 gets me about 12% more fps than the current very low config that you have up on your site (version 6 I believe), if you want to see it tell me

EDIT: nvm, just saw that you're no longer working on it[/spoiler][/quote]
thankss <3. i honestly could have gone more in depth on the other stuff but I'm glad you liked it!!

and I would be glad to hear about it. I'm no longer working on mastercomfig, but that doesn't mean I'm stopping work on TF2 configs.
Please sign in through STEAM to post a comment.