search

Raptor007 / aq2-tng

Action Quake 2: The Next Generation. Raptor007's sandbox for testing changes. When verified stable, this code is pushed to the official aq2-tng repo:
https://github.com/aq2-tng/aq2-tng/tree/bots
4 stars 2 forks source link

Knives rotation animation is sometimes slow on sv_fps enabled server #104

Open m4son opened 3 years ago

m4son commented 3 years ago

When a player is using cl_updaterate 10 on variable fps ( sv_fps 20 ) enabled server, knife throwing animation is sometimes a bit slow.

Raptor007 commented 3 years ago

Do you mean the knife spinning as it flies, or the hand model as it throws the knife?

m4son commented 3 years ago

Yes, when it flies.

Raptor007 commented 3 years ago

At a quick glance through the code, I don't see a reason for this to happen.

In knife_throw (g_weapon.c) knives are given angular velocity 1200 along their spin axis and set to MOVETYPE_TOSS: https://github.com/Raptor007/aq2-tng/blob/51406d4d32cf7ce7867010bb0ad8b12823dc68c7/source/g_weapon.c#L1129-L1131

Every server frame, objects with MOVETYPE_TOSS should run SV_Physics_Toss (g_phys.c) which among other things rotates their angles proportional to the server frame time: https://github.com/Raptor007/aq2-tng/blob/51406d4d32cf7ce7867010bb0ad8b12823dc68c7/source/g_phys.c#L868

Because the server is performing the rotations rather than just sending delta angles, it doesn't seem like there should be a way for this to get behind or out of sync on clients of different update rates. Running at half the update rate should simply skip over every other update, but the updates received should still have two frames' worth of rotation applied to the angles.

My best guess so far: there may be some difference in client-side interpolations between rotations of 120 at 10fps (1200 / 10) vs rotations of 60 at 20fps (1200 / 20). If that's the case, I don't think it can be "fixed". However, 10 updates per second to the client should always look the same regardless of what the server's actual framerate is; it just might not look exactly like the client-side interpolations of someone else running a higher update rate.

When I have some more time, I'll do some side-by-side comparisons of two different clients running different update rates on the same server, as well as comparing cl_updaterate 10 with sv_fps 20 side-by-side with a different game that's simply sv_fps 10.

Raptor007 commented 3 years ago

It just occurred to me that a dropped UDP update packet at 10fps would mean the next received rotation is 240. If that unit is in degrees (and I think it is) the client-side interpolation might briefly rotate the knife backwards rather than forwards. This could overall make the knife appear to be spinning more slowly. If this guess is correct, it's a problem you'd likely see with either cl_updaterate 10 or sv_fps 10 and some packet loss, but you wouldn't generally see it on a LAN or at any higher update rate.

If you can recompile the aq2-tng code on a server where you're experiencing these issues, try editing g_weapon.c line 1129, changing the 1200 to 890. This will slow down the knife rotation speed to 89 per update at 10fps, which means even with a dropped packet the next angle change would be 178. Anything less than 180 degrees should still interpolate as a forwards rotation. (I don't think this reduction in rotation speed would be a good permanent fix; it's just to test my theory.)