2.82 updates

[darkshade9]

I think the changes we've added recently along with the scope of changes warrants us to bump up the version to 2.82 unless you feel otherwise @Raptor007

1. Major addition of sv_antilag by Iceman12k for server prediction, will update the change.txt with more info before I change this PR from draft status
2. Crouch prediction
3. Ability to change team names, skins and skin indexes during a match (with some limitations)
4. Server no longer crashes if action.ini is missing, will warn the operator/player that the file is missing or couldn't be loaded, and loads CTF teamnames/skins rather than killing the server

[Raptor007]

Yes, I wanted to fix the big bugs like #95 before 2.82, and I'd say there's nothing critical remaining on that list, so let's go ahead and bump the version.

However, the changes are listed FROM 2.81 to whatever comes next, so this batch should still be added to the "From 2.81" portion, and any future changes should get a new "From 2.82" section.

Let's also change it to 2.82 in these places: https://github.com/actionquake/aq2-tng/blob/70bda152c7d16b8456d910ad1f5149d324d551eb/source/Makefile#L7 https://github.com/actionquake/aq2-tng/blob/70bda152c7d16b8456d910ad1f5149d324d551eb/source/a_game.h#L89 https://github.com/actionquake/aq2-tng/blob/70bda152c7d16b8456d910ad1f5149d324d551eb/TNG-manual.txt#L2

And I think this should say "Changes in TNG 2.82" to make it more clear: https://github.com/actionquake/aq2-tng/blob/70bda152c7d16b8456d910ad1f5149d324d551eb/change.txt#L1

[darkshade9]

Updated files as requested to reflect the 2.82 changes. Pending a few last minute changes from @Iceman12k mentioning he wanting to perform, this PR should be ready to go.

[Raptor007]

Thanks! Code looks good so far.

Might be helpful to add a short description of sv_antilag and crouch predict in the changes, and describe sv_antilag in more detail in the TNG-manual, such as the difference between values 1 and 2.

I assume the crouch prediction is just setting g_view_predict/g_view_high/g_view_low, and this tells modern clients like Q2Pro to immediately adjust viewheight for stand/crouch client-side rather than waiting for the server to send it? Very cool! Didn't know we could do it that way.

It looks like sv_antilag tracks incoming player positions and interpolates to reduce the teleporting effect? Makes sense with higher sv_fps especially, as I think Q2 was designed with the expectation of typically receiving at least one ClientThink for every server frame. I do appreciate that this is disabled by default as it would put player positions a little further behind (if I've understood it correctly) but I'm very interested to see this in action somewhere.

[Iceman12k]

I would like to do a bit more code cleanup/renaming of some cvars before this gets officialized. The antilag 1/2 concept was just for testing purposes, and should be split into 2 cvars for clarity.

What ""antilag"" does in concept tho is rewind the player positions to the timestamp the client is rendering at (assuming decently stable connection) and perform the hitscans from there. This means you can aim at the same spot regardless of your latency. Antilag 1 adds an additional frame to account for interpolation, so you can aim directly on the model. Antilag 2 (the preferred method since it has zero noticeable impact to the game on low pings) doesn't account for interpolation, so you still have to aim 100ms ahead with sv_fps 10. This all does have the side-effect of interpolating the hitbox positions as client rendering does, which means hitting laggy clients is probably a lot more consistent as well, though I haven't tested that much.

This principal is written up by Valve for Source engine here

Crouch prediciton implementation in the gamecode is fine, but I have some engine cleanup to do on that.

[Raptor007]

Ahh I see. So when firing a hitscan weapon, it estimates how long it took for the packet to arrive from the client based on ping, then temporarily moves all other players back to their position at that time to do the hit checks. Very clever!

Completely unimportant but I have a slight preference for this: antilag_t *state = &ent->client->antilag_state; ...to look like this: antilag_t *state = &(ent->client->antilag_state);

Just because at first glance I thought it was taking the address of ent which is already a pointer. But that was before I'd had my coffee so maybe it's just me. :¬)

[darkshade9]

I think we're ready for a formal review @Raptor007 @Iceman12k :) Probably one of the bigger PRs in recent history?

[Raptor007]

All looks good to me!

It depends on what you mean by "recent". Pull #6 was insanely big.