Since this is an Essentials.TF server, and someone with the Essentials.TF label said to use 132 update/cmdrate, I figured there was a good reason the server owners are saying to use that. I am also curious why they said to use 132 instead of 133.

If packets are being sent at a faster upload speed in bytes per second, the benefits of compression in terms of speed diminish. Also, the load from compression increases the more packets you're sending.

The rate settings are increased anyway, so fitting packets into the rate isn't really an issue.

With a higher rate setting, bytes are being sent faster and thus the transmission time you save from compression is less.

The defaults aren't designed for this higher cmd/update rate. It is more optimal to change them. Though, I agree that some of the more controversial settings might be best to discuss later since this thread is mainly about tickrate rather than net settings.

But there's no point for that extra load/delay on packets being compressed. The server and client both have to do extra processing for compression, and for little benefit. With such high rates being used anyway for this server, I don't think compression even has any sort of case to be used.

I don't know, but that's the update/cmdrate they chose, so I decided not to mess with that.

I prefer cl_interp 0, but since they recommended it and there isn't any difference (besides servers rules), I just put it again.

Packet compression doesn't do much and with that many packets, there's going to be much more load from compression.

net_maxcleartime 0.001 - Reduces packet delay to a minimum, which will help tremendously with choke issues
net_splitrate 2 - Changes the rate at which packets are split into smaller chunks if they're too large
net_compresspackets 0 - Disables using more CPU to reduce packet size by a little bit, since they're so many packets being sent, this reduces load by a lot
net_maxroutable 1260 - Ensures packets aren't being split unless they're at the maximum allowable size in the engine

Oh yeah, and I forgot that you should also be scaling up your split packet rate as well (this is the rate at which split packets are sent): net_splitpacket_maxrate. Set that to the same value as your rate setting.

Also maybe you can use sv_parallel_sendsnapshot 1, but I'm sure not sure about the stability of that one. It basically threads sending packets to all players.

It always had Linux support, but VAC vs hacks is a game of cat and mouse. Valve had many more years of playing that game on Windows, so VAC is much more comprehensive there. On Linux, there's a lot more things you can do to integrate your hacks, so VAC has to catch up to block those strategies. However, that doesn't mean VAC wasn't on LInux in the first place.

VAC always existed on Linux. Not sure where you got the information about CSGO, nor do I know what you mean by CSGO or TF2 VAC "implementations" in the first place.

VAC is implemented in Steam itself, not any game client.

nullifiedcat is just complaining about his personal accounts getting manually banned and spreading lies about VAC to make his cheat look better/more usable.

Linux does have VAC.

brutus has notoriously good aim. i'd love to see him fight a catbot.

I would recommend setting this on clients and on the server:

net_maxcleartime 0.001
net_compresspackets 0
net_maxroutable 1260

Though, net_maxcleartime will increase net usage some if you use it on the server, so if you aren't comfortable with doing that. Furthermore, I understand rate is capped at like 160k, but I would recommend it being 176624 at a bare minimum for 133 tick.

On the server:

net_splitrate 2

On clients:

cl_interp 0.0001
cl_updaterate 132
cl_cmdrate 132
cl_interp_ratio 1
net_splitrate 4

Nope you don't need it, the autoexec comes with the VPK

i get dizzy with any fps above 24 so id recommend tf2's default settings of

fps_min -10
fps_max 20
networking very_very_slow

it's harder to detect this kind of cheat. he wants to make a point about how "undetectable" his cheat is.

(his previous version was also "undetectable" but was eventually banned by VAC)

icec0ldconfig coming soon

welp, i can't compete with cool. nothing's cooler than cool.

It's strange people are getting this error even though the config sets it to 0 already.

6.1.2-beta

https://github.com/mastercoms/tf2cfg/archive/beta.zip

Optimizations, typo fix and new work in progress Bad CPU addon

Thanks

I've heard 81 is more stable than 80, whatever that means. 80 has less graphical features than 81, so you might get a performance boost from that.