Anti-latency (server-side hit detection / correction)
I recently made a tool for Halo CE that draws other players slightly ahead of where they are, using their velocity and your ping. That is, it draws them such that you can often shoot without leading. It works for vehicles too. It is not perfect; obviously, there is no way of predicting that a player will change direction. "Draw" is also the wrong word, as it does actually affect the physics in a weird way (but only briefly, unlike one of the prototype versions, which constantly had players falling through the floor).
What would be better is if the server could correct the actions of players based on their ping. For example, the server could store the positions of players for the last second. I am not sure how many positions that is (how many updates there are per second) but I am guessing it might be 30 positions for each player. Then, when player X fires a shot (and the server is doing the collision test for the shot), all other players would have their position (temporarily) set to one of the earlier stored positions (depending on the ping of player X). Hence, player X would not need to lead his shots, although the actual hit would still be delayed.
This is a slightly simplified example. Ideally, all objects could have their positions and various other important state information stored from the previous 1 second (or the maximum allowed latency that is desired). I am also not certain how easy it is to relate events (such as the collision test of a vehicle that has been pushed by a player) to the player that caused it and how easy it would be to hook into the code for these different types of collision tests. I guess it would also be challenging to identify which bits of state need saving, especially if other objects are referred to.
I thought this idea seemed like a rather naive form latency correction and that it may not really work well enough in practice. However, I recently saw that Valve's Source engine uses this type of hit detection. Therefore, I guess it can work well.
This does allow the situation where player X appears to be in cover on his screen, but is killed by player Y, because the latency of player Y caused player X to be moved back out of cover when the server performs the hit testing. However, this is usually the case with any kind of hit detection that does not require players to lead their shots and I think it is probably a reasonable sacrifice. A limit could also be set on how much latency correction is applied.
I have thought about implementing this, but I fear that my knowledge of Halo's engine is probably too limited. I am also just about to start some other work that I should probably give priority to. I don't know much about Halo's object list and how objects are deleted/added etc. I don't know where the different collision tests are performed and what parameters are accessible. I thought that, to start with, it might be worth just trying a proof of concept, where only player positions are stored and only immediate hit tests (e.g. pistol?) are considered. I remember in the Halo 2 engine you could figure out who had caused the damage (or who owned the bullet), but I can't remember the details. Thus, I think it would be possible to intercept the hit detection function and adjust player positions as explained above.
I know that "idea" posts are not appreciated, but I hope those with a good knowledge of the Halo engine can see that this is perhaps reasonably plausible. Of course, I have probably missed many issues that would arise and maybe this is just not feasible. I may attempt this one day, but it would be even better if those more knowledgeable are interested in trying it.
(On a somewhat related note, does anyone know the units of velocity that is found in Halo's memory for players? How many updates are there to player positions per second? The overall related question: What is the formula for working out where a player should be drawn given the velocity and current position (of others) and ping (of the client)?)
September 28th, 2011, 11:47 PM
TPBlinD
Re: Anti-latency (server-side hit detection / correction)
The latency and leading are what keeps bringing me back to this stupid, terrible game lol
September 29th, 2011, 12:44 AM
n00b1n8R
Re: Anti-latency (server-side hit detection / correction)
The latency and the leading is what keeps me leaving this stupid, terrible game lol
September 29th, 2011, 01:04 AM
n00b1n8R
Re: Anti-latency (server-side hit detection / correction)
Can you post a video of this in action? I could see it being useful for ranged engagements but it sounds like it would make pistol strafing and close quarters stuff really confusing.
September 29th, 2011, 04:02 AM
supersniper
Re: Anti-latency (server-side hit detection / correction)
i'm intrigued
September 29th, 2011, 09:30 AM
sanni
Re: Anti-latency (server-side hit detection / correction)
I rather would be interested in Halo CE with Halo PC netcode.
September 29th, 2011, 02:57 PM
PaulusT
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by TPBlinD
The latency and leading are what keeps bringing me back to this stupid, terrible game lol
I know what you mean. But, this is not how the game was meant to be played. It also means the leading depends on your connection, which means it is inconsistent (across servers, players, etc.). Introducing people to Halo PC (the upcoming release of Halo Anniversary means people are more likely to get back into Halo 1) is difficult due to the inconsistent and confusing leading. I believe more recent versions of Halo require leading, but this is not caused by network latency - the bullets are just slow. Thus, when you are in close range combat, no leading is required. Otherwise, the amount of leading depends on how far away your target is, which means even more skill is needed (adjust lead based on feedback and by judging the distance). This could presumably be added to Halo PC quite easily server-side, if desired. Weapons like the sniper rifle could have no leading, as you might expect.
Quote:
Originally Posted by n00b1n8R
Can you post a video of this in action? I could see it being useful for ranged engagements but it sounds like it would make pistol strafing and close quarters stuff really confusing.
I am not sure why you would think this (hopefully that doesn't sound too patronising!). I find it particularly effective for close quarters stuff, as judging the player's velocity (without the tool) is much harder when you are right next to them!..spinning round etc.
I would have liked to have provided better footage, but even this took a long time to capture and upload. I have amazing ping for the first and third segments, but the middle segment I have about 100 I think. Sorry for the poor gameplay/skill. As hinted before, I have not got the prediction amount/formula correct so I manually adjust it during gameplay. For example, when shooting the guy in the warthog, I would be getting an instant kill if I had the prediction amount correct (from experience).
As I said before, the prediction can be incorrect if players change direction. This would NOT be the case if this correction was done server-side (as it would not be a prediction) - this is what I am proposing. (EDIT: The server would remember the history of positions of player hitboxes and they would "lag" behind at the server. Players could then shoot at players on their screen and when the message reaches the server, the lagged hitboxes should be in the position so that the shot hits. This is a simplified explanation, as the lagged position of the hitboxes differs depending on who made the shot - it is their ping that decides how much to lag the hitboxes. 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.) The main source of error would be inconsistent latency or not being able to get an accurate enough measurement of latency (from client to server).
Quote:
Originally Posted by sanni
I rather would be interested in Halo CE with Halo PC netcode.
Why wouldn't you just play Halo PC? (I can't remember the disadvantages - can't most Halo CE features be added to Halo PC?). What are the main noticeable differences (problems) in the netcode? I did happen to notice (in Halo CE) the variables "use_new_vehicle_update_scheme" and "use_super_remote_players_action_update", which are set to true. These can be set to false by patching your server to enable devmode. I have no idea if this would make it more Halo PC-like.
September 29th, 2011, 04:44 PM
Kornman00
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by sanni
I rather would be interested in Halo CE with Halo PC netcode.
Custom Edition uses the same networking code as PC.
September 29th, 2011, 04:51 PM
urbanyoung
Re: Anti-latency (server-side hit detection / correction)
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.
September 29th, 2011, 05:49 PM
flyingmonkey3
Re: Anti-latency (server-side hit detection / correction)
I'm a little confused about what this does exactly. Does it change where players are drawn or does it change their actual positions based on ping?
September 29th, 2011, 09:41 PM
Mator
Re: 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
September 29th, 2011, 09:48 PM
n00b1n8R
Re: Anti-latency (server-side hit detection / correction)
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.
September 29th, 2011, 10:31 PM
jcap
Re: Anti-latency (server-side hit detection / correction)
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.
September 29th, 2011, 11:52 PM
flyingmonkey3
Re: Anti-latency (server-side hit detection / correction)
Ah so instead of moving the visual of the player forward, it sort of delays the hitbox?
September 30th, 2011, 01:04 AM
t3h m00kz
Re: Anti-latency (server-side hit detection / correction)
Fuck yes.
Why the fuck wasn't this done years ago?
Can we expect a release soon?
September 30th, 2011, 01:20 AM
supersniper
Re: Anti-latency (server-side hit detection / correction)
seriously this is amazing
September 30th, 2011, 03:18 AM
sanni
Re: Anti-latency (server-side hit detection / correction)
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.
September 30th, 2011, 03:44 AM
PaulusT
Re: Anti-latency (server-side hit detection / correction)
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?
September 30th, 2011, 05:30 AM
Sean Aero
Re: Anti-latency (server-side hit detection / correction)
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.
Re: Anti-latency (server-side hit detection / correction)
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.
September 30th, 2011, 10:55 AM
PaulusT
Re: Anti-latency (server-side hit detection / correction)
I was sort of assuming that we could find a function F that is called to perform a collision test for an object. Intercept calls to F; if the object is owned by some player, modify player positions before calling the original F and then set them back once original F has completed. Thus, there is no need to understand much about the collision system. The challenge is mainly finding F, although this may not be challenging really (for someone who has reverse-engineering experience). The problem is, this assumes that the collision tests simply read and make use of player positions, but there might be a separate pass that computes collision info, which is then used for collision testing. (E.g. I believe collision code in most games partitions the world so that only collisions between objects in the same or neighbouring partitions need to be checked.) Therefore, changing the player positions would not have any effect, as the collision info has already been calculated (or, it may give unexpected results). But this is all just pointless speculation really...
September 30th, 2011, 04:12 PM
t3h m00kz
Re: Anti-latency (server-side hit detection / correction)
So, reading this more in-depth, it sounds like you're planning for a server add-on type deal, similar to whatever DG uses for the Zombies server, as opposed to a program running along side the client. I really like this idea, and if it comes through I hope a bunch of servers pick this up. This will have fixed THE PROBLEM with CE, and may provide a more enjoyable experience for new users. The game will feel like it should feel. I just hope this project actually reaches completion, this should have been implemented a long time ago, back in the prime of CE.
Safe to assume the client-side correction you're showing in that video won't be released, as it would be more of a cheat than anything.
Also... how well do grenades work? I have to ask, because they lag behind based on ping by default.
If you need someone to help you test this stuff, let me know. I'm enthusiastic about seeing improved networking in this game.
September 30th, 2011, 04:15 PM
flyingmonkey3
Re: Anti-latency (server-side hit detection / correction)
Perhaps instead of only modifying player positions you modify the positions of all moving objects?
September 30th, 2011, 04:28 PM
supersniper
Re: Anti-latency (server-side hit detection / correction)
the only problem with grenades is the whole stick issue with plasmas...
September 30th, 2011, 05:06 PM
Pooky
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by t3h m00kz
Also... how well do grenades work? I have to ask, because they lag behind based on ping by default.
The thing most people don't get is that EVERYTHING is affected by ping. That includes melee, grenade sticks, vehicle splatters, everything. You should be leading every action you do, not just pistol bullets.
September 30th, 2011, 05:44 PM
Kornman00
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by seanaero
improved network code (reduces the incidence of player "warping")
It's still running the same networking layer found in HPC. The only real difference is the introduction of two new message-packets (super_remote_players_action_update and super_ping_update IIRC) and whatever logic that follows for them. However, it is still the same underlying networking code.
September 30th, 2011, 05:52 PM
t3h m00kz
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by Pooky
The thing most people don't get is that EVERYTHING is affected by ping. That includes melee, grenade sticks, vehicle splatters, everything. You should be leading every action you do, not just pistol bullets.
I know. The difference being you actually SEE the lag with the grenades, not the other attacks, which is why I ask, because there's an inconsistency.
September 30th, 2011, 09:06 PM
supersniper
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by Pooky
The thing most people don't get is that EVERYTHING is affected by ping. That includes melee, grenade sticks, vehicle splatters, everything. You should be leading every action you do, not just pistol bullets.
he is right, the hardest thing for me to lead are grenade sticks I still can't get that down.
September 30th, 2011, 09:28 PM
t3h m00kz
Re: Anti-latency (server-side hit detection / correction)
The amount you would have to lead the grenades wouldn't change if they visually lagged or not. They act just like everything else, save for the visuals.
In fact, you can trigger visual lag in the other weapons by ticking "Projectile is client-side only" in the weapon tags, which give you a server-side visual of the projectiles, IE you shoot, and the projectiles appear when the server detects them as opposed to instantaneously, similar to Unreal Tournament or Gears of War. The grenades act like this, though there are a few differences in how they act as far as effects go.
The Snow Grove shotgun has this lag.
September 30th, 2011, 09:57 PM
flyingmonkey3
Re: Anti-latency (server-side hit detection / correction)
I may be wrong but doesn't checking "projectile is client-side only" just make it so that only one projectile appears for clients while unchecking it causes 2 projectiles to appear, one being the "client projectile" which is usually drawn and the other being the "actual server projectile"?
September 30th, 2011, 10:20 PM
t3h m00kz
Re: Anti-latency (server-side hit detection / correction)
No.
Only one projectile appears in either case. It's a "Show Projectile Lag" off/on switch, basically.
Just remembering, another example or this in action would be the fire arrow in Hyrule Field. The problem with this option being, explosions and effects of that sort don't appear on your screen.
September 30th, 2011, 11:09 PM
flyingmonkey3
Re: Anti-latency (server-side hit detection / correction)
I just checked and it seems to behave as I described. By default the needler has the flag checked. When I uncheck it, I get the following. I DID NOT make the weapon fire 2 projectiles at once. The modified map is the map the server runs, not the map the client has. http://www.xfire.com/video/4e5c6b/
Note that when the projectiles hit the wall only one of them leaves a decal, leading me to believe that one is the "real" projectile according to the server while the other is the projectile that players normally see.
Or perhaps the problem is that I did this on PC and not CE?
E:
I did some more testing and here's what I found: Same procedure as before. "Projectile is client-side only" unchecked. Server runs modded map. Client has default map. This time I also changed the projectile the needler references to the sniper bullet. http://www.xfire.com/video/4e5c81/
With the projectile swapped and "projectile is client-side only" checked as it is in the default map, you would only see a needle being fired. With the projectile swapped and "projectile is client-side only" unchecked as seen in the video, you get both the sniper bullet, the "real server projectile" and the needle, the "fake client projectile".
This leads me to believe that the "projectile is client-side only" flag does exactly what it says. When checked, it causes the client to only see the "fake client projectile". You can test this by joining a game and using the needler. Sometimes the needles appear to miss an enemy yet you still hit him and vice versa, hence the "fake".
When the flag is unchecked, the client sees a "real server projectile" in addition to the "fake client projectile". In the case of the modded map in the video, the "real projectile" would be the sniper bullet as the needler has had its projectile reference swapped for the sniper bullet. Notice how when the sniper bullet misses but the needler hits, the enemy takes no damage. On the contrary when the sniper bullet hits, whether or not the needle also hits, the enemy does take damage.
September 30th, 2011, 11:33 PM
t3h m00kz
Re: Anti-latency (server-side hit detection / correction)
uhm, I've never seen that on CE. I did the UT2k4 maps, and a ton of the weapons had that option checked, and there definitely weren't two projectiles when those weapons fired.
Here's a video someone made of the mod.. it's hard to see, but it's noticeable when he fires the flak cannon, link gun and minigun that there's definitely not a client-side projectile.
Re: Anti-latency (server-side hit detection / correction)
In conclusion the flag has different effects in PC and CE then?
E: To clarify, when the flag IS checked, there is always only 1 projectile. When it IS NOT checked, there can be 2.
E2: Sorry to sort of hijack the thread, but I would like this to be clarified.
October 1st, 2011, 09:16 PM
t3h m00kz
Re: Anti-latency (server-side hit detection / correction)
Don't know. Don't have PC installed and I can't check on it. It looks like the client is firing a needle and the server is firing a sniper round. Map mismatch maybe?
Either way, yeah we kind of hijacked the thread, but my concern about grenades remains.
October 2nd, 2011, 12:21 PM
PaulusT
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by t3h m00kz
Safe to assume the client-side correction you're showing in that video won't be released, as it would be more of a cheat than anything.
Also... how well do grenades work? I have to ask, because they lag behind based on ping by default.
Don't worry - I won't release it. I was considering it at one point though, as it is better than the many available aim bots (as in, less of a cheat - but still a cheat I guess).
In the client-side tool, grenades are "drawn" slightly further ahead, based on velocity and ping, as you might expect. It's not great, as they end up going through walls (as in the video) and generally warp. Sometimes, they appear to land on a ledge, but this was incorrect so they then warp to a different location and explode :( Colliding with other players is also bad (although, perhaps this was always bad). Vehicles are the worst, as they are also drawn ahead, even when the client is driving. This should be fixed really, but it doesn't bother me that much - I usually just disable the tool when I am driving. Of course, none of this is really important, as I won't release this tool and these problems wouldn't exist in the server-side idea. Grenades could theoretically be adjusted, such that, when they explode, all other players are moved back to their recent positions (from the positions history). However, this might be a bit harsh! I think focusing only on bullets and player positions would be a good initial goal....although I think your point is a good one and worth testing if this gets off the ground.
Quote:
Originally Posted by flyingmonkey3
Perhaps instead of only modifying player positions you modify the positions of all moving objects?
This would be the best plan, but, as an initial goal (and when giving examples), I thought I would focus on player positions only.
October 2nd, 2011, 01:27 PM
Pooky
Re: Anti-latency (server-side hit detection / correction)
Sounds pretty similar to just using cl_timenudge in any quake 3 engine game, and I've never heard anyone call that a cheat. The only difference between leading and shooting at a 'predicted' client for an experienced player is that in the former you're using your own judgement, which is more reliable than any computer prediction anyway.
October 2nd, 2011, 02:54 PM
t3h m00kz
Re: Anti-latency (server-side hit detection / correction)
I'd say it would potentially be safe to post it here if you want, as we're not really as much of a community of cheaters as much as a community of modders. I would be lying if I said I didn't want to see this in action first hand. Not having to lead is something I've been wanting to experience for years.
I'd actually be fine with the client side hack being released. It'd be just another tool to enhance the game, similar to yelo or third person hacks. Ultimately its up to you, its not a tool designed to cheat with, and it enhances the game in ways.
Quote:
Originally Posted by Pooky
Sounds pretty similar to just using cl_timenudge in any quake 3 engine game, and I've never heard anyone call that a cheat. The only difference between leading and shooting at a 'predicted' client for an experienced player is that in the former you're using your own judgement, which is more reliable than any computer prediction anyway.
So... you're saying this would not be advantageous in any way.
That's rediculous. If this gets released to the general community, players who don't know what leading is will suddenly be getting more kills. The tiny few skilled people may not get much of an advantage boost, but you're not thinking about the rest of the people who play this.
October 2nd, 2011, 04:16 PM
JackalStomper
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by t3h m00kz
The tiny few skilled people may not get much of an advantage boost, but you're not thinking about the rest of the people who play this.
Most of the players you're talking about can't even read this thread.
Or afford a legitimate copy of halo.
And are already cheating anyway.
October 2nd, 2011, 04:58 PM
Pooky
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by t3h m00kz
That's rediculous. If this gets released to the general community, players who don't know what leading is will suddenly be getting more kills. The tiny few skilled people may not get much of an advantage boost, but you're not thinking about the rest of the people who play this.
That's retarded. All something like this could conceivably do is make the game more playable for people who don't understand the concept of leading. Ping is still fully in effect, so it wouldn't offer an advantage in any way except giving you a (buggy) visual indicator of leading which any skilled player can do anyway.
see again: cl_timenudge
October 2nd, 2011, 05:06 PM
t3h m00kz
Re: Anti-latency (server-side hit detection / correction)
Whatever
October 2nd, 2011, 10:36 PM
TPBlinD
Re: Anti-latency (server-side hit detection / correction)
People who don't understand leading shouldn't be playing anyway.. lol
October 2nd, 2011, 10:50 PM
t3h m00kz
Re: Anti-latency (server-side hit detection / correction)
>if s omeone sucks at a game they shouldn't play
That's what I'm hearing. Fantastic sportsmanship and logic! You ought to be proud.
October 2nd, 2011, 11:02 PM
Pooky
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by TPBlinD
People who don't understand leading shouldn't be playing anyway.. lol
:ugh:
Yeah fuck 90% of Halo PC/CE players as well as any potential new players because they don't know about a completely undocumented aspect of the game. That makes so much sense!
October 3rd, 2011, 10:07 AM
TPBlinD
Re: Anti-latency (server-side hit detection / correction)
This game is like 7 years old, if they don't know how to play the game how it was made then realistically they shouldn't keep trying... lol. Pretty sure most people understand lead now they just blow dick at it.
There aren't going to be any new players that aren't pirating it (mexican). Who gives a fuck?
October 3rd, 2011, 11:03 AM
Donut
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by TPBlinD
if they don't know how to play the game how it was made then realistically they shouldn't keep trying
i singled this part of your post out in hopes that youd re-read it and see how ridiculous that is.
people dont know how to do something -> stop trying. by that logic, none of us should be here. at all.
E: and dont give me that "the game is 7 years old" thing. i started playing in 2006, and i know people who play on and off that still arnt very good with leading. im mediocre at best.
October 3rd, 2011, 12:09 PM
flyingmonkey3
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by TPBlinD
if they don't know how to play the game how it was made then realistically they shouldn't keep trying
In other words: If at first you don't succeed, give up. Sounds like quality advice.
October 3rd, 2011, 12:19 PM
Cortexian
Re: Anti-latency (server-side hit detection / correction)
There's a difference between being a typical pirate/mexican that literally just cannot wrap their head around the concept of leading, and a normal person who will actually catch on and improve.
There are literally a few players I know that have been the same level of terrible for 3+ years at least.
October 3rd, 2011, 02:58 PM
TPBlinD
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by Donut
i singled this part of your post out in hopes that youd re-read it and see how ridiculous that is.
people dont know how to do something -> stop trying. by that logic, none of us should be here. at all.
E: and dont give me that "the game is 7 years old" thing. i started playing in 2006, and i know people who play on and off that still arnt very good with leading. im mediocre at best.
Really lol.
Seeing as how thats totally what I said bro. Leading is part of the game, if you can't wrap your head around a key game mechanic in a dead game then what are you trying to prove?
Some people are just naturally terrible at video games, and while the leading is gimmicky as fuck it makes the gameplay very unique. I like it, others do too.
It doesn't really matter though, I'm amazing at the game either way B)
October 3rd, 2011, 02:59 PM
TPBlinD
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by flyingmonkey3
In other words: If at first you don't succeed, give up. Sounds like quality advice.
Yup. I live my life on the principles around my feelings towards Halo: Custom Edition. I have the wisdom of a wizard.
October 3rd, 2011, 03:20 PM
Donut
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by TPBlinD
Really lol.
Seeing as how thats totally what I said bro.
uh, yeah:
Quote:
Originally Posted by TPBlinD
People who don't understand leading shouldn't be playing anyway.. lol
Quote:
Originally Posted by TPBlinD
This game is like 7 years old, if they don't know how to play the game how it was made then realistically they shouldn't keep trying... lol. Pretty sure most people understand lead now they just blow dick at it.
Quote:
Originally Posted by TPBlinD
Leading is part of the game, if you can't wrap your head around a key game mechanic in a dead game then what are you trying to prove?
i dont even know what else to say at this point. pooky pretty much hit the nail on the head: :ugh:
E: what the fuck, you just answered your own question and proved my point:
Quote:
Originally Posted by TPBlinD
Some people are just naturally terrible at video games, and while the leading is gimmicky as fuck it makes the gameplay very unique. I like it, others do too.
October 3rd, 2011, 04:06 PM
TPBlinD
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by Donut
uh, yeah:
i dont even know what else to say at this point. pooky pretty much hit the nail on the head: :ugh:
E: what the fuck, you just answered your own question and proved my point:
wat.
i said people who can't understand leading shouldn't be playing
theres always cod.
October 3rd, 2011, 04:51 PM
t3h m00kz
Re: Anti-latency (server-side hit detection / correction)
>people shouldn't be allowed to play what they want to play if they suck at it!!!
I totally agree bro. Let's build up concentration camps and keep these fuckers out of the game.
October 3rd, 2011, 05:21 PM
Donut
Re: Anti-latency (server-side hit detection / correction)
im gonna take one more stab at this: you said people who dont understand leading shouldnt play this game. that in itself is stupid since there are trick servers and maps like coldsnap. i dont play them but other people do. then you said this game has a unique feel to it. you like it and so do other people. so people might not completely understand leading, but its not like they have no right to play because of that.
by the way, how do you think most people figured out you have to lead shots? it never even occurred to me until somebody told me.
October 3rd, 2011, 06:31 PM
p0lar_bear
Re: Anti-latency (server-side hit detection / correction)
I think blind is talking about idiots that act like compensating for latency is game-breaking and impossible to do, and not necessarily people who get it but just have issues pulling it off. But he could have worded that so much better.
Personally, I'd like to think that this would help me so much for sniping, but after playing other games I find that I'm just horrible at hitting a target. Leading in Halo actually helps me out because I'm always a little too early or too late. %-)
October 3rd, 2011, 07:19 PM
Pooky
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by TPBlinD
Some people are just naturally terrible at video games, and while the leading is gimmicky as fuck it makes the gameplay very unique. I like it, others do too.
I agree that leading adds more to the game that it takes away, but I think it should be more consistent for all players. That said, I gotta point out that leading is not at all unique to Halo. Lots of other games have it, including all games based on the Quake 3 engine (though usually not as bad as Halo).
At any rate, a client side app to make leading more straightforward is no more a cheat than having a targeting reticule. In both cases it's just taking something you have to do anyway (aim) and removing some of the bullshit from the equation.
October 3rd, 2011, 07:20 PM
supersniper
Re: Anti-latency (server-side hit detection / correction)
way to fucken threadjack this thread...
October 3rd, 2011, 07:31 PM
Kornman00
Re: Anti-latency (server-side hit detection / correction)
if only candle jack were he-
October 3rd, 2011, 08:07 PM
t3h m00kz
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by Pooky
leading is not at all unique to Halo. Lots of other games have it, including all games based on the Quake 3 engine
Except for Quake 3.
October 3rd, 2011, 10:15 PM
n00b1n8R
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by t3h m00kz
Except for Quake 3.
Yeah nah, go play quake live and delete that post.
October 3rd, 2011, 10:18 PM
El Lobo
Re: Anti-latency (server-side hit detection / correction)
Love the leading.
:lobo:
October 3rd, 2011, 10:26 PM
Pooky
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by n00b1n8R
Yeah nah, go play quake live and delete that post.
This. Hell, go play instagib on any non Unlagged server.
October 3rd, 2011, 10:26 PM
t3h m00kz
Re: Anti-latency (server-side hit detection / correction)
I've never had to lead in Quake Live instagib.
Unreal on the other hand,
October 3rd, 2011, 10:27 PM
Pooky
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by Pooky
I agree that leading adds more to the game that it takes away, but I think it should be more consistent for all players. That said, I gotta point out that leading is not at all unique to Halo. Lots of other games have it, including all games based on the Quake 3 engine (though usually not as bad as Halo).
Quote:
Originally Posted by Pooky
This. Hell, go play instagib on any non Unlagged server.
Quote:
Originally Posted by t3h m00kz
I've never had to lead in Quake Live instagib.
Unreal on the other hand,
GG no read. Unlagged is automatically applied to Quake Live iirc, which makes the leading quite a bit less prominent than in vanilla but it's still there. Best noticed on really high pings.
Quote:
The solution Unlagged can provide
Unlagged is a server-side technique. A normal server only stores the current positions of all players. So the server forget where the enemy was when you shot at him.
In Unlagged the positions of all players are stored over a short period of time on the server.
When the server now receives your packet with the information that you shot at your enemy it can calculate, based on the knowlege about your ping, the position of your enemy back to the position where he stands when you fired at him. It can now see that you really hit him at the time when you pressed the fire-button and can give the enemy the damage he would get when you played with ping 0.
Is Unlagged the right solution?
The biggest problem nowadays is the ping that often does not allow fair games. Unlagged is a really good solution for people with low and high ping (altough it cannot compensate extremly high pings). But the player with the better ping will still have slightly better chances in a fight, because the packet that he wants to attack reaches the server earlier than the one from the high ping player.
Unlagged cannot reduce the real ping to 0 and it will never be possible to really simulate a ping 0, but it is the way to go. It allows games between people with different pings and the game will be fair enough because everyone has the chance to hit where he actually fired.
With Unlagged you have a chance to win against an equally skilled player. You won't lose only because it's to hard to hit your enemy.
Re: Anti-latency (server-side hit detection / correction)
gg no read, more like gg I've never played vanilla Q3, and I've heard Live is a copy/paste and therefore it's easy to make assumptions.
October 3rd, 2011, 10:56 PM
Pooky
Re: Anti-latency (server-side hit detection / correction)
It's pretty similar, but I wouldn't call it a copy paste. There are a lot of assorted small changes. But that's beside the point. The fact is that as long as there's ping, there's always going to be some degree of leading on any game that uses server-side hit detection like Halo.
October 3rd, 2011, 11:18 PM
TPBlinD
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by t3h m00kz
>people shouldn't be allowed to play what they want to play if they suck at it!!!
I totally agree bro. Let's build up concentration camps and keep these fuckers out of the game.
lol
Quote:
Originally Posted by Donut
by the way, how do you think most people figured out you have to lead shots? it never even occurred to me until somebody told me.
then you're dumb.
shots aren't hitting? welp find out where the sweet spot is and learn 2 play
the game is built the way it is. i mean modding the game is cool and all but i have no mods or anything when i'm playing and its still fun as fuck after all these years
easiest fucking game too.
e: LOVE THE LOBO
October 3rd, 2011, 11:47 PM
Donut
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by TPBlinD
then you're dumb.
shots aren't hitting? welp find out where the sweet spot is and learn 2 play
i typed up a paragraph response with some points outlined, stared at it for a few minutes, then i deleted it when realized nothing is going to change your mind when youre sporting an attitude like "all bad people gtfo".
E: also done crapping up this thread.
October 3rd, 2011, 11:56 PM
n00b1n8R
Re: Anti-latency (server-side hit detection / correction)
I'd just like to add that I quoted the wrong post and I've never had to consciously lead in quake live.
October 4th, 2011, 12:04 AM
t3h m00kz
Re: Anti-latency (server-side hit detection / correction)
damn it noobinator!!
October 4th, 2011, 02:16 AM
urbanyoung
Re: Anti-latency (server-side hit detection / correction)
This thread would've made for an interesting discussion, too bad you two suck and raped the thread.....
October 4th, 2011, 03:52 AM
t3h m00kz
Re: Anti-latency (server-side hit detection / correction)
Sucking and raping is what I do.
October 4th, 2011, 05:13 AM
Pooky
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by n00b1n8R
I'd just like to add that I quoted the wrong post and I've never had to consciously lead in quake live.
Go play it with 800 ping.
Of course you haven't fucking noticed it, that's why Quake Live has that matchmaking thing to give you servers close by with people on a similar skill level. Also notice how I said the leading in other games isn't usually as extreme as in Halo. Even Unlagged isn't a perfect solution, because it often results in people getting shot after they already ran around a corner.
October 4th, 2011, 05:26 AM
t3h m00kz
Re: Anti-latency (server-side hit detection / correction)
The most least bullshit game I've ever played network-wise is... ironically, Sauerbraten, which is free and open source, and which I play periodically to this day.
Why is it the least bullshit? Because if you shoot someone, and it hits them, it fucking hits them. Immediately, the game recognizes damage needs to be sent to them. No latency bullshit. The only thing that may happen is they kill you before the damage is sent to them... which is fucking fair. COD3 had similar networking, before Treyarch moved over to whatever the fuck COD4 used. Why they changed it up is beyond me. I fucking hate getting jipped out of a kill because I died before my damage lands ALA Halo 2/3 and every COD game to this day.
Funny how the most popular industry standard games can have absolutely horrid networking and damage registration. I don't know what the fuck they're thinking.
E: Jesus christ, I seem to love the word fuck.
October 4th, 2011, 05:57 AM
urbanyoung
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by t3h m00kz
The most least bullshit game I've ever played network-wise is... ironically, Sauerbraten, which is free and open source, and which I play periodically to this day.
Why is it the least bullshit? Because if you shoot someone, and it hits them, it fucking hits them. Immediately, the game recognizes damage needs to be sent to them. No latency bullshit. The only thing that may happen is they kill you before the damage is sent to them... which is fucking fair. COD3 had similar networking, before Treyarch moved over to whatever the fuck COD4 used. Why they changed it up is beyond me. I fucking hate getting jipped out of a kill because I died before my damage lands ALA Halo 2/3 and every COD game to this day.
Funny how the most popular industry standard games can have absolutely horrid networking and damage registration. I don't know what the fuck they're thinking.
E: Jesus christ, I seem to love the word fuck.
Games don't work like that because that design is retarded. That design, as you describe it, trusts the client. You cannot do this. If the server trusts the client to notify it of damage then it can be exploited. All you need to do is either break the packet security and inject a "hit" packet, or make the client do it for you with a few function calls. You would be able to "shoot" people without even looking at them. The way modern games detect hits is really as good as you can get.
October 4th, 2011, 01:37 PM
t3h m00kz
Re: Anti-latency (server-side hit detection / correction)
Easily hackable, yes, but Client/Server can still be quite hackable. IE Halo 2. Ironically I've never seen nearly as many hackers in Sauerbraten, save for some people creating an AI controllable via console commands in a server. Even with CE, you've got aimbots and wallhacks.
With console games, I'd imagine you'd have to worry about hackers much less than PC titles, and therefore it baffles me why consoles don't take advantage of trusting the clients more. There's a fraction of the amount of hackers as there are on the PC versions.
October 4th, 2011, 07:06 PM
Pooky
Re: Anti-latency (server-side hit detection / correction)
Well, the good thing about the Server/Client model is that a good amount of hacks like speedhacks etc. are not possible because all players are controlled by the server. Halo 2/3/Reach do not use this system, instead they trust the clients. I used to have a whole gallery of screenshots of people getting lasered straight through walls because of this.
October 4th, 2011, 07:46 PM
t3h m00kz
Re: Anti-latency (server-side hit detection / correction)
Halo 2/3 very much uses client/server. The hit detection is just more advanced. In Halo 2 you cannot hit people with BR shots unless you have the red reticule. Even if the projectiles connect on your screen (I've tested this with video, slowed it down, seen cases where bullets connect with no damage delt). At long distances, ALA Coag, in order to hit, you have to lead. Halo 3 uses a more advanced version not reliant on the red reticule, and you will see cases where the bullet spread will cause the bullets to zip past the enemy's head, but the server will register a headshot. I'm not sure about Reach.
I used to have a video showing tons of shots in Halo 2 that didn't hit. Lost it, apparently.
October 4th, 2011, 07:50 PM
Pooky
Re: Anti-latency (server-side hit detection / correction)
Point taken on Halo 2, I'd almost forgotten about this video.
That said, I still ran into an obnoxious amount of situations in Halo 3 involving people getting lasered or sniped through walls... guess the netcode ain't all that advanced. Personally I prefer Halo 1's system, at least the leading was predictable.
Re: Anti-latency (server-side hit detection / correction)
I experimented and found out that that's caused by bullet redirection on the killed player's screen. The game redirects the killer's bullet to the appropriate location on the killed player's body. Notice how YOU never kill anybody through walls on your screen.
The result? You see their shots shoot off in a direction they actually didn't in order to make it look like they're shooting you.
Have player 1 aim at a corner. Have player 2 run around corner, have player 1 shoot player 2 just before player 2 is in cover. Player 2 will die from a shot that, on his screen, hit the corner due to the redirection.
So yes, it is a more advanced hit detection than Halo 1. More advanced does not mean it does not have flaws.
I had a screenshot of severe redirection in my Halo 3 files, I'll have to post it sometime..
October 4th, 2011, 08:02 PM
Pooky
Re: Anti-latency (server-side hit detection / correction)
Still prefer predictability over some of the wacky bullshit that happened on Halo 3 vOv
Also dedicated servers ftfw. Host advantage was huge in Halo 2 and still pretty annoying in 3 and Reach.
October 4th, 2011, 08:31 PM
p0lar_bear
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by t3h m00kz
I had a screenshot of severe redirection in my Halo 3 files, I'll have to post it sometime..
Besides the awesome instance of lag where Trevor got sniped by a cloud?
I digress, it happened to me all too often with the sniper in H3. I vividly remember once taking a video of me headshotting someone three times on Valhalla with it and it didn't do a damn thing to him.
October 4th, 2011, 08:38 PM
t3h m00kz
Re: Anti-latency (server-side hit detection / correction)
Lag? Or KARMA?
In trevor's case
October 6th, 2011, 04:20 PM
Mator
Re: Anti-latency (server-side hit detection / correction)
Netcode is an ongoing issue. They are constantly trying new things. Some things work, some don't. :|
October 7th, 2011, 06:38 PM
t3h m00kz
Re: Anti-latency (server-side hit detection / correction)
Any updates for us paulus? I'm really looking forward to this
October 7th, 2011, 09:36 PM
jcap
Re: Anti-latency (server-side hit detection / correction)
I think he was trying to see if anyone else would be interested in picking it up
October 7th, 2011, 10:53 PM
t3h m00kz
Re: Anti-latency (server-side hit detection / correction)
fuckballs
Well, if nobody does I'd say release it as it is now, otherwise it'll be one of those gems that gets locked away forever doing nothing but collecting virtual dust.
October 8th, 2011, 01:24 AM
justin108
Re: Anti-latency (server-side hit detection / correction)
After reading this whole thread and having played this game since it came out, I have become used to the leading, it adds an aspect that I do not get anywhere else. Although I no longer play, the lead was one thing that kept me interested. I like the fact this game has a learning curve, when I first started I went negative every time. Even after not playing for a year, it would be hard to go negative now. I can only speak for myself here, but the "lead" and learning the difference in 33 vs 133 ping (or higher) is the difference of good or baddie. It took me years to figure it out (slow learner). Now I know how to lead shots, and I think of it as "bending" bullets (ex. "Wanted" style). So why change a game we have all come to love not despite the quirks but because of them? I wish I had time to play now, but I only randomly get to read the forums when I have a sitter or my kid is asleep, and I am not working on my own blog. I am shocked Korn and Jcap are still able to spend time on here, I am sure they lead busy lifestyles also. While I do find your help useful, ultimately I feel it is ages too late. HCEL certainly could have benefited from this if implemented server side. This is only my opinion, so take it for less than a grain of salt. As the forum reads it seems many want it.
October 8th, 2011, 02:42 AM
Patrickssj6
Re: Anti-latency (server-side hit detection / correction)
You are not by any chance the Paulus who made the sheep/freeze trainer? :P
October 10th, 2011, 05:11 PM
PaulusT
Re: Anti-latency (server-side hit detection / correction)
Quote:
Originally Posted by Patrickssj6
You are not by any chance the Paulus who made the sheep/freeze trainer? :P
Yes I am :) That was actually rather simple though :( The time freeze was taken from Sheep's trainer. I also made a trainer for Halo 2 that was more impressive from a technical point of view (not just poking values into memory), but still fairly basic (and I don't think it worked too well unless you found a DLL loader). I cannot even begin to imagine how some people are able to reverse engineer so well.
As for an update, I was indeed suggesting that someone else could attempt this, as I am going to be pretty busy for a while. I did have a quick attempt at finding potential functions to intercept; I believe (if I recall correctly) for the time-freeze hack (Halo 1 and 2), there are several functions that are called for every object in the game that needs updating. One of these was intercepted and changed to a no-op for all objects except the player. This made all objects freeze, except for the player. I believe it might be possible to intercept this function so that we check if the object to be updated belongs to a player and if so, move other objects (such as players) back appropriately. Then, move objects to their original position when the function returns.
I only did this very quickly, so I didn't even check if this is definitely the right function but:
Given Halo CE v1.09, with base address=0x00400000
0x0045C3A8 CALL haloce.004F8B20
Within the function, we reach:
0x004FBB80 PUSH ECX
I think at this point, the address of the object being updated is in a register (I can't check which one right now). Or, this may just be some other object address that is calculated, but the correct address should be calculated somewhere in the function.
I may get some time to look into this further, but if anyone is willing to contribute, it would be very much appreciated by most!
As for the arguments against fixing the lag:
It's too late: Fair enough, but I might quite like to have this for private matches with friends. Plus, people might consider this when Halo Anniversary multiplayer turns out to be nothing like the original (at least, I think that is confirmed to be the case).
Other: Halo 1 is not meant to have this lag. It was not meant to be played like this. The lag is essentially (almost) a bug, but one that the developers knew about and were never going to fix. The lag is inconsistent - players in the same server must usually lead different amounts and you must lead different amounts depending on the servers you play on. Consistent leading could be implemented on top of this fix (server-side), but it could be based on having slow bullets and could vary based on the weapon or other factors, which is probably preferable - having to lead in close-up battles makes no sense and is mostly luck!
October 12th, 2011, 04:31 PM
Skarma
Re: 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??)
October 12th, 2011, 10:36 PM
Kornman00
Re: Anti-latency (server-side hit detection / correction)
They're documented; see s_object_data's center/radius fields.
October 13th, 2011, 02:18 PM
Skarma
Re: Anti-latency (server-side hit detection / correction)
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
October 13th, 2011, 03:12 PM
PaulusT
Re: Anti-latency (server-side hit detection / correction)
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?
October 13th, 2011, 03:59 PM
Patrickssj6
Re: Anti-latency (server-side hit detection / correction)
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.
October 13th, 2011, 04:50 PM
Choking Victim
Re: Anti-latency (server-side hit detection / correction)
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.
October 13th, 2011, 05:00 PM
PaulusT
Re: Anti-latency (server-side hit detection / correction)
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.
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.
October 13th, 2011, 05:14 PM
Patrickssj6
Re: Anti-latency (server-side hit detection / correction)
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.
October 13th, 2011, 05:41 PM
Kornman00
Re: Anti-latency (server-side hit detection / correction)
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.
October 24th, 2011, 12:23 AM
Flare
Re: Anti-latency (server-side hit detection / correction)
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:
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.