Leading for ping is ridiculous, Mk.2: An Example

[Mormegil]

I may be wrong but I think he is talking about a better covering system like when hiding behind sand bags they could be penetrated. If thats what he is talking about then I agree. I think covers should be penetrated with bullets. The only penetratable wall(s) I know of is the walls in Welding Shed (B) in Red October Factory.

You need to shoot more walls. When I've got an MG or even a semi auto rifle, a third of my kills are guys hiding behind walls. Most walls can be penetrated by rifle rounds. You just need to know where to aim based on where people like to stay behind or under cover.

 

[r5cya]

I may be wrong but I think he is talking about a better covering system like when hiding behind sand bags they could be penetrated. If thats what he is talking about then I agree. I think covers should be penetrated with bullets. The only penetratable wall(s) I know of is the walls in Welding Shed (B) in Red October Factory.

you must not have played the game long then. you can shoot even the weakest guns through lots of walls! i love shooting guys who run onto the other side of a wall to avoid me. i just pop them through it!
as far as sandbags being penetrable, really? why do you think they used them in the first place? why do you think just about every backstop at every rifle range you've ever been to has sand behind them? it stops bullets. i think the ptrs might/should be able to penetrate, but not the rest of them. i'm gonna have to check this one out for myself. next time i go to the range i'll bring a sandback and shhot it with a steel core 7.62x54 round. i'm willing to bet it will not penetrate even the narrow width.

we better let the guy i asked the question to to answer for himself.

 

[dazman76]

I'd like to add to my previous post, by saying that I mean no offense to people like Mekhazzio, who was spent quite some time debating this issue. You (and others) obviously have done quite some research into the problem, but I do still question the assertions that client-side authority would work well in RO2. I also question, without proper testing, the assertion that client-side authority works well with a full ballistic model. Even given latency effects, I feel that such a model still works best when a central server is the authoritative entity - it provides balance, where client-side authority seems to always lean in favour of the shooter. This seems faulty, when latency could well be affecting the shooter too, but still leans in their favour.

 

[mattlach]

Honestly, I have 160ping on even local servers sadly, and I have to lead my shots up to like 5m before I get a hit.

This is because in-game ping = network latency + server computation latency.

This is why when you search for a game in the browser the ping is almost always lower than while in the game.

The reason this happens is because this game is VERY CPU intensive due to all the bullet physics computations going on, and the fact that the engine really isn't multithreaded at all, loading just one server core very hard.

Most modern servers are OK up to 32 players, but when the player count is cranked up all the way to 64, there simply isn't a server CPU made today that can handle the load, without adding server computation latency.

Personally I ping ~13ms to the 2fjg server, but once inside my ping is often as high as 160ms...

Something really has to be done from Tripwires side to address this, especially as community maps get larger and load the server CPU harder. They probably don't have the option to multithread, as it would likely require rewriting the entire engine.

Since the client side supports PhysX, I wonder if the server could be coerced into using it as well. That way you could put a GeForce card in your server and use it to offload physics calculations, and thus reduce server calculation latencies. it would be unorthodox and kind of weird, but it might just work...

Otherwise the options are going to be to sit around and wait for single threaded server performance to increase, make smaller maps or limit servers to 32 players...

 

[MrHello]

If all it'd take is for them to multi-thread it rather than re-write network code, then what the hell, I don't care I just want to play without having to compensate so rediculously for shots!

 

[Mormegil]

Since the client side supports PhysX, I wonder if the server could be coerced into using it as well. That way you could put a GeForce card in your server and use it to offload physics calculations, and thus reduce server calculation latencies. it would be unorthodox and kind of weird, but it might just work...

I was wondering that too, and spawned a discussion on these forums a few years back. It seems like that wouldn't work, because PhysX and CUDA based calculations are designed for a lot of parallel calculations. This is the kind of thing you need when rendering a scene, or simulating particles / boulders - lots of the same calculation run in parallel. Eye candy physics.

The physics of the game on the server is more random - collisions, trajectories, damage models - each in a random order. So no good for PhysX, I believe.

 

[PhoenixDragon]

I also question, without proper testing, the assertion that client-side authority works well with a full ballistic model.

See any WW2 flight sim. They have ballistics and client-side hit detection working just fine. It's actually a quite common combination.

 

[dazman76]

The physics of the game on the server is more random - collisions, trajectories, damage models - each in a random order. So no good for PhysX, I believe.

