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

[dazman76]

With client-side hit detection, it's exactly the opposite, however. It would take a substantial load -off- of the server and distribute it across the clients.

After all of this talk, I still can't decide (for myself) which route seems to make the most sense. I'd love to see both implemented, so we could have servers running them and actually try them out. After the biggest hurdle of TWI not liking the client-side approach - which is a pretty big hurdle it has to be said - wouldn't any extra load on clients cause problems right now? They've already removed "stuff(tm)" from the maps to ease pressure on the clients, and there is still more optimisation to be done before all players are running smoothly. Would extra client load negate these efforts?

Bah, who are we kidding? We aren't going to get the chance to try it and find out are we? I really would like to. I'm still cynical that more client authority is the way forward, but I'm very much open to being proven wrong and enjoying the result

 

[defektive]

Bah, who are we kidding? We aren't going to get the chance to try it and find out are we?

Aye, it's a pretty safe bet that this will never happen; RO2 is wedlocked to its current netcode. Accepting that, the only option is to try and mitigate the symptoms of the way RO2 works, i.e., random target lead, rather than tackle the cause directly. Trying to reduce the ping overheads on servers is one step along that route, and as far as I last heard that

 

[PhoenixDragon]

Maybe tackling the current inertia-less movement model would help a bit too.

Inertia is already in. It's fairly significant, too. Try snapping 180 degrees while running. It'll take a good second or more before you'll be up to speed in the new direction. I'm constantly amazed that people don't notice it.

 

[defektive]

Inertia is already in. It's fairly significant, too. Try snapping 180 degrees while running. It'll take a good second or more before you'll be up to speed in the new direction. I'm constantly amazed that people don't notice it.

Yeah, perhaps "inertia-less" was a poor choice of words because there clearly is at least some inertia. That said, it

 

[dazman76]

a growing, fuzzy area of variable probability amplitude

Oooo, quantum physics!

 

[defektive]

Oooo, quantum physics!

Yup, this is the RO2 Uncertainty Principle show starring Ramm’s Variable (as a last minute replacement for the previously billed Planck’s Constant).
:IS2:

