Hitreg Fix (REQUESTING SERVER CVAR CHANGE)

[ELK]

Having the same update rate and command rate causes timing issues. I was told this by somebody who knows the engine, and also networking. I could possibly get more information on this if staff requests. It would be best to limit command rate to 99.

One may assume a command rate of 99 would skip every 100th command send but this is not how rates work. Instead it sends a command every 10.1010...ms instead of every 10ms. Everything is done in time not rates actually even how rate chokes.

I appreciate that you fixed your sv_minrate upon my request long ago. The server is now 100-tick and sv_minrate and sv_maxrate 100000 is not high enough when the server is full or has many players. Please enable net_graph and observe the numbers above the bars at the top of the network graph. This is how large the updates are in bytes (after decompression*).

If a player recieves a 1100 byte update with an updaterate of 100 and a rate of 100000 the server will wait 11ms before sending the update to the client (update rate 90.9090...) [This is not 100% accurate as the net_graph shows decompressed packet sizes, and most players will be using the default values of net_compresspackets 1, and net_compresspackets_minsize 1024]

PROTIP: Choking caused by a server's poor rate settings like this one can be avoided with one simple cvar! So the server checks the updaterate and rate settings and decides how long to wait before sending the next update as explained above, but the client tells the server the maximum amount of time it is allowed to delay an update with the cvar net_maxcleartime 4.0. By changing net_maxcleartime from 4 seconds to 0.001 seconds with the command net_maxcleartime 0.001 the server cannot delay an update even if it's exceeding the rate calculations.

---------------------------------------------

HITREG FIX

cl_updaterate 100 as this effects interpolation, cl_cmdrate is not needed as the server currently forces 100

cl_smooth 0, If a prediction error occurs, most commonly caused by choke, loss, or poor server performance, it will "rubberband" you back to the correct position over 100ms. The server does not use your rubber position during hitreg, it uses your server position. By disabling smoothing you will instead instantly snap to the corrected location. You can see when prediction errors are occuring with the cl_showerror 2 cvar.

rate #######,  rate is an important command because if your bandwidth is exceeded it will cause udp offholds (extra loss in a row) compared a delayed update the server will send you (choke). Even though this command can help people with very slow internet like me (600kbit) I STRONGLY suggest server owners set it to a high value because most people will be running default network settings, and if the minimum rate was low players would have a poor experience. The highest value that has any effect is 1048576‬, I suggest setting it to this as most people's connection are 8mbit or faster.

net_splitpacket_maxrate, here is a command people tend to not know about. It's identical to rate except for split packets. Packets are split when larger than net_maxroutable 1260, and unfortunately sent over 1 frame at a time instead of 2 by the command net_splitrate 1. Speaking of which:

net_splitrate 2, if packets are split into two, send two per frame instead of the default 1 per frame.

net_maxroutable 1200, I don't know why but the expert suggested this and I think I recall him saying something about it being less than the server's is important.

net_maxfragments 1200, I don't know why but the expert suggested this and I think I recall him saying something about it being less than the server's is important.

AND NOW THE MOST IMPORTANT SETTINGS FOR HITREG

cl_interp_ratio 1,  This will change your minimum interp to cl_updaterate 100 = 10ms,,, 10ms/1 = 10ms. The default is 2 which would be 20ms.

cl_interp #.###, Now to tweak your interp using net_graph 3. At the very bottom of the network graph is a blue area with orange bars. The orange bars indicate how long it took to interpolate that update. If the bars raise above the white line that means it did not interpolate and falls back to extrapolation. To fix this you need to increase the duration of the interpolation buffer using cl_interp. The server ALWAYS uses interpolated positions to check for hit reg. Also you will have to lead your shot to hit an extrapolated enemy.

A little known fact is that cl_interp actually has a hidden minimum. You can confirm this yourself by using cl_updaterate 1000, cl_interp_ratio 1, cl_interp 0. This will set your "lerp:" on your network graph to 1ms. Every orange bar should be above the white line now, but it's not. If you now change your cl_updaterate to 100 for 10ms,  50% of the bars should go over the line, this is because your ping isn't a perfect, for example, 50.0000ms, if you recieve a packet even 0.1ms late it will have no time to interpolate thus the bar should raise above the line, and if it drops even 0.1ms it will have the data it needs to interpolate. But instead it's nowhere near 50% of the time. Also confirming there is a hidden minimum. You can also set it back to the default of 100ms by entering cl_interp 0.1 and see that all the orange bars are well below the white line. This hidden secret has helped people using the bad net settings for a long time

YOU CAN ALSO CHANGE THIS

net_compresspackets 1, this is default anyways

net_compresspackets_minsize 128, the default is 1024. The chance that somebody has a 20 year old network adapter that isn't fast enough to decompress packets is extremely unlikely, so why not compress them all and save data. This is a nice addition to anyone on extremely slow net like me or a metered network.

 

TL;DR

SERVER OWNERS; will you please change these ConVars to these values on your servers sv_mincmdrate (65 for 66-tick, 99 for 100-tick, 127 for 128-tick); sv_maxcmdrate (65 for 66-tick, 99 for 100-tick, 127 for 128-tick); sv_minrate 200000; sv_maxrate 200000

 