Just to add to and clarify what you said - it's more that the randomness isn't good for CUDA, because of the parallelism you mentioned. PhysX itself is a full physics engine that doesn't require CUDA to operate - so I'd say that PhysX is used for both client and server physics (makes sense to use the same library/engine), but it uses CUDA only on the clients.

Even in that brief time when the old PhysX cards existed (remember those? ), the library could work with only the CPU, so it was a competitor to Havok etc. The cards, which were a bit pricey to say they only handled physics, were largely not understood by gamers - there hadn't been a whole new card for PC's in many years, and since physics already worked quite well without them, they were pretty niche. NVIDIA and ATI realised their parallel GPU cores could do the same things, so NVIDIA bought PhysX to get the library itself, and a better look at the hardware design.

 

[Mekhazzio]

I do still question the assertions that client-side authority would work well in RO2. I also question, without proper testing, the assertion that client-side authority works well with a full ballistic model. Even given latency effects, I feel that such a model still works best when a central server is the authoritative entity - it provides balance, where client-side authority seems to always lean in favour of the shooter.

Favoring the shooter is the entire point, though. In RO, we have a game design where the projectile speeds versus character movement makes dodging impossible. By the time you even realize you're under fire, it's already been decided if you're hit or not. If we were playing something in more of a shmup vein like Descent, where weaving through slowly moving fire is a huge part of the gameplay, then yes, it would be problematic to make the shooter authoritative, but in RO, everything is already decided on the shooter's side to begin with, so giving them full fidelity comes at no cost.

As for the larger theory discussion, this is hardly a new topic. Client authority has been a staple of internet gaming since before there was internet gaming. All the earliest online action games on GEnie, Compuserve, AOL, Gamestorm, etc were made possible by authoritative clients. It's only a fairly recent development that computing resources and bandwidth have been inexpensive enough to allow the luxury of fully server-based models for a wide audience. Even now, authoritative clients are still necessary for large volume settings like MMOs, to cut down on server workload, and for high-precision environments like combat flight simulators, because of the prohibitive complexity and overhead of doing server history rollback on a precise level with anything other than hitscan weaponry and the sheer pointlessness of not using any latency compensation at all. RO2 shares a lot more in common with a flight sim than it does with a traditional shooter like UT.

As for if it can be done, it should be fairly trivial in Unreal Engine. Just run the firing logic on the clients, like in single player, and replicate the hit functions over to the server. It might even be possible to drop in as a mutator. (Hmm......)

 

[Gaizokubanou]

what? can you explain that in more detail to me, please? esp. the trading refinement part? seems like such a broad, vague statement. what are you willing to give up there?

I meant currently we have hit detection on server side so that you will almost never, if not just never, die right after getting behind a solid cover.

If hit detection were to go client side, then while I managed to get in cover, someone would've seen my character still moving to where I am due to internet delay, and if they scored a hit on that delayed data, I would receive a hit while in a cover.

I rather have the second case if it meant that aiming and shooting was much more precise.

Favoring the shooter is the entire point, though. In RO, we have a game design where the projectile speeds versus character movement makes dodging impossible. By the time you even realize you're under fire, it's already been decided if you're hit or not. If we were playing something in more of a shmup vein like Descent, where weaving through slowly moving fire is a huge part of the gameplay, then yes, it would be problematic to make the shooter authoritative, but in RO, everything is already decided on the shooter's side to begin with, so giving them full fidelity comes at no cost.

Basically this.

 

[melipone]

I thought the netcode worked fine in Ostfront, and suspect its not that much different in RO2. I've never been a fan of over the top prediction like in source games. Theres pros and cons for all the styles of netcode..having to lead the shot a bit more is the best of the lot imo. The other types have to predict far too much and end up making mistakes or guess whats happened, or make it feel like its not even in real time so you can't react to what you see. Having to adjust your aim and shoot a little infront of the movement of a player is a good compromise imo, as long as that then correlates to better overall reg and a feeling like you can adjust to the situation rather than getting shot before you can even move into cover.

There are probably just some bugs atm, or it isn't like Ostfront? The invincibility in some limbs will also make shots feel off. Another important factor is a steady ping. If pings fluctuate a lot because servers are being stressed then you have to change the amount of lead in the shot. Getting pings steady like in Ostfront is probably important for overall reg (so people get used to one type of delay). The example in the op is also of someone with an abnormally high ping. The game should be made to work the best for the majority of the players rather than the minority. Why should I get shot a second or so after going behind cover after seeing someone, just because they have a high ping? I should be able to react in real time to what I see

