Lack of interpolation really kills games with a small community.

[mattlach]

[QUOTE='[Mad_Murdock]
We say: the server updating everything is laggy because it has to track everything and update every client.

You say: We cannot use client side lag comp. because it will stress the server so much we all lag.[/QUOTE]

I think you misunderstood.

In its current state, the engine has no lag compensation at all.

Lag compensation can be implemented on either the server or client side.

Server is not ideal as it comes with a lot of load, and the servers are already pretty loaded from this CPU-heavy title.

Client is not ideal as it comes with a huge potential for cheating, as the server has to trust the data coming from the client (which may have been modified somehow)

at least that's how I understood it.


Personally, I'd prefer to have the choice to use the benefits of client side lag compensation, and the ability to turn it off if there is a perceived large amount of cheating (despite VAC and PB being enabled).

The approach that TWI has taken (nothing at all) just comes across as being lazy, and the whole "it will bork my game by having me die behind walls" thing just sounds like an excuse to cover that up.

 

[dazman76]

I have to admit, my feeble mind doesn't even understand how client-side hit detection actually fixes anything. If your ping is high, then there's a good chance that the enemy you're aiming at isn't stood where he appears to be - so regardless of where the hit detection is, you stand a high chance of missing. The client still has to receive position updates and verify kills with the server - so this approach simply leads to apparent hits and kills, which are then confusingly reversed when correct information is again received from the server.

How can one person's client predicting hits/kills with inaccurate data, improve the lag-induced problems? Maybe I'm just being dim, but I don't understand this logic at all. Every client could be running different latencies and therefore working with different error margins - while a hit can be confirmed on client A because enemy B appears to be in your sights, there's a high chance that enemy B isn't actually in your sights at all. So, you think you killed them, but you didn't - the server still has to make that decision, you can't have clients making these decisions without confirming them with the server, and other clients. Can you? Seems illogical to me. Well actually, just seems plain wrong and un-workable. I must be missing something.

 

[the_Monk]

Well, if that is indeed the case, then I have yet to play on a server that can handle the load of RO2...

...and I've played on a lot of servers.

Put it this way, many (not all of course) 64-player servers cannot properly handle 64-players. Is that only due to the server hardware/connection and not somehow also related to the game engine? I don't know......I'm not a software dev.

What I do know is that servers between 24 and 32 players running tweaked tickrate and connectionrate configs rarely and I mean rarely exibit "hit detection issues" for me regardless of my ingame ping to the server.

 

[6S.Maraz]

I have to admit, my feeble mind doesn't even understand how client-side hit detection actually fixes anything. If your ping is high, then there's a good chance that the enemy you're aiming at isn't stood where he appears to be - so regardless of where the hit detection is, you stand a high chance of missing.

No, because the position of the enemy is computed on your PC, not the server's, or the enemy's. In your words, you must aim exactly where the neemy "appears to be" (in your PC). Of course you must take into account bullet travel time if the enemy is running, but no additional deviation due to Internet packets travel time.

So hit detection is completely client side, the cient tells the server "I have hit", there is no decision by the server.

Maraz

 

[[Mad_Murdock]]

I think you misunderstood.

Entirely possible lol, i am far from an expert on this stuff.

How can i tell which server has modified tickrate and connection settings? Cause it seems all i can do is find a 32 player and hope for the best.

 

[the_Monk]

Entirely possible lol, i am far from an expert on this stuff.

How can i tell which server has modified tickrate and connection settings? Cause it seems all i can do is find a 32 player and hope for the best.

Once ingame open the console and type "stat net" to turn on the network statistics. You can see under INBOUND if you are ever getting more than 20 (20 is the default MAX tickrate setting) then the server has been modified.

 

[dazman76]

No, because the position of the enemy is computed on your PC, not the server's, or the enemy's.

Right, thanks for the explanation

However, this isn't multiplayer gaming in my opinion - so I'm still surprised that people see this as a "fix" for latency-related problems. To have a reliable, fair MP game you must get your position info from a single, central source that is classed as the definitive "state". If every client calculates independent positions these could all be in error without confirmation against server-supplied information. I'm guessing there has to be more to it than this, but I still don't see it as a step forward - quite the opposite in fact. Does such a system really improve gameplay? It seems to me that both approaches have pros and cons, but I find it hard to see a true improvement since neither approach is perfect. Again, if I'm missing something obvious, apologies to whoever replies heh

 

[=GG= Mr Moe]

While I don't fully understand the exact details, I think some people have it wrong and I'm sure someone with more knowledge will step in and explain it better with client/server side hit detection.

But in short since I am on hold at work ( ) I am not in favor for any kind of lag compensation. When I have played on higher ping servers in ROHOS and ROOST (in Russia from here in the states) and I just lead my target as if I am hunting a running deer, then add a bit if my ping is high and I have reasonable success with it. I am not talking when a server is obviously lagging.

Plus, I have been shot behind walls after ducking and around corners in other games and it truly sucks. You are trying to give the benefit of the doubt to the firing player when the person being shot at may have dived to cover or run out of sight and that person is getting screwed.

Sorry to those suffering from high ping on far away servers, but I don't think the majority of the other players should be punished.

 

[mattlach]

Put it this way, many (not all of course) 64-player servers cannot properly handle 64-players. Is that only due to the server hardware/connection and not somehow also related to the game engine? I don't know......I'm not a software dev.

What I do know is that servers between 24 and 32 players running tweaked tickrate and connectionrate configs rarely and I mean rarely exibit "hit detection issues" for me regardless of my ingame ping to the server.

So what kind of server would one need to properly field a 64 player game?

What makes this such a challenge to achieve? Does the dedicated server just hammer one core, just like the client?

 

[=GG= Mr Moe]

So what kind of server would one need to properly field a 64 player game?

What makes this such a challenge to achieve? Does the dedicated server just hammer one core, just like the client?

The server doesn't have to draw anything...

 

[Reise]

Find a server with 2x tickrate.

You will never have an issue with shot registration.

 

[Echo Black]

Find a server with 2x tickrate.

You will never have an issue with shot registration.

This is not the issue at all...

---

 

[radix]

No, because the position of the enemy is computed on your PC, not the server's, or the enemy's. In your words, you must aim exactly where the neemy "appears to be" (in your PC). Of course you must take into account bullet travel time if the enemy is running, but no additional deviation due to Internet packets travel time.

So hit detection is completely client side, the cient tells the server "I have hit", there is no decision by the server.

Maraz

How does your PC (client) know where the enemy is?
It knows because the server told him.

What if the enemy moved behind cover, the server state machine get actualized, it notifies all other 63 players but your connection sux and your client doesnt get notified in time.
Your computer still see the enemy in a location where he is not for all the 63 players except you. you shoot and you expect him to die? Ruin the game of all other 63 players just because you have a "personal" problem with your inet connection?

I find client side and server side lag compensation pretty bad. It could be good (server side only) if applied moderately.

FFS find a server near you and play there. No server? Rent one!

BTW guys, the ping displayed in game is not the ICMP ping. Is the UT ping. Dont compare it with CS or other games ping. I've posted several times how this ping number is computed but I'm too drunk and cant be bothered to search for it.

 

[Mekhazzio]

Find a server with 2x tickrate.

You will never have an issue with shot registration.

This is not the issue at all...

It's a part of the issue, since at the default 20 tick rate, you have an essentially random amount from 0 to 50ms added on to everything. That's up to a quarter of a meter of extra lead by itself, but most notably is further magnifying the fluctuation that's already inherent in internet gaming. The lack of consistency from moment to moment is as much of an issue as the delay itself and can mean you need to significantly vary your lead to hit even two people running alongside each other. Conveniently, this problem is also solved by client side hit detection.

It seems to me that both approaches have pros and cons, but I find it hard to see a true improvement since neither approach is perfect.

Yeah, that's the short version of the problem. The game is trying to coordinate events that resolve faster than even an above-average internet connection can transmit them, so all solutions are a compromise at best. The question is what form you want that compromise to come in, and "hitting what you aim at" is not something a first person shooter should be trading off for intangible gain.

 

[Grimreapo]

As someone who has played BF3 and the other modern shooters I can say no thanks to this, in theory this is nice but I have not seen a game use it well and I dont want this in RO2:
Cadburry - Black Ops lag compensation - YouTube

 

[mattlach]

As someone who has played BF3 and the other modern shooters I can say no thanks to this, in theory this is nice but I have not seen a game use it well and I dont want this in RO2:
Cadburry - Black Ops lag compensation - YouTube

But on that players screen, the guy was right on target. Lag compensation makes the experience more accurate from the shooters experience.

To me this makes perfect sense, as shooting is the most precision oriented part of the game.

 

[Grimreapo]

Black Ops lag compensation - YouTube
Black Ops - Lag compensation?!?! - YouTube
A short demonstration of source engine lag compensation at it's finest. - YouTube

I could go on, in THEORY its a great idea and as much as I like TWI would you honestly want them to code such a thing in a hurry?

 

[Colt .45 killer]

I lol'd so hard. Next time please try a little more embellishment to make your already ridiculous statement even more so.

Being an Australian in an American clan this is a pertinent issue for me. Lag Compensation hardly damages game play, and the "dying around a corner" defence is a total cop-out. Because, regardless of whether it appears you're around a corner or not, the enemy player still shot you when you were in the open.

This was almost a game-breaking issue for me. But I decided to sack-up and support my clan mates. I play with a 250 ping and no anti-lag... It's a pretty interesting experience when you're trying to snapshot around a corner with a KAR98 and there's a PPSh in your face.


Wally

It was your choice to join an off continent clan. ( That seems harsh, but it's true )

Also, speaking from experience in Bfbc2 the way the stack trace of previous places works allows laggier players to see you after you have already passed an area. So they can see and shoot you, where as a second ago when you ran by, they *were NOT there*. Nothing more annoying then the advantage in that case being given to someone with a lagged connection.
IF RO2 were to get a copy paste of BFBc2's lag correction I would quit playing.

Also, HOS DOES have some minimal elements of lag correction in the form of client side prediction.

Also, a lot of the running shots are lagged already for myself, and I often have a very good ping to the server, so some of that is probably code related and due to a lot of the bugs.

 

[WallyAussie]

It was your choice to join an off continent clan. ( That seems harsh, but it's true )

Right, I understand the point. I get it. I've already been flamed serveral times for it. I joined 7 years ago, and I don't think I'll be leaving anytime soon.

The obvious benefits of client-side lag compensation and the choice the developers made to not include it is abusrd. It's 2011. Not 2005.

The killed around the corner argument is so unbelievably fallacious I can't understand how people take it seriously -- or think it impacts on their gameplay. The enemy player died when he was not in cover from a legitimate shot and a legitimate hit. The embellishment that some people are adding to their stories of horrendous experiences with lag compensation are truly amusing. It makes not a whit of difference to the immersion of the dying player (up to a reasonable ping limit of, say, 300 -- and players past that sort of ping can be removed from the server anyway).

When you see those videos of Black Ops, you're looking at it from the server's perspective, from a replay recorded by the server. Of course there will be lag there when dealing with high ping players. What you're not seeing is the real time perspective of the shooter, nor the real time perspective of the victim. Which appear genuinely (because that's what it is: genuine. No artificial lead for ping) as if they took a shot on target. So, for the purposes of this discussion, they too are erroneous -- they're giving completely the wrong impression.





Wally

 

[Mekhazzio]

The TF2 video is actually supporting the client-side argument, since it's showing misses that the server verifies as hits and is demonstrating the effectively random nature of a server-arbitrated model on rapidly moving targets. The whole point of client-side hit detection is to stop both the misses that are actually hits and the hits that are actually misses. TF2 uses server-side lag compensation, which is in most cases a pretty good solution, but in extreme cases like the transpacific connection in that video, it breaks down to the point that it's no better than the basic server model RO2 uses.

RO2 has an endless amount of similar instances to that TF2 video, it just has the disguise of bullet time of flight to mask it. People expect to be leading targets and don't look too closely at the end result that you're leading with an effective projectile speed more appropriate for a baseball than a bullet.