(Easy, Tigers. I'm only kidding.)

 

[Floyd]

I've got some ocean side property with a pier and a yatch for sale in AZ if anyone is interested. I guess I could manufacture a .gif to prove my point. However, the fact that I can show I have property, pier and a yatch in AZ doesn't mean there is an ocean there......

Lets get the game optimized first before we change the netcode. If clientside hitscan and your typical netcode were run on the overloaded servers we have now you would experience warping like you've never seen. Dieing around corners will become dieing after you've run inside and up three flights of stairs (if the shot even gets registered and is not thrown out of the stack). Next will come the high ping kick mutators (<sarcasm> because everyone knows that high pings lag the server</sarcasm>.... ). Servers will still be taxed and no-one will be able to play anywhere.

Server Requirements:

16 Players: Haven't benchmarked this yet, but we don't expect it will take much CPU to run this

32 Players: CPU usage - 1 Core of a 2.6 GHZ Core I7 or equivalent (i.e. the server process will take most of 1 core, with a few smaller threads on other cores). We also tested on an Intel Core2 Quad Q8400 @ 2.66GHz and that could handle 32 players but I wouldn't try and do 32 players with a machine much slower than that.

64 Players: Goal CPU usage - 1 Core of a Intel Xeon E3-1270 3.4 GHZ (3.8 GHZ actually with Turbo enabled) or equivalent (i.e. the server process will take most of 1 core, with a few smaller threads on other cores).


A note on performance:

64 players was pushing the test machine (Intel Xeon E3-1270 3.4 GHZ (3.8 GHZ actually with Turbo enabled) pretty hard on certain maps, but did handle 64 players. Likewise 32 players pushed the Intel Core2 Quad Q8400 @ 2.66GHz pretty hard at 32 players, but did handle it. We're working on some final optimizations that might get the performance a little better, but there won't be any drastic changes from these specs.
Likewise the number of players the server can handle (i.e. how much performance is needed) varies from map to map, and gametype to game type. Smaller maps and countdown tend to perform better than larger maps in territory or firefight. So if you run smaller maps only on your server, you might be able to push the slots higher. Just watch your CPU usage, and more importantly the ping of players connected. Ping will climb a bit as the server gets under load and as CPU usage goes up, this is to be expected. But watch the ping, if it is a server near you and the ping starts to go above 100ms consistently, then you are likely pushing your server too hard and need to reduce the number of slots.

What I have found is that it looks like an Intel Xeon E31270 @ 3.4 GHZ (3.8 GHZ actually with Turbo enabled) can just handle 64 players now, and is being pushed pretty hard. We've got a last batch of optimizations that we're going to try over the weekend that might bet it down a bit lower so the CPU isn't pushed quite as hard (possibly getting things down by about 5%). We tested on an Intel Core2 Quad Q8400 @ 2.66GHz and that could handle 32 players but I wouldn't try and do 32 players with a machine much slower than that. As mentioned before, the final optimizations might push this down a little, but nothing drastic.

Server code optimization is a known issue and is the first thing needing to be addressed.


Unfortunately, unless they go the way of DICE and not release the server code to the public and require admins to rent servers from 'qualified' GSP's, TW can't control what hardware or what player numbers a server admin runs their software on. Sadly, the general public does not seem to care and flock like lemmings to overloaded servers 64 player servers.


True, 64 players were advertised, but there are clearly (and acknowledged) game code optimization issues (notice I did not say netcode issues). Unless and until that is fixed, if you have gameplay issues quit pandering to the 64 player numbers. Play on less taxed hardware and you'll be much happier. Win/win for everyone. More players and more server options.

 

[mattlach]

Sadly, the general public does not seem to care and flock like lemmings to overloaded servers 64 player servers.

Yes, this is very frustrating.

I'd rather play on a more responsive 32 player server, but they are always empty (or full of bots)

Instead I have to fight for a spot on a continuously full 64 player server.

It would be so much better if the 64 player server were split into two 32 player (or maybe even 48 player) servers. The game would be more responsive and it would be easier to get into a server.

Unfortunately, the moment a server admin reduces from 64 players to something more reasonable for the server hardware, all the players leave and flock to another overloaded 64 player server.

I don't know what it is about the magic number 64, but it sucks players in like crazy...

 

[mattlach]

sed, but there are clearly (and acknowledged) game code optimization issues (notice I did not say netcode issues). Unless and until that is fixed, if you have gameplay issues quit pandering to the 64 player numbers. Play on less taxed hardware and you'll be much happier. Win/win for everyone. More players and more server options.

Agreed.

Netcode may be an issue, but if the engine can just be optimized to the point where in game latencies start matching console latencies, it would be less of an issue. The biggest problem is the server optimization.

 

[Serial Messiah]

And the number of times that is actually important in a match is practically negligible. You talk as if tactical movement, as in real-world tactical movement, makes you able to dodge bullets. With the already low movement speed and inertia, you're not going to be making reactions quick enough to make a difference. Even poking out from cover, snapping off a shot, and dropping back behind cover, takes most of a second. More if you actually aim. Erratic movement will still make you hard to track (the reason it's done in the real world), it just won't have the unrealistic extra benefit of forcing the shooter guess which way you're going to move next between the time he takes the shot and the time the server gets the message (which obviously does not exist in the real world). Strafing back-and-forth when an enemy starts shooting at you from 10 meters is not tactical movement, it's taking advantage of the network model that penalizes the shooter. When you get in close, the guy who stands still and tries to make an aimed shot will almost always lose to the guy who jitters around firing hip-shots, even if the moving guy takes multiple bolt-action shots to hit. With its networking, close-quarters RO2 combat resembles Benny Hill more than it does Stalingrad.

So you'd have to rely on stuff like suppression fire, smoke, short dashes between cover, and other such tactics. You know, the kinds of tactical movement used in real life. That's what Mekh's point about LANs was. If you were to play a match on a LAN, your bullet-dodging stuff would not work.

And I do find amusement that penalizing run-and-gun gameplay is now considered a flaw of the client-side hit-detection, rather than a benefit.

I'm wondering if you guys actually played this much. With how much I've played this and the original, one thing remains true: the shooter who aims usually comes out ahead even in close quarters. Reflex is certainly a part of it, but when I take a tenth of a second more to aim at an opponent five or ten meters out, I usually prevail. When I panic and shoot wildly, I usually lose. It's almost always like this, even in ROHOS. Of course I go out of my way to play on servers where my ping is below 150 ms. That might just be me. If there aren't any servers with a suitable ping and a decent number of players, I usually don't even bother. Further I notice myself stricken with lag bullets in other games far more than I see dubious misses in ROHOS. Yeah there are times in this where I feel in close combat like my muzzle is clipping someone because the shots are just pouring through them, something which is rare in others games, but that may well be a separate issue.

The primary flaws of client-side hit detection is that it's retarded and highly arbitrary when machines and connections differ widely between players. Doing the whole relay of having the client report a shot, the server registering whether it hit or not, and then sending the packets back to clients is far better than particularly laggy people receiving benefit from their awful connections. Combine that with the ease of hacking in such a system and you have something that developers generally avoid with good reason.

You can not realistically master the current system because how much you have to lead depends on your ping and the other guy's ping. Having your gun's functionality change at its core (bullet speed) depending on who you shoot at is very unintuitive at best, ahistorical and frustrating at worst.

It doesn't really depend on the other guy's ping far as I know. The server determines whether the player is struck and relays that to the client.

 

[PhoenixDragon]

If inertia is tweaked to more affected your ability to jink and weave then it might help mitigate some of the randomness

 

[Xendance]

I'd really like to see something supporting this idea. We're not talking the aimbots that every game gets, networking doesn't matter for those (In fact, they're already there for RO2). The theoretical weakness of a client-side model is a man-in-the-middle method that replaces all your "miss" messages with "hit" messages. I say theoretical, because I'm not aware of any such hack having ever been made, even for exceptionally popular FPS games. The chances of someone making one for RO2, a small and niche game, is vanishingly small. Besides, with both VAC and PunkBuster, how much paranoia do we need? Is it really worth trashing responsive shooting to avoid a theoretical hack that is unlikely to be made, and likely to be shut down by the two anti-cheat systems already running on this game?