Reg was good in Ostfront. Not so many WTF moments like in predictive netcodes. Hopefully its similar in RO2

 

[24.Pz.Kaul]

OP, thanks for taking the time to clear the "hitbox detection" issue up. LOL! That was a great gif.

The bullet lag really is terrible. It's basically the main reason my friends and I quit playing.

This was the biggest reasons all of my friends gave up trying to play.

It's an unforgiving, pinpoint game with player hitboxes that are small and well modeled ballistics, but the network introduces a "luck-factor" to every shot that IMHO shouldn't be there.


Would love to see Ramm's comment on this.

 

[defektive]

The speed of RO2

 

[melipone]

The speed of RO2’s game play highlights the weaknesses in the suitability of server-side hit detection. RO played a little slower and was a little bit more methodical which helped to obfuscate the random lead distances. The thing is RO2 now introduces bullet travel time which only serves to exacerbate the issue. RO2 probably should have favoured the shooter.

Moot anyway because Satan will be ice-skating to work the day before TWI re-think this one. Slower game play (and maybe removing bullet travel time) seems to be about the only likely practical solution.

I would like a more tactical style FPS too. With real time decision making based on knowledge of your player's current strengths/weaknesses and time it takes to do moves. Like Ostfront. But not really because of the netcode. We used to play fast paced games on dialup like quake 2 that even had a delay before your weapon even reacted to a key press based on ping. Modes like railgun only (freezetag!) were fine. Only thing was low ping players had an advantage, but that will be the same no matter what. Now most people have a low ping and the game should be based on that. With a high ping your damage still only happens based on your latency. I don't really mind leading for ping personally, and I much prefer it to dodgy netcode like in CS or similar games. People over like 100 ping in CS style netcodes warp around a lot or cause other issues that makes it feel like its not real time (server goes back and looks at what happened and can create errors, or even just try to guess what happened). Ram did a good summary of the netcode styles and I agreed with him on that.

Edit, this is what Ramm said about it: http://forums.tripwireinteractive.com/showpost.php?p=662931&postcount=9

 

[defektive]

Edit, this is what Ramm said about it: [url]http://forums.tripwireinteractive.com/showpost.php?p=662931&postcount=9[/URL]

Yeah, I read it the first time it was posted. I agree that "method 2" reads like the best option but practical experience in-game just feels wrOnG somehow. Either something isn't working correctly or there are forces at work that I don't have the technical understanding to identify.

 

[Mekhazzio]

Ram did a good summary of the netcode styles and I agreed with him on that.

Edit, this is what Ramm said about it: http://forums.tripwireinteractive.com/showpost.php?p=662931&postcount=9

The bulk of that post is not discussing general networking styles but ways of handling just hit displays in specific, which are the blood sprays and hit confirm sound effects. It's just deciding if you want to conceal the fact that the networking is skewing the hit location or not. Knowing where your hits are actually landing is nice and all, as it lets me make videos like in the OP and gives you at least some clue as to wtf is actually happening behind the scenes, but it doesn't even try to address the problem that shots don't go where they're supposed to when moving targets are involved.

 

[r5cya]

I meant currently we have hit detection on server side so that you will almost never, if not just never, die right after getting behind a solid cover.

If hit detection were to go client side, then while I managed to get in cover, someone would've seen my character still moving to where I am due to internet delay, and if they scored a hit on that delayed data, I would receive a hit while in a cover.

I rather have the second case if it meant that aiming and shooting was much more precise.



Basically this.

gotcha! thank for explaining it to me!

 

[CheckYour6]

This is also why you don't get killed behind cover in RO2 and in other games you do. Lag compensations are like hax for those who can't have a good connection.

 

[mattlach]

This is also why you don't get killed behind cover in RO2 and in other games you do. Lag compensations are like hax for those who can't have a good connection.

With prediction you never get killed while behind cover. This is a fallacy.

You get killed while you are in the open or exposed.

It just doesn't register on your client until after you have reached cover.

With prediction the game is still the most fair, and the most playable.

 

[=GG= Mr Moe]

With prediction you never get killed while behind cover. This is a fallacy.

You get killed while you are in the open or exposed.

It just doesn't register on your client until after you have reached cover.

With prediction the game is still the most fair, and the most playable.

See, you can look at if from the target's perspective. You are behind cover but the shooter lags a bit behind and sees you in the open, when in fact YOU ARE NOT.

Prediction being fair and playable is an opinion only, and your opinion I do not share. I would rather err with caution and side with the target. Players are dying fast enough as it is