There is no reason lag compensation would take ballistics out of the game. What are you talking about?
Leading for ping is ridiculous, Mk.2: An Example
- Thread starter Mekhazzio
- Start date
- Status
There is no reason lag compensation would take ballistics out of the game. What are you talking about?
Only lag compensation that has been proposed here so far are having hit detection done on client side. Where did you get the idea that doing so would remove bullet drops/speed (because it doesn't)?
Last edited:
The only way I have seen games properly implement lag compensation is by means of hitscan, the basis of most of the games on the source engine. Even if ballistics were implemented the issues will still be over there being no "actual' location of two clients within the game server, unlike what there currently is now. Essentially there will be no objective reality on the server side. The net result is that people will be shot after there was the perception of cover and players will be dead however on their screen will still be firing a shot. Given what would happen if ballistics were somehow kept (with the client being in charge of deciding where the enemy is which will have no true bearing on where the enemy actually is) the "I was shot after I made it behind cover" is going to happen many, many times. I don't really see that solving too many issues but instead shifting them into new problems. Even if client side hit detection was to magically be implemented tomorrow there would still be lag issues with RO2.
So? The server's not playing. The humans in the game should have a little higher priority
It's a long thread, so I can understand the desire to skip to the end, but all those points have been covered. Ballistics can stay in, "dying behind cover" already exists in the current model (I even posted a video of it) so we wouldn't be getting anything new, and besides, can you argue with a straight face that it's worse than having the networking mess with every single shot ever made at a non-stationary target?
Yes, there'll still be lag, but having a shot simply be delayed is a lot less game-breaking than having it be both delayed and thrown off-target.
So? The server's not playing. The humans in the game should have a little higher priority
It's a long thread, so I can understand the desire to skip to the end, but all those points have been covered. Ballistics can stay in, "dying behind cover" already exists in the current model (I even posted a video of it) so we wouldn't be getting anything new, and besides, can you argue with a straight face that it's worse than having the networking mess with every single shot ever made at a non-stationary target?
Yes, there'll still be lag, but having a shot simply be delayed is a lot less game-breaking than having it be both delayed and thrown off-target.
I've read over the thread in its entirety. I know that the "issues" have been "addressed" however I don't view the answers as being sufficient. Problems are still going to exist if this system was adopted over night. At least with an objective server reality it will always be consistent. I don't think trading one set of problems for another is going to fix anything, especially with the type of lag and warping seen in game to the tune of actual packet loss. Perhaps I am incorrect.
If you read the thread then you shouldn't have worried about bullet ballistics (no idea where this came from) and warping (warping is caused by data loss, which is again irrelevant whether hit detection is server or client side). Battlefield 3 features client side hit detection but features functional ballistics (not that RO2 should be anything like BF3, that's not my point, I'm just bringing it up to show that it's technically possible). The warping was explained 5 posts above your first post...
The only valid concerns are 1) cover perception delay 2) easier to hack and 3) heavier CPU loads on client side.
Last edited:
Well, lets not forget that the majority of those complaining about latency issues either have agendas or are assuming that a client side hit detection scheme would be an instant cure for the 'lag' issues in overloaded servers and and instant cure for the hit detection issues some people claim they have constantly. Thats not to mention that most of the points addressing the latency issue are based upon the predication that high client pings are strictly network code induced. Its easy to pull the wool over the average jr fps gamer's eyes with a lot of techno talk. Not that any of it has been necessarily false, but much of it has nothing to do with the problems that are inducing the latency in RO2. (I'm still trying to figure out what that 'dieing behind cover' scene was all about. Smoke and mirrors I presume as it was in no way representative or indicative of what most are talking about.)
But hey, lets all keep harping on it like we know what we're talking about....
But hey, lets all keep harping on it like we know what we're talking about....
Last edited:
Ok, so the worst thing you can see in the game is something like in BF3, where the hitbox is client related, and you have "ping compensation" often dying even you have ran away 5 meters behind solid cover. For example, you are watching the small corridor on your ironsight/optics, and first you die, then you see enemy, then you hear the shooting.
Other thing, is that you clearly see enemy "healthbar" droping on the zero, but suddenly he survives, you die and his healhtbar jumps on the half.
example > EX3D 2SaiNt4U presents: SOME COOL NEW BF3 FEATURES - YouTube
take a look at the healthbar, and see the animation in which is he relaoding and shooting in the same time.
Other thing, is that you clearly see enemy "healthbar" droping on the zero, but suddenly he survives, you die and his healhtbar jumps on the half.
example > EX3D 2SaiNt4U presents: SOME COOL NEW BF3 FEATURES - YouTube
take a look at the healthbar, and see the animation in which is he relaoding and shooting in the same time.
Last edited:
...agendas? What, is this some sort of conspiracy now? What does that even mean?
I do not see anyone making that claim. Where are you getting that? The closest I can see is that a client-side model would reduce the load on the server to a degree, but the most that would do is push up the number of players a server can handle before being overloaded, and slightly better handling of shooting when it is overloaded, but nothing is going to stop people from hosting games with player-counts too high for the machine it runs on.
Of all the complaints of bad hit-detection I've seen, the vast majority are quite clearly an issue with the expected results being different from what ended up happening, due to the network delay. The target is moving, and where the shot was made is no longer where the target is some ~100ms later. Usually something like unloading on someone at close range that is moving to the side, and while it looks like every shot should hit, none do, because the shooter isn't leading by enough (A distance that can be over a meter ahead of the target at point-blank range).
The occasional other "hit-detection" complain tends to be either clipping geometry (Rare, as the game does a surprisingly good job of letting bullets pass where they should; a few train-car ladders and such in Station blocking bullets passing through what should be open space is the only example that comes to mind), or from not understanding the damage model of the game (Particularly the very low damage cap for foot/shin/hand/forearm), which can result in someone shooting a person many times for no noticeable result other than the puff of blood. For all the complaints of hit-detection bugs, I've never seen a clear-cut example of a shot that absolutely should have hit, considering all of the above, yet fails to connect. If there is a legitimate flaw in hit detection, it's lost behind the significant number of shots that miss due to the network delay to the point where it's questionable that it even exists.
Many people have complained that client-side hit-detection needs to be avoided because it will introduce that "dying behind cover" illusion. Many in this very thread. Many even after the video was posted showing that it happens with the current networking model, anyway, making it impossible for a client-side model to "introduce" it to the game. It's the same reason people are saying that a client-side model will introduce warping, or remove ballistics. It's because some people do not understand the details of the different networking models, but are perfectly willing to make wild speculations about it despite this.
...like this. "Dying behind cover" is already in RO2. Mind that the only way you'll ever get 5 meters behind impenetrable cover "before" dying is to have a total latency of over a second, while sprinting.
As for dying before you see the opponent come around the corner, that would only be possible if there's some significant packet-loss going on and causing such significant warping that the movement data is lost until after the shot data has fully resolved, which is fairly unlikely. It is also, again, a matter of data lost in transmission, not something caused by the networking model. Depending on how they transmit shot data, it can happen on a server-side model (Like RO2), too.
Since the server transmits movement and shooting information to you as it gets it, an un-choked connection would not only show the person moving out before shooting, but the timing of the other person's action would appear exactly the same whether it were a client-side or server-side model.
That means that DICE made the curious decision of having the client "predict" what damage it was going to deal on the client-side, rather than waiting for the server to confirm the damage, send back the confirmation, and then show the damage done. Basically it means the shot that killed you reached the server before your shots did, and since you were dead when your shots arrive at the server, it invalidates them; that information gets back to the client, and it cancels its predicted damage. Because of the networking delay, you see yourself making several shots, but the server decides they were invalid because you were dead. Essentially, you get the same thing now in RO2, where you can shoot a person square-on, but because his shot already killed you on the server it never lands.
Basically, this effect has nothing to do with the networking model, but instead has to do with the client predicting events. I'm generally against client prediction -- as a friend put it, it's essentially the game lying to you. In situations like this, it also makes it much less apparent as to what is actually going on in the game. A similar effect in RO2 would be introduced if you had the client decide when to show the blood-puffs produced by hits, rather than waiting for the server to confirm it. Many games do it this way, even. I imagine it would be a very bad thing in RO2 with its current network model; Shooting at a moving target, you'd get blood-puffs only when you're making shots that, due to the network delay, could not possibly hit, while the shots that do, produce no visible effect.
That's the long and short of it. You can have good network ping, which is visible on steam server browser yet still have 100ms actual ingame ping. The lousy single-threaded server code makes server lag worse together with the 64 or bust -attitude. At 100ms lag point blank lead would be half a meter with target sprinting. This is of course completely unintuitive as with any firearms experience you decrease the lead the closer you're shooting.
So close in its harder to hit the target than at 100 meters. To make matters even worse the firing animation does not show any lag so you have no continuous feedback of the lag and would have to observe bullet impact. That's easy to do with someone charging you.
My agenda is wanting a game I like to be more playable and less randomly frustrating due to poor programming. I'm curious what else you might think is the reason. It's all a clever deception by the Illuminati?
But yes, I do assume that it would be an instant cure for the "hit detection issues", because those issues are almost 100% attributable to shots missing moving targets due to uncompensated network delay. Fix that and you fix the vast bulk of "hit detection issues". If A is a necessary condition for B, and you remove A, then you're removing B as well.
It also doesn't matter what the source of latency is. Maybe you're across an ocean from the server, maybe you're on dialup, maybe the server's overloaded, it's all the same result in the end: latency. A decently designed compensation method doesn't care how the latency is delivered, it all looks the same and is all handled the same way.
For me there's also a realism aspect to it. Last I played there were several times of me getting off a point blank shot (with the boom and everything) right before I died. In RL I would've gotten him. With compensation, the game would in that instance have been more realistic while the trade off, dying behind cover, wouldn't have been unrealistic because dying behind cover means you really died on your way there, exposing yourself too much.
I think in practice you would also find that dying behind cover in ROHOS would be less noticeable than in other games.
Why? Because with slow death, bleed-out and penetrable cover, the odd death due to client-side hit detection would simply blend in and look like one of these other events.
Why? Because with slow death, bleed-out and penetrable cover, the odd death due to client-side hit detection would simply blend in and look like one of these other events.
seriously?Mekhazzio said:
Sorry for the sarcasm. Its not so much directed at anyone other than myself. I vowed to bow out of this (imo) often ludicrous discussion, yet here I am...Shame on me.
There are some obviously intelligent and articulate contributors. I don't know what baffles me more....The willingness to continue to espouse that distance induced latency, network protocol, the current cpu instruction set and game code issues can all be lumped into a quick fix by simply introducing (either client side hit detection) or latency compensation. Or the willingess of people to believe that.
In the meantime for those that can't compensate , I'd suggest (not entering any shooting matches and) finding a well endowed server not running over 52 players. Your play will be fine.
For my sanity, I am officially done....lol.
Enjoy....
Last edited:
Done that. On a small server with a ping of less than 80, leading a target in RO2 is nothing like leading a target in real life, and the closer the range the worse it gets.
That is all.
That is all.
First off, 'lag' issues in overloaded servers" is not "hit-detection issues," so what I said still stands: Nobody has claimed that a client-side model will be an instant cure-all for every lag issue on an overloaded server. That is a strawman argument. The only thing it will do is provide improved consistency in shot placement when the server is overloaded.
I'm not even sure what you're trying to argue here, or what difference it would make. The delay between when you press the fire button and when the ruling computer processes the shot is what matters, and a client-side or latency-compensated network model doesn't care whether any delay is from latency between the client and server, the server's processor choking from people overloading it, or the tick-rate. The delay due to distance (And line quality, and intervening hosts, etc, everything that is part of the "network" along the transmission) between your computer and the server is one of the reasons for delays, and usually the most significant by a large margin.
Look at some videos that are supposed to show this hit-detection bug. In almost every single case, you can see that where the shot was aimed as it's made on the client's screen is not where the target is by the time the shot arrives on the server and the hit effects are played. The very few that don't show this tend to involve completely non-lethal hits, such as lighting up someone's feet.
Now I have to wonder what you imagine the "dying behind cover" phenomenon is, specifically how a latency-compensated or client-side network model could produce some completely different yet strangely identical effect. I'm truly curious, because the simple fact of the matter is that it's the exact same thing: It's the delay between when the shot is ruled to have hit on one computer and the message is received on the target's computer. What do you think it is?
...okay, this whole bit seems to have nothing to do with what I was talking about, to the degree that I'm really not sure what kind of point you're trying to make here. Simple version of what you were replying to: Sometimes transmitted data gets "lost" during transmission. If it fails to go through, it's usually re-sent. In the time it takes to do that, some other data, from a later point in time, might get through. The final effect is that data transmitted in one order from one computer might reach the other computer in a completely different order. This tends to be from network congestion, not your own network hardware. It has absolutely nothing to do with ping (With the exception that a condition that causes notable packet-loss is also likely to drive up latency). It also has absolutely nothing to do with the model of hit-detection used. Changing from a server-side to client-side model will not change the order the server receives packets, nor will it introduce warping, which is what the poster I was quoting was claiming.
...That's nice? Good for you? However, I had quoted and was talking to someone else, who had provided an example of a client making predictions, so I'm not sure why what you had or had not said on the subject is really relevant.
seriously?
Yes, seriously. You should look into how the different methods of handling multiplayer networking actually work. They do not work in the way you seem to assume they do.
Any solution to the latency issues that involves not shooting is not a solution.
Yeah, I'm guessing this is why people don't seem to notice that you can "die behind cover" in the game already. I'd add in the lower movement speed of RO2 compared to the other games, as well, so the distance you get behind cover before the death message reaches your client is less.
Obviously it's not a terribly game-breaking thing if nobody ever notices it
There's nothing stopping you from explaining why you think this is an incorrect view. You'd have a bit more luck convincing others that way than simply coming along and stating that up is down and expecting that to be taken at face value.
Because, yes, it doesn't matter what the source of latency is to client-side hit detection. The server is overloaded? It doesn't need to process anything in the way of ballistics or physics, it simply nods its head when a client says it hits. It's a simple, fully deterministic algorithm, no matter how pushed back the tick rate has gotten. The packet loss is high? The hit message is resent until its receipt is acknowledged by the server. It probably won't arrive when it ought to, but the data won't be invalid because of that - that's the entire point of the design. The sheer network traffic delay is high? ...same point. It makes no difference in the end.
The only thing that could potentially degrade client-side hit detection is if a client's system is so underperforming that, like overloaded servers on the current method, it can't keep up with the basic physics cycles. That isn't much of a concern, since I really doubt anyone is likely to be playing the game at a fractional framerate.
The hit detection in this game is the worst I've seen since Delta Force 2 from 1999.
The various reasons have been discussed which make shooting enemies difficult who are separated by various network latency rates and what theories of code needs to be implemented which can make the difficulty to actually hit your target less dramatic or noticable. Some of them are good, and have been implemented by other game developers.
Why haven't they responded to this thread with a good answer to this problem which comes shipped with the engine that they purchased? Because it's a difficult thing to do! They purchased an engine, did some basic scripting and content creation, and yet somehow you guys think that they are master programmers who are just too lazy to fix the problem inherent to the engine. There's a reason why there's a call for an experienced "Senior Programmer" in their Employment link on their homepage who has a lot of experience and "Working knowledge of 3d math." I'm not criticizing them; it's difficult and very technical programming. I bet it bugs the hell out of them that they can create such a potentially great game and have it ruined by such pestering problems such as the piss poor directional audio system and no latency compensating hit registration. As it stands, the hit registration is entirely server-side and this is very apparent to all of us who have to shoot varying distances ahead of our enemy depending on their and our latency to the server. Most people without much perception just write it off as ballistic travel speed at distance and just simply yell at the screen when trying to do any amount of moving close quarter battle. We intelligent players, however, are VERY aware of the actual registration problem, and that is why servers are empty and players who ARE on the servers aren't usually very good. Then there's die-hard players like myself who are aware of the problem, who compensate for latency and ballistics and dominate in every round (Delta Force 2 comes to mind again), and only continue to play because the only alternative is a money-driven teenage-marketed industry's game titles. This game and the modding community have some huge potential for creating fantastic content and philosophies for what a game SHOULD BE but they will never be fully appreciated by the community until the engine's inherent core issues are fixed.
So you can either continue to ***** about it in the forums, join up with them if you have the skills to solve it, or find someone who does and is willing to make far less money than their skills would allow them to. Don't think that they don't hear you, it's just that currently they just can't do anything about it. Or at least that's how I see it.
The various reasons have been discussed which make shooting enemies difficult who are separated by various network latency rates and what theories of code needs to be implemented which can make the difficulty to actually hit your target less dramatic or noticable. Some of them are good, and have been implemented by other game developers.
Why haven't they responded to this thread with a good answer to this problem which comes shipped with the engine that they purchased? Because it's a difficult thing to do! They purchased an engine, did some basic scripting and content creation, and yet somehow you guys think that they are master programmers who are just too lazy to fix the problem inherent to the engine. There's a reason why there's a call for an experienced "Senior Programmer" in their Employment link on their homepage who has a lot of experience and "Working knowledge of 3d math." I'm not criticizing them; it's difficult and very technical programming. I bet it bugs the hell out of them that they can create such a potentially great game and have it ruined by such pestering problems such as the piss poor directional audio system and no latency compensating hit registration. As it stands, the hit registration is entirely server-side and this is very apparent to all of us who have to shoot varying distances ahead of our enemy depending on their and our latency to the server. Most people without much perception just write it off as ballistic travel speed at distance and just simply yell at the screen when trying to do any amount of moving close quarter battle. We intelligent players, however, are VERY aware of the actual registration problem, and that is why servers are empty and players who ARE on the servers aren't usually very good. Then there's die-hard players like myself who are aware of the problem, who compensate for latency and ballistics and dominate in every round (Delta Force 2 comes to mind again), and only continue to play because the only alternative is a money-driven teenage-marketed industry's game titles. This game and the modding community have some huge potential for creating fantastic content and philosophies for what a game SHOULD BE but they will never be fully appreciated by the community until the engine's inherent core issues are fixed.
So you can either continue to ***** about it in the forums, join up with them if you have the skills to solve it, or find someone who does and is willing to make far less money than their skills would allow them to. Don't think that they don't hear you, it's just that currently they just can't do anything about it. Or at least that's how I see it.
Last edited:
- Status