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

This is interesting.

Obviously the big problem we keep seeing in the videos is whenever there's a change in direction there's a "warp". When jumping there appears to be an inverted effect where the player gets put into the ground. However, run server side it might be different. Let me think... Server side it would basically add a certain constant defined by the player's ping multiplied by the player's velocity vector for the position coordinates to each client. Yes, that should work. Though I don't know if that would remove the warp factor due to directional change (or acceleration, what have you). The server is still receiving the position packet with some delay, as defined by the ping between the player whose position corresponds to the packet and the server. Due to this you'd still see some directional warpage, though it would be half as strong as shown in the video. Overall it'd still make a difference, probably positive. Of course, if this becomes used by many servers players would start taking advantage of this by changing direction a lot (short strafing), which is already done by some skilled players. This would lead to a lot of desync corrections (warps, what have you) because position is being simulated ahead of time. Thus short-strafing would in a sense counter the usefulness of the program entirely. But it's certainly worth a test.

... I wrote a whole bunch more after this but modacity logged me out so it was lost. Fiddlesticks.

In short: because collision between dynamic objects is calculated client-side and because there's still delay between client and server you aren't going to be able to fix this, unless you recode halo's netcode to deal with collisions between dynamic objects server-side.


-Mator

Quote:

---

Originally Posted by urbanyoung

This sounds like quite an interesting idea. I think you'd need to modify the collision system that Halo uses based on which objects are owned by which player. I've never actually looked at Halo's collision detection, but I assume it's quite complex. Pretty cool idea, might be fun to have a look into.

---

Changes where players are drawn by the client based on the client's ping.

Quote:

---

Originally Posted by Mator

Obviously the big problem we keep seeing in the videos is whenever there's a change in direction there's a "warp". When jumping there appears to be an inverted effect where the player gets put into the ground. However, run server side it might be different. Let me think... Server side it would basically add a certain constant defined by the player's ping multiplied by the player's velocity vector for the position coordinates to each client.

---

The way I understand it, the reason for the warping is because this is client-sided, and it's a fault he recognizes. The problem with Halo's lag is that the server sends you the position information for all the players in the server, but by the time you actually see and shoot them, you are already about 100-200ms behind when the server originally sent the position to you. We make up for the difference by leading our aim. Since he uses the player's current velocity to put the actual placement of the biped on the client ahead of their actual position on the client, you have a better visual representation of where the player will most likely be when the shot is registered on the server. But it has its downsides. You can see that the prediction glitches slightly when a player jumps, and it could very easily confused if players strafe side to side a lot.

Paulus hopes to remedy these issues by making it server-side. Performing this action server-side would actually be the reverse of the client-side mod. The objective wouldn't be to modify the positional data that the server sends out to the clients. Instead, the server would have to recall a "history" of where the player has been for the past 100-200ms. The player's actual hitbox (or whatever registers hits) would have to lag behind the actual player's position, like a ghost or shadow player. This would allow the clients to see player positions as they normally would, but when they shoot the player they see, the server would have the necessary adjustments to compensate for the delayed client response, and it would hopefully register a hit.

Ah so instead of moving the visual of the player forward, it sort of delays the hitbox?

Fuck yes.

Why the fuck wasn't this done years ago?

Can we expect a release soon?

seriously this is amazing

Quote:

---

Originally Posted by Kornman00

Custom Edition uses the same networking code as PC.

---

Interesting, but then what makes playing CE such a different experience than playing PC? Somehow in CE people with pings over 100 don't experience as much lag as in PC. I always wanted to know what has been changed from PC to CE, because it plays different.

Quote:

---

Originally Posted by jcap

Performing this action server-side would actually be the reverse of the client-side mod. The objective wouldn't be to modify the positional data that the server sends out to the clients. Instead, the server would have to recall a "history" of where the player has been for the past 100-200ms. The player's actual hitbox (or whatever registers hits) would have to lag behind the actual player's position, like a ghost or shadow player. This would allow the clients to see player positions as they normally would, but when they shoot the player they see, the server would have the necessary adjustments to compensate for the delayed client response, and it would hopefully register a hit.

---

Thank you for the great explanation! I should have made this clearer. The tool that I have made is client-side, gives a rough prediction and has the warping issue. The server-side fix would not be a prediction, as such, and would not have this issue. Ever played Counter Strike? It would be like that (i.e. no leading - plain and simple). I have edited an earlier post to make this clearer. Note that the amount of lag for the hitboxes in each calculation depends on the player who made the shot (but there is no need to worry about this detail unless you want to try and implement it).

Here is an explanation for Vale's Source engine games - e.g Counter Strike - http://developer.valvesoftware.com/w...g_compensation . Note that player positions are moved back only to do a calculation. The clients never see this.

Quote:

---

Originally Posted by jcap

Paulus hopes to remedy these issues by making it server-side.

---

Paulus is suggesting these issues can be remedied by making it server-side. :D


BTW, the moderators are amazing! Thanks for all the fixes!

Kornman00:

I guess you are quite busy and don't have much time for something like this? Do you think the hit test function for things such as pistol bullets could be found around the code that decreases the amount of ammo during a pistol shot? Or, does a pistol shot create an object (bullet), which then causes hit testing to be performed later? (From Open Sauce: ) Would NetworkDatumData.owner_player_index work for this? Is OBJECTS_UPDATE_HOOK called once per tick (what happens before/after this hook)? Any other [hints/useful info] you can think of?

Quote:

---

Originally Posted by Kornman00

Custom Edition uses the same networking code as PC.

---

Things included in the new executable (HaloCE) are "Fast Shaders" (improves performance up to 60% on pixel shader hardware), improved network code (reduces the incidence of player "warping"), and lots of new features that provide options for players to improve their multiplayer games. Perhaps, most importantly, however, the new executable allows end users to play a potentially endless volume of new content created with the Halo Editing Kit.

Source: http://uk.pc.gamespy.com/pc/halo-com.../509885p1.html

Quote:

---

Originally Posted by PaulusT

Or, does a pistol shot create an object (bullet), which then causes hit testing to be performed later?

---

Firing a weapon spawns a projectile with the owner set to the shooting player. I then assume the projectile works like a normal object and its damage is triggered if a collision is detected, although I may be wrong. I haven't looked into this but it seems logical. If this is how it works then one would need to override a bit of the collision detection and use old (calculated) coordinates which are calculated based on the shooting player's ping and their recent location data. I don't think implementing something like this would be too difficult if you have a framework already done (OpenSource, Gandanur, Phasor, SAPP w/e). The most time consuming thing will be reversing the collision system and understanding how it works, so you can change it.