PLAYERS; Copy and paste this in your console to fix your hitreg on 100-tick servers. Rate & net_splitpacket_maxrate are not included because net_maxcleartime overrides them. I suggest you read cl_interp to tweak it for your net but I included the value that works best for my net (which is really bad).

cl_updaterate 100; cl_cmdrate 99; net_maxroutable 1200; net_maxfragments 1200; net_splitrate 2; net_maxcleartime 0.001; net_compresspackets 1; net_compresspackets_minsize 128; cl_interp_ratio 1; cl_interp 0.025

 

EDIT: removed one of the net_compresspackets 1 from the player suggest TL;DR rates because it was in there twice

 

 

Edited May 21, 2020 by ELK

[Benz]

We will look into this and get things resolved. Thank you for reaching out to us. @ne0g33k is our server manager for CS:S.

[ELK]

sv_client_cmdrate_difference is currently 0 and would have to be changed to 1 to allow a cmdrate of 99.

sv_client_min_interp_ratio & sv_client_max_interp_ratio are both 1 I would suggest changing these to 1.5 to allow for more jitter than the hidden minimum ratio. This will only effect players using custom net settings that include cl_interp 0, as the default cl_interp 0.1 will override cl_interp_ratio's calculated value. [This will also effect players even if they are using 66 rates. lerp is falsely reported on the net_graph using a calculation of the client's cl_updaterate when in fact lerp is calculated on the server forced cl_updaterate value. This can be proven by changing your cl_interp to 0, cl_interp_ratio 1, and cl_updaterate to 10. The net graph will report 100.0ms of lerp, but the bottom of the network graph clearly shows that your lerp is in fact slightly above 10.0 as you will not only see bars sometimes raise above the white line, but also if you change cl_interp to 0.1 it will look completely different. This also means setting your cl_updaterate to 1000 will not give you 1.0ms lerp lol] A value of 1.5 is aggressive and would be ideal for stable connections. I use cell tower internet and use a value of 25ms as I have very bad network jitter.

Edited May 21, 2020 by ELK

[ne0g33k]

This is a pretty tall order, I will look into it. So Basically you want to Change all the servers, and have all the players that play on our server to change their configs. This is where I would insert my Evil Admin Laugh, but I will consider your request puny Mortal.....  

[ELK]

You're not wrong that I would like all players to change their rates but that won't happen. Everyone except uber music anyways because that guys stomps me lol The server can, at the most, use these commands.

 

sv_mincmdrate 99; sv_maxcmdrate 99, sv_maxupdaterate 100, sv_minupdaterate 100; sv_minrate 200000; sv_maxrate 200000; sv_client_cmdrate_difference 1

This will effect all players^ They won't be choked by defaults rates except those larger than 1260 before compression because they are sent once per frame due to the default value of net_splitrate 1, and will not have timing issues caused by identical update/cmd rates.

sv_client_min_interp_ratio 1.5; sv_client_max_interp_ratio 1.5

Will effect players using most of the hitreg configs available^ Players with good net using configs won't have unnecessarily poor hitreg effected by extrapolation.

 

Thanks for considering these changes.

[Benz]

We are always working on ways and things that can be done to improve the gameplay on our servers for our population. We will look into all of this and get back toy ou on this thread.

[Lyden]

 

i have no idea whats wrong with the hitreg on hg servers, i have the same latency on awpclan servers but on those servers the hitreg is really really good
I hate awpclan servers, but the hitreg is crisp
And i love hg servers but the hitreg is really bad
Is it really just about server settings? idk anything about this, i just find that hard to believe
The hours before the hg servers reset each day the players start to shake for me, been like that for me for since i first joined a hg server over 3 years ago, have never seen that on another server before
 

Edited May 28, 2020 by Lyden

[Benz]

We are working on this. @Lyden

[ELK]

There is a hitreg problem I know about, but don't know how to fix. I was scolded by somebody on right here on the forums. They suggested just as I, to restart the server more often as after time the issue becomes worse. There is more diagnostics in source SDK. With my little knowledge I was trying to see if I could pinpoint the issue but the other guy raged at me to not do so even while I suggest to the server owners to restart more often. I gave up because of the scolding.

 

I have been a paidmin in the past and you must type status within x amount of time (maybe 30 seconds maybe 1 minute) by HG rules of reporting because as far as they are aware that was the only way to get steam id which is of course the only way to accurately ban people and avoid banning the wrong person with the same name or scams which fake the same name. There is actually a console command that will list all steam ids in a demo. That was in one of my other posts. I'm rather certain it was an OP, but it's worth the staff looking into, which can help ban hackers.

 

I don't really check up on this thread, and all I know about having different update rate and cmd rate (keep in mind everything works in ms not rates which always vary) If a dev wants more information as why to set cmd rate to 65 and update rate to 66 they should contact the creator of tf2's master comfig, yes that is with an M and yes you will have to hit the "i meant comfig not config" when searching on google. He has a discord. Funny thing is servers actually run 66.666... tick which is actually 15ms exactly per tick. 66 tick doesn't even line up with the server. 100 on 100 tick does though.