Det har ju inget med hitboxar att göra. Utan enbart vilken form av nätkod. Antigen kör man Serverregistrering eller clientregistrering
som beräknar vad man träffar. Båda har för- och nackdelar. Bf3 har ju client med laggcompenstion. Personligen föredrar jag serverhanteringen.
Helt saxat från http://forums.tripwireinteractive.com/showthread.php?t=48004
"Method 1) Calculate hit effects on the client. With this method you get instant feedback on where your bullet would hit (with hitscan weapons). This is great but there is one major flaw - where you see your bullet hit on the client doesn't actually represent where your bullet hit on the server since they are both calculated independently. This was the system that was used in Americas Army 2.X (which I worked on). This system is exasperated by randomness or cone fire, since to simulate the shot on the client you have to simulate the randomness you would also have on the server. The problem is, since it is random the client and the server will have different locations where the bullet will go. This is why in AA2.X you would very often actually see puffs of blood coming off of an enemy that you were shooting, but in reality you didn't hit them at all. Your client side simulated shot had hit them, but your server shot had not.
Method 2) Display hit effects on the client in the proper place by sending the information from the server on where the "real" hit actually happened. The disadvantage of this system is that there is a slight delay between when your shot is replicated to the server and when the hit location is replicated back down to your client. The advantage of this system is that when you see a hit effect appear it actually appears where the real hit happened on the server. In other words, when you see that you blood puffs appearing on an enemy that you shot, you are ACTUALLY damaging them.
In the original RO and since then I have been using method 2. I find the slight delay until the hit effect appears is far outweighed by never getting "false positives" and knowing where my bullets actually hit. Combine this with a non-hitscan system with full bullet ballistics where even if you are playing a non-network game there is a slight delay between when you fire and when your bullet hits, then the delay when playing online is almost not noticeable with a ping < 100 ms.
Also, in your case where you say your ping is 60 ms, but there is a delay 0.3 to 0.5 seconds (300-500ms) either there has to be something wrong with your network, the network between you and the server, or the people coding that particular game. Because in the standard "Method 2" system above, with a 60ms ping it would be about 120ms (or .12 seconds) before you saw the hit effects. Most likely it is a problem with your network, your computer, or your perception of time.
Finally, there are the games with the so called "lag compensation". I've never been a fan of this so called lag compensation because of the side effects it causes. If you have ever been playing an online game and walked completely around a corner only to die when noone could possibly have shot you, it was likely do to lag compensation. With these systems the server stores a list of locations and where a player was at a particular time. Then when a player shoots on his client it sends the firing info and a timestamp to the server. So when the server receives this information it basically "rewinds" back to the point in time when the client fired and checks to see if the shot from some time in the past would hit the player back then. The problem with this system is, that depending upon players ping everyone playing the game has a different view of where the other players are at a particular time. This is why on your machine you could be behind a wall, but the player (who you may not even be able to see on your machine) who has a higher ping than you sees you where you were a short time ago and shoots and kills you. So this is why I think lag compensation sucks
I prefer the Unreal net code methodology which uses client side prediction instead of lag compensation. When a programmer knows what they are doing and uses the Unreal net code properly client side prediction gives all of the clients connected to a server a very very close picture of where the other players are actually at on the server at all times. It does this by predicting the physics and movement of the other players. It does this pretty good for super-fast games like UT, and when you slow this down to real world movement speeds like in Red Orchestra this system is rock solid. In other words, in RO when you shoot at someone you can pretty much guarantee they are at where you see them at (up to a ping of 200ms). Likewise when you get SHOT by someone on RO, it was because they could see where you are currently at, not where you WERE a short time ago. "