Here's one example BF3 MassKill Hack - YouTube

 

[Mekhazzio]

That's so much less detectable than an aimbot, right?

Kind of awesome, though. I'd like to see the server code that allows that through. They must not have even tried.

 

[Red Engima]

Here's one example BF3 MassKill Hack - YouTube

Meh, the RO2 community is so small hacking so blatantly will get you banned for any good sever if not all the severs. Any good sever worth its weight in gold will have a admin on 24 hours

 

[Cullis]

It's also not the real source of the problem, anyway. Almost every other FPS ever made will eat 150-200ms for breakfast, and most can smoothly handle two, three, or even six times that much latency. The RO series is special in this regard, and not the good kind of special.

:what:
Have you ever played any other FPS online?

Unreal Tournament gets utterly unplayable at pings over 150 ms. Red Orchestra is slightly better, due to slower movement and the nature of the play.

Six times that latency is one second. You can't probably play Starcraft over that, or Wow.

 

[PhoenixDragon]

Here's one example

Thank you, I'm glad someone actually supplies something to back that up.

I must admit I'm kind of surprised that the server doesn't reject most of those shots just based on relative locations. That seems somewhat shoddy. Even early client-side models would give a rudimentary check of the shooter and target's location to make sure the shot could have been made as reported, even if it was just comparing general zones. Even then I don't know if something that blatant would be possible in RO2 just because people don't even exist on the client if they're far enough out of sight (This is why sometimes people disappear in spectator mode, particularly after they die; the server decides they're no longer relevant to you, and stops sending you data).

Still, that's quite a bit more obvious than an aimbot. I rather question how well it'll keep working against VAC and/or PunkBuster. Or how much disruption it could cause. BF3 is a massively popular game. How often does something like that show up? In well over a decade of gaming in client-side hit-detection games, I've seen less than a dozen aimbots. I've never encountered a push-button-to-kill-anyone hack like that, so I admit I'm a rather surprised (I think DICE must have dropped the ball on -something- for that to even work). I've only encountered one person cheating in RO2, though I'm not sure if that was an aimbot or a wallhack (Which is probably the most effective of the possible cheats, and typically least obvious from the PoV of other players).

 

[PhoenixDragon]

Six times that latency is one second. You can't probably play Starcraft over that, or Wow.

I've played L4D2 matches with that much latency. Not by choice, mind you. Roommates can make latency a little unpredictable. But while in RO2 a 1-second latency is "Holy crap I can't do anything," in L4D2 it's "Huh, something seems a little strange. Oh well, I'm still killing them fine."

 

[dazman76]

Here's one example

Holy hackfest Batman That's a whole new level of hack that I wasn't even aware of Quite literally, the big red button. Words cannot describe how pathetic humanity has become lol

 

[Mekhazzio]

:what:
Have you ever played any other FPS online?

Unreal Tournament gets utterly unplayable at pings over 150 ms. Red Orchestra is slightly better, due to slower movement and the nature of the play. Six times that latency is one second. You can't probably play Starcraft over that, or Wow.

Red Orchestra and Unreal Tournament use exactly the same internals. RO is built on the Unreal engine. So...yeah. It stands to reason that they behave exactly the same. That's kind of the point of this thread. It doesn't work all that great for UT and it definitely doesn't work for RO.

But yes, other FPS' can handle that kind of latency without imploding. I was playing Nuclear Dawn a couple weeks back with >1 second latency and it was working just fine. I was at a huge reaction time disadvantage to the other players, sure, but shooting at targets worked better at 1 second than RO2 does at 100ms, despite being a much faster paced game. That's not even getting into the older FPS like Rainbow Six, which were made to work in the days of dialup where your average ping was 300ms. If they tried to get away with the default Unreal system back then, they effectively would not have even had a multiplayer mode. FPS' that can't handle latency are very much in the minority.

RTS games are innately more tolerant, to say nothing of MMOs. WoW wouldn't even notice, you can run that on a tin can and string. The default packet rate over there is something like 5 times per second, and then the server will get around to your data whenever it darn well feels like it. -Everyone- is dropped down to a crap connection on WoW.

 

[dazman76]

I was playing Nuclear Dawn a couple weeks back with >1 second latency and it was working just fine. I was at a huge reaction time disadvantage to the other players, sure, but shooting at targets worked better

If that's true, it forms my biggest complaint about client-side authority. If you as the shooter have 1000ms latency, but your target has a respectable 100ms - they would be moving quickly, but to you, they appear to be moving via warping, but at some point are right in your sights. You shoot, your client registers the kill, and you just got handed with the most ridiculous frag imaginable This is basically the "shot behind cover" argument, but without the cover. You absolutely do not deserve that kill, regardless of the fact that "you hit a nice shot when the player was right under your crosshairs". That's like me trying to shoot the president a week after he moved from the spot, then demanding that he dies

Unless I'm missing something here - which is completely possible - this would be a very regular occurrence where any shooter has higher latency than their target. I really don't like that result. While it caters for the shooter, it's ruining things for literally every other player on the server.