evil elmo wrote:That was me flow, sorry but all those bright colours was a bit much on the eyes and made the post hard to read, hope you dont mind 2 much
Now for what i'm using atm is... Cl_updaterate 66000 / cl_cmdrate 100.
Little_Devil wrote:Now for what i'm using atm is... Cl_updaterate 66000 / cl_cmdrate 100.
lol no point as for 66,000, where did you get that from ?
Not that it matters so much, because the server limits the rates when you join to a minimum of 40 and a maximum of 66, which is ample.
These figures are variable anyhow because of how the game engine works and how good your net connection and computer is. these figures are fractions of a second and are requests sent to the server for how often you update the server and how often the server updates you, in the end it is down to how often the server can do these with the amount of players on the server.
rates 20 = 1/40 seconds = 25ms, 66 = 1/66 seconds =15.5ms
The best figures you can have are those you choose, for your machine.
cl_interp_ratio and cl_interp are related so will need setting for your machine.
interp is in fractions of a second 0.1 = 100ms interp ratio is a multiplier to be used.
lerp is the combined effect of interp and interp_ratio shown in ms.
e.g. interp of 0.1 interp_ratio = 1 lerp = 100ms
I can't work out if the interp ratio means 2 to 1 or times 2, but I would imagine from the reports of results it means a 2-1 ratio.
interp of 0.1 interp_ratio = 2 lerp = 200ms, which would be pretty pointless
whereas interp of 0.1 interp_ratio = 2 lerp = 50ms would be the most likely.
interp is interpolation, which is a predictive control for the next position of a model. The lower the lerp the better the game play, but you may well lag due to your computer work load being too great.
As far as timings are concerned, you have to picture what is happening on a time line graph.
Suppose you have a decent connection, with the perfect computer and are being updated from the server on a regular basis of every 16ms, having a lerp of 100ms is not going to achieve anything at all, as you have already received positional information from the server nearly 6 times already.
However you have to look at the real world and all the other variables, like acceptable data loss over the net, together with your ping, the speed of your machine, what background tasks you are running, the speed of your monitor etc etc etc...
Servers do set the interp, so a setting of interp to 0 would let the server set the best rate for the server you are on and you could then try halving that to possibly get better hit stats by using interp_ratio of 2.
Little_Devil wrote:If you set cl_interp to 0, the server will set the best interp for your connection, then set cl_interp_ratio to either 1, which sets whatever the server sets interp to or you can half the time by setting it to 2. lerp is a result figure and is the interp divided by the interp_ratio. Divide by 1 is whatever the interp is, divide by 2 half the interp value.
For the sake of explanation, the Update and cmd rates are 1/x where x is the figure entered after the command, in this case 66. 1 divided by 66 is around 15.5ms.
interp times are seconds based, not frame based so the number after the command is in seconds. 0.0155 seconds = 15.5ms
By the very nature of the game the update and command rates are frames per second so are not strictly speaking data bursts of fixed lengths in time. (don't mistake this frames per second with your fps value, frame is a term used in the calculations and is not strictly related to fps)
Whatever you choose for interp ratio, is what is best for your machine and the only way to find that out is by testing on your machine. If your machine can handle a ratio of 2 without degradation of graphics, it will be the best you can have, without messing around with the interp figure as well.
I could explain the methods used in isolation to everything else that is going on, but as you could probably imagine this would not show a true picture, without taking into account all the variables, which would include thing like your monitor refresh rate and where everything was synced to. It gets quite complicated when you start to look at everything and tbh a rough setting is the best you can hope for, given the computer you use is not stable either. Imagine an equation where every single component is a variable with no reference constants.
Good luck with your endeavours
Little_Devil wrote:Thanks for pointing out the lerp times for the different cl_interp_ratios, as it does appear to be counter intuitive to have a multiplier rather than a divider.
I can see where your confusion comes in, not helped by my mistaken assessment of the interp_ratio numbers
If as you say you get 30.3ms for a ratio of 2 and 15.6 ms for an interp of 1, then it would appear that the interp_ratio is indeed a multiplier. In which case a cl_interp_ratio 1 would be the better value to have, as interpolation would be every 15.6ms. I presume with a good machine this would be fine.
Consider the following :
F = the frame you receive from the server. net dependent.
> = cl_udate/cmd rates of 15.6ms sample time.
P = interpolated frame. Machine dependent.
< = interp time
<=> for this demonstration.
Fx = missing or corrupted frame.
There is a lot more to this but showing just these 2 will suffice.
You start all maps with F
The following sequence is what can happen : F > F > Fx > Fx > F
now depending on the times chosen you also have F followed by as many P frames as needed until the next complete F frame, spaced out at regular time intervals of <.
So if you have 15.6 ms then you are interpolating the next frame if it is missing out of the next download, or every 2 Frames with interp_ratio at 2. This of course carries on until you receive the next proper F frame.
The above sequence would then be F > F > P > P > F
You also have to take into account that due to the spurious nature of the net, the > may actually be delayed so the time of the next F frame could be delayed and not missing. This would lead to a P followed in a very short time after an F. This scenario would of course lead to a heavier load on your CPU.
P is of course best guestimate so the model may jump slightly if the positional information generated is wildly different to that of the F frame.
As you can see the relationship between update and command rates is important, which is why you have interp set to 0. You can of course try to interpolate faster, or slower if you wish, but do need to take into account your rates.
Users browsing this forum: CommonCrawl [Bot] and 1 guest