network settings to use higher tickrate imo:
rate 133000
cl_interp 0.0001
cl_updaterate 133
cl_cmdrate 133
cl_interp_ratio 1

https://cdn.shopify.com/s/files/1/1061/1924/products/Eyes_Emoji_large.png?v=1480481045

Just a question: What does any of this mean?
I would be perfectly willing to help out, if I knew what I was supposed to do.

tf2 is normally 66 tick

these servers are 133 tick and are an experiment to see how stable they are/how they affect gameplay

they might disappear after a bit but if ppl like them they'll stay

give feedback

i think u mean Sydney

HiipFire - Today at 7:37 PM
uhh @twiikuu it's spelled sydney
twiikuu - Today at 7:38 PM
YAWN

I tried it out with funs, didn't really notice much difference besides it felt easier to hit as soldier. Felt like rockets were travelling faster

tickrate changes fucked with sentries in the past, making them way stronger iirc? Is there a way to check if this still happens?

just played some mge and it seems smoother and a lot nicer to strafe though not a huge difference overall; I am on 60hz though idk if that makes a difference.

Also at 60hz and it does make it smoother and nicer to strafe.

I have 5 ping to the server though, that could also affect things

at 144hz the sentry tracking/idle animations are very choppy, even with interp on. that's the only oddity i noticed from messing around on the NA DM server by myself for a bit. general movement, airstrafing, rocket jumping etc. all feel extremely smooth and responsive, even with 60 ping. would absolutely love to try playing some pugs with these plugins.

the DM servers don't seem to have any kind of whitelist or class-specific limits (max 2 of everything) so you could always just hop on with other people and build some sentries i guess

I have 7.6 interp and the game feels smoother than ever for me. Everything is super crisp on 240hz. I dont think it is placebo. Make sure you guys use the net settings on comment #2.

this needs to be standard asap

my 100 ping felt like 35 and that made me very happy

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

If I remember correctly in the past higher tickrate servers had issues with shutter doors and airstrafing(among other things). I played in the dm server and didn't notice either of these being a problem does this mean you fixed it or did I miss something?

Also please add classlimits/whitelist.

If people really want this and it works without any side-effects I don't mind adding this to my dm servers

Would love this. Yes please.

I'll update original post with what people have reported so far, and what we've discovered as well.

Sorry!

We couldn't reproduce that, could you give us more details or a video to showcase it?

I've added all of this but could you explain what they change? Thanks.

We won't restrict anymore than what's already allowed (2 of each on SOAP, sc/sol/dem/sniper on MGE), we'd rather see people test every class and weapons.

I would actually rather see this happen than us hosting our own servers, hit me up if you need any help setting up.

When I tried this before bhopping felt more consistent (i.e. scrolling down every time you land will almost always keep your RJ going) which is kinda counterintuitive, can anyone reproduce?

Csgo works differently but with that it isn't really any harder on high tickrate, it just changes the timing a bit (because you need to send a +jump on one tick and a -jump on the next I THINK)

Why?

Why not just cl_interp 0? I don't see anything special about the value 0.0001, so it'll just clamp to 1/cl_updaterate either way.

net_compresspackets 0

This sounds like it will increase network usage, which will presumably already be pretty high seeing as the server is 133 tick. Can't speak for everyone but my internet isn't great so I'd prefer if this were avoided.

The interp is because I've seen issues in the past with setting interp to 0 when on LAN, so this ensures you're always on the lowest and never run into problems :)

I've modified 3 EU serveme.tf servers to run at 133Hz:

133Hz - BolusBrigade #1
133Hz - BeretBrigade #1
133Hz - KroketBrigade #1

Just tick "Enable plugins" when making your reservation.

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.

Could you made edit your post to include all the steps you need to do in order to play on these servers?
Like you've added a few settings but do I need to change the stuff WolfMachina posted as well (mastercoms also posted some different/extra things)?

We're talking kilobytes per second here, this will not cause >1% CPU load on any CPU made since TF2 was released. Also, only large packets are compressed (net_compresspackets_minsize).

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'm not sure what your logic is here. If compression reduces the average packet size to X% of what it was originally, only X% of the original bandwidth will be used. This saving will apply regardless of the rate packets are being sent at.

cl_updaterate 132
cl_cmdrate 132

???

Edit:

Can't think of a good way of phrasing this, but I don't think you should be giving out advice based on justification this weak.

The point is reduced transmission times and fitting all packets within sv_maxrate, it's a trade-off. The time you lose (<0.02ms) to compress a packet is gained by having to spend less time transmitting it (because it's now smaller).

I'd stick with the defaults (both client and server) over lists of TF2 client and server cvars with no data/benchmarks.