Trust client side hits
Imbalanxd
Join Date: 2011-06-15 Member: 104581Members
Join Date: 2011-06-15 Member: 104581Members
<div class="IPBDescription">performance band aids</div>One thing above all else annoys me at the moment. I can deal with the jittery FPS, I've dealt with it in many other games before. I can deal with the rubber banding lag, as once again, I've experienced it before. One thing I cannot tolerate, however, is the server rejecting my client verified hits 50% of the time.
I do not understand the point of calculating client side hits just to light up a crosshair, when in most cases the server refutes the hit and doesn't follow through with it. This is obviously just some problem that I'm sure will be fixed down the line, but I see no point in having to subject ourselves to this irritation for the time being. As a make shift "solution", can the server not just trust that which is determined as a hit on the client side?
I know that, at release, this will not be viable due to potential cheating, but lets be honest, at the moment its built on open LUA. I could probably hack together a makeshift aimbot in a day. I don't think cheating is a big concern at the moment.
I do not understand the point of calculating client side hits just to light up a crosshair, when in most cases the server refutes the hit and doesn't follow through with it. This is obviously just some problem that I'm sure will be fixed down the line, but I see no point in having to subject ourselves to this irritation for the time being. As a make shift "solution", can the server not just trust that which is determined as a hit on the client side?
I know that, at release, this will not be viable due to potential cheating, but lets be honest, at the moment its built on open LUA. I could probably hack together a makeshift aimbot in a day. I don't think cheating is a big concern at the moment.
Comments
At least, that's how I understand it. I could be wrong; synchronized network code is complicated computer science.
At least, that's how I understand it. I could be wrong; synchronized network code is complicated computer science.<!--QuoteEnd--></div><!--QuoteEEnd-->
The client is already doing the hit checks, which is why the crosshair lights up essentially instantly. The server then checks it against its own internal version of the game world to see if the client is correct. Best case scenario, every client is trustworthy and the hits registered by the clients truly are hits. The only reason the server would then reject such claims is due to latency and jitter, which causes the prediction of the client to create a version of the game world inconsistent with that of the server's. So while the client did in fact shoot the target on his screen, the server is forced to refute it because its version of the game world is the final arbiter.
Real world scenario however, people will simply stream positive hit messages to the server, which is why in general the server must always check for itself.
Oh, and I'm not talking about prediction here. Prediction merely refers to the positioning of targets, not how positive hits are registered and conveyed.
Experienced two aim-boter's last night. The cheating has already commenced.
Real world scenario however, people will simply stream positive hit messages to the server, which is why in general the server must always check for itself.
Oh, and I'm not talking about prediction here. Prediction merely refers to the positioning of targets, not how positive hits are registered and conveyed.<!--QuoteEnd--></div><!--QuoteEEnd-->
I'm confused. I was wrong about how it works, but you're saying that the fix is the same, right? Without the client performing quickly enough, it makes inaccurate calculations.
And if prediction doesn't affect hitreg, am I not still talking about the same thing? I don't know, are there any good articles for understanding this? It's pretty interesting, and I would like to learn it correctly.
Those can come in late and don't need to be a lie obviously
It's a feature I've been requesting for a while now, but has largely been brushed aside I think
-
Red dot, blood spatter, and sound effects = Predicted
+Score, Animation wince or ragdoll = Registered
Prediction is there just to show the expected result of your actions immediately, while waiting for the server to read your net packet, compare it to everyone else's, and return an update of the result. If the client and server are having no bandwidth/latency/performance issues, the prediction will most likely be correct. If there's lag, low tick-rate, packet loss, or poor server performance, it can often be wrong. Shouldn't be difficult to understand why prediction isn't always right in NS2, knowing that.
And if prediction doesn't affect hitreg, am I not still talking about the same thing? I don't know, are there any good articles for understanding this? It's pretty interesting, and I would like to learn it correctly.<!--QuoteEnd--></div><!--QuoteEEnd-->
Well at the risk of Max or someone else coming in and finding 1000 errors of mine, I will level with you and say that I am not 100% informed on this stuff. I am formerly educated in the field thought not completely familiar with industry standards.
Anyway:
Many games like to have "on hit" indicators that tell you when you are firing in the correct location. I think battlefield did it first, and other games have started doing it as well. Additionally, things like blood splatters and pain noises (skulk grunts, marine moans ect) also rely on determining whether or not the target was hit. Sending the necessary information to the server, waiting for it to be processed, and then waiting for the server to return the outcome can take some time. If only this method was used to determine hits, it would create quite a jarring visual and audio discord. So instead, while the client waits for the server to determine positive hits for the purpose of damage, it calculates its own hits for hit indicators and blood splatters ect. The server can disagree with the client however, even after the client has determined a positive hit and implemented the required visual feedback. This is why you can shoot a skulk directly in the face wit a shotgun, witnessing the rain of green blood, and have it take absolutely no damage.
So the problem I am referring to is in the agreement between the client and the server. What I am proposing is that, instead of having the server do the hit detection a second time, let the client do it and just send the positive hit register back to the server. In other words, trust the client.
The client side prediction is what <b>causes</b> the disagreement between client and server, and is a lot more complicated. That is essentially where the problem lies I assume, and will probably be addressed in the future.
A bit off subject, but quake 2 had an audio on-hit indicator, I don't know if it was the first but its been around before battlefield.
Never trust the client. To accomplish the solution you're looking for, the server would have to rewind the game to trace the client's shots along with the servers version of the client's prediction. That may sound confusing, but basically I'm saying the server would have to do the exact prediction the client did to generate a true trusted result.
Of course the end result would be even more code running on the server, and possibly a big performance hit.
Of course the end result would be even more code running on the server, and possibly a big performance hit.<!--QuoteEnd--></div><!--QuoteEEnd-->
Ye, I meant eliminate all forms of hit registration not happening on the client. Would be kind of pointless to perform the exact same calculation with the exact same data at two different locations.
As player said, it was just a suggestion for a band aid fix. I don't think it would be a simple boolean change though, as the client packet would need to include extra data, and the structure is probably already set.
I'm also not sure how badly this affects people at the moment. I perfectly aware that sometimes bullets simply "miss" even when aiming directly at the target, but I don't know how often people have client/server disagreements on hits. I play with very high ping, so maybe that is the main factor. When my friend buys into the beta I will do some tests on what kind of movement gives the most frequent disagreements.
While hitreg has still some bugs, its much improved now. I actually dont know of a specific hitreg bug right now. I know that there is an issue somewhere, but nobody came up with a video or a way to reproduce a current hitreg problem yet.
I don't know if a video will be of much use, as it will just show what we already know; some bullets hit, some don't.
What I want to do is get a skulk to move around using various styles while I shoot at it with a pistol. Every time my client records a hit I can verify with the skulk player whether or not he actually took damage. I think anything less than around an 80% correlation between client and server can be said to be unacceptable. The main problem is that two people running around shooting each other is not the same as 20 people, but its a start at least.
if you play vs a high ping pkayer (or you yourself is one)
you'll notice the ability to shoot and kill a statioary skulk before he can even react
if i was 800 ping and the server tedted
my shots then the skulk with 100 ping should easily have been able to move from that location
but reality is they have moved but my shots still counted
Exactly. So, for the meantime, lets take the strain off the server and just do it client side. I think everyone will be happier with that solution for now, unless cheating becomes rampant.
Nothing. Lag compensation also does not fix this problem; there's no way to magically remove the latency without actually, physically removing the latency. The person who does the peeking has the advantage.
Lag compensation makes the inconsistency feel slightly worse. High latency players can hit you were you were several hundred milliseconds ago; that's the price of "rewinding time" on the server and checking if it looked like a hit on their screen.
You can't get rid of the latency, you can only move it around. WÃth hitscan weapons it's not so bad; sometimes you make it around a corner before you die and that feels a little dodgy, but most often the enemy player is far enough away that he's just aiming a few degrees wrong. Melee is the worst; it's hard to dodge something that runs around and bites you were you were several hundred milliseconds in the past, it can feel like the range on melee is much too long(hence feeling like you get devoured from 10 meters in NS if you quickly scoot past a high latency onos with a jetpack and he gets you).
If players have the same run speed you can end up with strange paradoxes. This happens often enough in PVK. You are running backwards; you see the enemy as they were in the past(way out of range). The enemy that is chasing after you sees you where you were in the past, which is much closer to him. So a player with a dinky little sword can reach you, but you simultaneously cannot reach him with a long spear.
Latency sucks and there is only one fair and consistent way to remove it without making trade-offs and that is to actually, physically remove latency. Better internet connections is hard; but you can make the server run faster and if a game gets more players, a good, populated server will on average be available closer to the player(this is actually a very large effect. If I look in the steam server browser for the original counter-strike I find at least a hundred servers _with players_ and a latency less than 10 ms. Now interpolation effectively adds some latency, but if the server tickrate is high you can get away with maybe 25-50 ms of interpolation instead of 100+ ms.)
Most visual indications of a hit(blood spurts, sparks etc.) are generated on the client. But the server still has final say over whether any actual hits were made.
The server has a record of its past transactions with the client and it has timestamps on packets sent by the client. It knows what packets the client has recieved(the client ACKs the packets) and when the client sent its packet to the server, so it can "rewind time" and reconstruct what the player saw when he fired a gun.
The server also has authority over your movement(except for view direction, typically); but the client predicts your movement so you don't notice any latency. For static geometry the server will pretty much infallibly generate the same result as the client. When you collide with another player there are problems. The server can't use the same trick and rewind time, because it needs to use a consistent view of the world, which is the latest position of players as seen by the server; but this is unknown to your client so there are lots of prediction errors. (hence why things get very jittery when you brush up against moving enemy players)