How would server providers feel about this?

Most basic server providers don't allow for the adjustment of command-line parameters, I thought.

I reckon if you're even ABLE to set up 128 tick on your server, you have enough control over it that it shouldn't be a problem to do so.

ring saam ring!: Yo tragic
tragicservers.com: How's it going?
ring saam ring!: Pretty good thanks. I just saw this on TFTV
ring saam ring!: http://teamfortress.tv/thread/25252/tips-how-to-run-your-server-at-a-higher-tickrate#430695
ring saam ring!: And I was wondering what your thoughts were
ring saam ring!: Does increasing the tickrate have a negative effect on your end?
ring saam ring!: I know for CS higher tick rate servers cost more.
tragicservers.com: I'll make a comment
ring saam ring!: Cool, thanks.
tragicservers.com: when I have time to check it out and stress test

I think most people are able to put things in addons folders though right?

Yes, but you still need access to the server launch parameters to adjust tickrate - you can't change it through any cvar, and the only thing this plugin does is unlock the launch parameter.

I understand your concern though, and I definitely don't condone people trying to squeeze more performance out of server providers than they pay for - a tickrate of 128 is effectively doubling the CPU use and bandwidth of your server, and will negatively effect your server provider if you're not certain it's something you can do.

I'm open to people trying it on a server to see the load / stress it.

If you currently have a server with me, please do not use this. Chances are you'll do more harm than good and disrupt your neighbors performance.

If someone can gather a group and send me a friend request, please do so.

I don't see how this would be beneficial to your gameplay in the long run, cuz at the end of the day you're still playing on ESEA's servers for your matches, which run at 66 tick.

It would be fucking sick to see this on sites like serveme.tf and tf2pickup.net

c'mon EU

Doesn't apply to EU/AU/UGC. I think this is very interesting and hopefully there aren't any nasty bugs that come with it.

EDIT:

It looks like the cmdrate/updaterate is capped to 100 so the max tickrate a server can use is 100. Maybe there's a way around this cap.

Doors open/close much more slowly. This is very game breaking, because as a scout you have to wait 0.5 seconds for a door to open in Badlands, and rockets goes through roller doors that haven't properly closed yet.

It seems that ctap rocket jumps are slightly better with high tickrate (or maybe just easier).

Doors opening slowly can probably be fixed easily with a plugin (maybe modify the tickrate enabler source code for a tf2 specific version?), but I don't know about the rate caps. I'd like if someone who's well versed with writing plugins for the engine could comment on the subject

I tried asking serveme to host one server with this thing just for testing many months ago, but they didn't like this idea: "experiment with ur own servers", rip.

if its possible to play at 100 or 128 tick it should definitely be the norm

the argument that "dont use it, cause esea doesnt" is dumb. esea has 128 tick for cs, and if it was the norm for tf2 i imagine they would change.

the benefits are absurd, hitreg in scout vs. scout and sniper vs. sniper would be greatly improved

Have fun with subtly broken physics everywhere

Seems to show some potential. Tested it on TF2Center earlier today, and it seemed to run great. My game client couldn't go pass 100tick, but still better than 66.

I've set up a test server on 23.102.35.9:27015 (Germany) running this addon on MGEmod, for anyone willing to test it. It's gonna be running the next couple of days.

Right, I mean imagine all the things that could be slightly or significantly off...

-Weapons that have drop to them, Demo Pipes (time to detonate possibly too)/Stickies, huntsman, crossbow, rescue ranger, needles, jarate, mad milk
Airstrafing
-Juggling enemies
-Sentry turn speeds/fire rates?
-200ms scope headshot delay might not be 200ms anymore
-Dispenser Heal/Ammo rate
-Building build rate
-Medigun heal rate
-Pyro Airblast / Fire particles
-Idk as soldier I like shooting the ground next to dropped weapons in order to get more ammo, might not work the same lol.
(I assume movement speed is fine since nobody has noticed it yet)

I've found that increasing the minimum cmdrate and updaterate to 128 can force clients to values higher than 100. Try it out!

