Anti-latency (server-side hit detection / correction)

I did some research on object visibility that used bounding sphere volumes to test if an object was in the view frustum or not (in my old reverse engineering references thread). I believe collision testing may do something like this, maybe with bounding boxes instead. As far as updating objects, I would also do a collision test with the bsp geometry to make sure an object isn't partially inside/under, which may be causing the warping or physics problems (depending on when you are updating positions). There is bounding information in each object structure you should check out, I think it is undocumented in OS. I can't remember the offsets since all my work was deleted. Refer to the object tags which has the bounding info also. (Centre & radius??)

They're documented; see s_object_data's center/radius fields.

Ah, you're right! Thanks for clearing that. I hadn't checked your struct updates since I did that research a few years ago when it wasn't there. :P

Thanks for the info. As mentioned earlier, note that the warping does not apply to the proposed server-side fix and no extra/added collision testing should be needed.

The question that might be important for making the server-side tool is: Does modifying the positions of players just before the bullet hit-testing have an effect?

You want to send a fake player position from the server to the client before the bullet-collision testing?

The only way I see "improving" the latency would be just to move the player ahead into the predicted direction client sided...and pray that the predicted position is right.

I remember a predicted_position field in the s_player_datum struct in an older build of Open Sauce. I've personally never messed with it, but maybe you could make use of it (assuming it does what you're looking for). If not, there's always the possibility of taking into account the player's looking vector and throttle key states and using them to more accurately predict the player's next position.

Quote:

---

Originally Posted by Patrickssj6

You want to send a fake player position from the server to the client before the bullet-collision testing?

The only way I see "improving" the latency would be just to move the player ahead into the predicted direction client sided...and pray that the predicted position is right.

---

Ooops no sorry.

1. The method would be like this:
http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Lag_compensation

Looking at the figure: A player has shot directly at the running player. At the server, the bullet shot where the cross-hairs are. It misses the player that is running. This is because the player that made the shot did not lead and by the time the message (containing the shot information) reaches the server, the running player has moved. To fix this, the server moves the running player back (but only temporarily, during hit testing), depending on the ping of the player that made the shot. Moving the player "back" is achieved by keeping a history of all player positions. This "moving back" (just for collision testing) is shown in the diagram as the wireframe model. Thus, the shot is registered as a hit at the server.

2. Regarding the question: I want to know if moving the player positions (at the server) just before the server performs hit testing actually makes a difference (i.e. change the outcome of the hit test). The player positions will be reset to their original positions after hit testing and the clients see no change in position. The reason why it may make no difference is that the player position may not be read/accessed during hit testing - it may be that the collision volume position is calculated *earlier*, using the player position. Thus, changing the player position at this later stage makes no difference. This is an implementation question and is not really important for understanding the idea (1).

3. None of this is important until someone starts implementing! :downs: I'd like to try. My previous post may help those who want to do some tests...or not.

Quote:

---

Originally Posted by Choking Victim

I remember a predicted_position field in the s_player_datum struct in an older build of Open Sauce.

---

I was referring to that. I don't know how the predicted position field is exactly calculated (is ping even considered?) besides position, direction and movement vector. For testing purposes you could try moving the player ahead into the predicted position :S

Of course the method you posted Paulus is a lot more thorough.

s_player_datum has two different (union'd) networking structures depending on what the current game connection is (ie, if it's running as a server or client). Those structures are mostly related to processing player network message updates used by the game and shouldn't be touched directly.

I did something like this a while back. Ultimately it didn't work because the language i was using (auto hotkey) could not track the player positions fast enough, so I planned to give up until i later someday maybe learned something like C++. But other parts were working.

Warning: this one of the first things I ever wrote and so its probably extremely nooby and hard to read, but maybe its of some use to somebody:

http://pastebin.com/JQstFiTs

Basically the program tracks and records players positions, checks when pistol shots have been fired, sees if the shooter is aimed at anyone X ping into the past recorded positions, then does damage to the appropriate player. The 'dodamage' part worked up until the part where the player actually needed to die.

There are some theoretical problems with my nooby approach:
-The program just checks if the shooter is aimed at any player, not accounting for any walls etc in the way.
-This wouldn't work for slow moving projectiles like the plasma rifle bullets. The program would have to check where in space the PR projectiles are and do a hittest if they ever came near an enemy. The pistol checking in the program was meant to be as if the pistol were instantly shot across the map, even though the real pistol bullet in normal gameplay isn't instant.
-Ping might fluctuate and not appropriately match up such that shooters can aim right at enemies and register a hit, i don't know.


I think the easiest approach would be to write something for the client that tells the server 'i just hit player 2' and then have the server do the appropriate damage. The client would just check for whenever their shot activates the pistol effect on someones armor, or something like that I guess. People exploiting the client-side system isn't a concern of mine because I simply wouldn't play with cheaters.


I would really love if someone fixed the lead out of halo. I actually still play halo PC almost every day vs other organized players, few games a day usually. Mostly @ or around http://s9.zetaboards.com/HPT_Forums/site/ . There's at least a 100 of us regularly playing. Tonight we just had a $100 3v3 tourny, the semis/finals being a few days from now. Since I know all the people I'm playing with basically, you can see why i wouldn't mind a client side solution, because it would be easy to get them to download and run the client.