akmdm akmdm I also backported the packet loss indicator from ZCC, which prints how many packets were missed on the client's screen when they experience packet loss. I left its default value to true, as it could be useful information to anyone who might be experiencing packet loss.
No need to be sorry, I greatly appreciate your patches! Also thanks for the updates regarding the movement regulator. Probably we should just return to the tic buffer from 3.0, so that we can release a new beta build soon.
I added 10268, 10269 and 10270. 10271 also looks fine, I'm just not completely sure whether cl_showpacketloss should default to true or not. The occasional missed packet is normal, so I personally wouldn't want to be bothered by minor packet loss that it nearly not noticeable.
Reply To torr_samaho >Also thanks for the updates regarding the movement regulator. Probably we should just return to the tic buffer from 3.0, so that we can release a new beta build soon.
Sounds good, I'd really appreciate that! I think a lot has changed in the last few months too so maybe we're ready for a new build. I'll still try to make any more improvements to the jerky movement as time goes.
I'm just not completely sure whether cl_showpacketloss should default to true or not. The occasional missed packet is normal, so I personally wouldn't want to be bothered by minor packet loss that it nearly not noticeable.
That's a good point, I can send out a quick revision which changes the default value to false and people can enable the indicator themselves if they want it.
No need to send a revision, I can easily replaced the bool locally :).
akmdm Reply To torr_samaho
No need to send a revision, I can easily replaced the bool locally :).
No problem, thanks!
Looks like you added the updated the patch the very minute I left the comment. In any case, 10271 with default false is added now.
akmdm I want to ask something, if we switch back to 3.0's tic buffer, could the buffer still empty at 4 commands per 3 tics rather than 6? That way the buffer isn't emptying too quickly as it does in 3.0.
Reply To akmdm
I want to ask something, if we switch back to 3.0's tic buffer, could the buffer still empty at 4 commands per 3 tics rather than 6? That way the buffer isn't emptying too quickly as it does in 3.0.
Sure. It's quite possible that the behavior of 3.0's tic buffer can be improved by some fine tuning.
Fork
Sorry, at this moment, I don't have much stuff ready for submission yet. Firstly, an update on the movement regulator: I tried giving it another chance and see if making it even less strict compared to my initial changes (gaps greater than 4 tics aren't accounted for, gaps timeout after 35 tics, adding a "current latency" variable that gradually transitions to the "safe latency" over a few seconds), but after testing with some friends I'm still getting a couple of complaints about delays, albeit less than before. The last compromise I can think of is reducing the max gap size to only 2 tics, but this would likely undermine the usefulness of the movement regulator.
Secondly, I tried experimenting with duplicating the last processed movement command for tics when the server doesn't have any stored movement commands left from the client, which kind of helps improve the stuttering (I tried observing this with two clients, one of which was configured to suffer ping spikes and dropped packets, the movement was less jerky compared to 3.0, even in the worst conditions). I might need to refine and test this some more to see if this won't be too problematic during actual online games.
Thirdly, I tried experimenting to see if it would be feasible to modify MovePlayer or MoveLocalPlayer command to only send updates on deltas like position, velocity, and angle, when they actually change in order to save some more on bandwidth. So far, there's some discrepancies in the positioning of the player while they're stationary on the server and client's ends. Maybe there's some way to improve this.
Lastly, I've been getting a lot of complaints about jerky player movement, or "player teleporation", when people change cl_ticsperupdate to something above 1. Even I can notice the jerky movement when I change my update rate to 3 tics. I suppose this never an issue in 3.0 or older versions since the tic update rate never worked correctly until now. I'll try finding a way to smoothing the movement in between the tics that new movement commands are sent.
In the meantime, I managed to quickly add a few small patches to keep things moving.