The engine is designed to intelligently scale almost every game mechanic with the tickrate. The only major negative difference I've noticed after lots of testing is the change in door speed.

"there are minor effects on air acceleration and fall speed, as well"

This would highly affect what I put in bold, has anyone tried bhopping to see if it has more or less potential than normal tf2 does?

Hey

That seemed to have fixed it. Thanks :) I've set up a feedback thread for the EU TF2 scene on ETF2L here: http://etf2l.org/forum/customise/topic-31551/

>The engine is designed to intelligently scale almost every game mechanic with the tickrate.

Literally no game engine in the entire world has a perfect framerate conversion system. Not source, not unreal, not unity, not even an engine someone might come up with for this very purpose.

I know for a fact that Source has a flawed delta time system just as unity does.

The closest that you can get without writing all of your physics code as higher order math is integer fractions of the base framerate through frameskipping.

Credentials: http://wareya.tumblr.com/post/81226191435/making-gg2-suck-less-physics-simulation-scaling

There's a strict 1.2x max speed limit when bhopping, and that's when landing tick perfect jumps - otherwise you're instantly capped to your normal speed. It's a strict cap in the code. The effects on airstrafing and fall speed are minimal enough to only really be noticeable in intense movement modes like surf and bhop.

I'm aware that it'll never be perfect, but I wasn't able to notice any difference with the game mechanics when I was testing - this is why the thread was made though, so that more large-scale testing could be done.

>The effects on airstrafing and fall speed are minimal enough to only really be noticeable in intense movement modes like surf and bhop.

Actually, tickrate is a hard limit on the accuracy of airstrafing in all cases. Increasing the tickrate will make airstrafing stronger/tighter.

Really? I thought that the default value of sv_airaccelerate 10 would cap airstrafing at a certain level of control regardless of how high you push the tickrate.

>I'm aware that it'll never be perfect, but I wasn't able to notice any difference with the game mechanics when I was testing - this is why the thread was made though, so that more large-scale testing could be done.

Sure doesn't seem like it considering that the OP reads as an informational post for unlocking the hidden powers of tickrate for better hitreg and replication.

This part is especially bitter:

>it was originally locked back in 2010 due to server owners not understanding it properly

You're talking about anyone who reads your post and takes it at face value already.

>Really? I thought that the default value of sv_airaccelerate 10 would cap airstrafing at a certain level of control regardless of how high you push the tickrate.

That's a limit on the amount of acceleration applied over time.

The tickrate is a limit on the angular portion. Airstrafing is technically a bug, and "the size of the angle of the acceleration that's being applied" (tickrate) has a huge effect on it. It's the reason why strafing in the air 90 degrees extremely slowly gives you more of a speed boost than doing so faster, even though both are still well below the "turning speed limit".

http://flafla2.github.io/2015/02/14/bunnyhop.html

I updated my CFG for servers like this

http://teamfortress.tv/post/430753/my-fps-config

// Competitive connection // Very few servers will have these settings
//cl_cmdrate 128 
//cl_interp .007 // this will likely have to be user defined .007 should be roughly the lowest interp, hit scan might do well at .0152 for this
//cl_interp_ratio 1
//cl_lagcompensation 1
//cl_pred_optimize 2
//cl_smooth 0
//cl_smoothtime 0.01
//cl_updaterate 128 
//rate 90000 // With higher tick rates you have more bandwidth being used

Sorry - I've rewritten that part now. I realize that re-reading it, it sounds too opinionated. As I've put at the bottom of the OP, I want to help this community - CSGO has reaped the benefits of 128 tick for a while, and I think we need to push to have it in TF2 as well, if it's possible.

I've read the linked article before, and I've studied the mechanics of airstrafing/bunny hopping pretty intensely - I didn't think the effects of high tickrate on airstrafing would make any extreme difference in gameplay, but that's why I want to do more wide-scale testing. We'll never find out if this is viable for competitive play if we don't try it.

Hope this becomes the standard

is the dark ages of 66 tick finally coming to an end?

soon the excuses of "this server isnt 128" will arise

this won't make any changes guys, this is not counter strike

So does the plugin need to adjust door speed by 128/66 or is there more to it?