44 replies to this topic

[TheMightyWashburn]

So ive been playing about a month and I use the forums a lot as some of you may have noticed.

Anyway, I have heard tons of ******** about this "netcode" problem but little explanation of what it is and how it presents itself in game.

NO ANECDOTAL STORIES!

I want someone to be as technical as they can and explain what it is, how it is wrong, and how it is different from other games.

Thank you for your expertise!

[EvilCow]

Very simple,

You hit something from your point of view and it takes no damage, the server does not register it.

This is what is commonly defined a "netcode" problem.

Edit: typo

Edited by EvilCow, 16 November 2012 - 12:44 PM.

[TheMightyWashburn]

EvilCow, on 16 November 2012 - 12:43 PM, said:

Very simple,

You hit something from your point of view and it takes no damage, the server does not register it.

This is what is commonly defined a "netcode" problem.

Edit: typo

I thought it was pretty obvious I meant the technical specifications. You didnt really explain anything.

[Kyrie]

EvilCow, on 16 November 2012 - 12:43 PM, said:

Very simple,

You hit something from your point of view and it takes no damage, the server does not register it.

This is what is commonly defined a "netcode" problem.

Edit: typo

^^ This. Or more dramatically: You see a shutdown mech. You stop. Both you and the target are not moving. You alphastrike the target, still unmoving, and despite the red flash on the reticle, the damage does not register.

These problems can happen for a variety of reasons. One possible example is that the actual "hitbox" does not match the mech figure drawn on your screen; this then gets exacerbated dramatically when the mechs are in motion relative to each other. Another compounding factor is that since each "hit" is validated by the server (example, your PC sends a packet to the server saying: my_mech fired laser from position (pos X, Y, Z) at angle (angle) and I should have hit target_mech at position X,Y,Z; server then decides whether that hit really happened.) If the server thinks that you or your target were in fact not in the positions your packet said you were when pulled the trigger.... you missed despite seeing it as a hit visually.

[Dagger6T6]

http://webhome.idire...ag_shooting.htm

the links above explains it in terms of Mechwarrior 3... but we have essentially the same situation right now

[Tickdoff Tank]

Start here: http://www.jason35.com/netcode.htm

[LordBraxton]

Simple as my simple mind can understand

We are on server side hit detection quiaff?

So its the servers that don't know how to 'place' clients in the world when they are moving above 100 or so.

Pure lack of server power? Or limitations to the cry engine? I'd like to know more myself, I have a feeling the technical side is fairly different from MW3s probs.

[TheMightyWashburn]

Tickdoff Tank, on 16 November 2012 - 12:55 PM, said:

Start here: http://www.jason35.com/netcode.htm

thank you

[Virtusx]

The short version. Hits and where mechs are located are determined by the server. Since your client and the server are in two different locations, there is a difference in where the client shows you they are and where the server knows they are. Example is that the Jenner running full tilt 120+ shows on your screen as X but the server sees them as X+1 meters so you fire but the servers sees it as firing behind him.

Edited by Virtusx, 16 November 2012 - 01:00 PM.

[PhigNewtenz]

Tickedoff Tank's link is a very good answer to your question. Here's my qualitative description of the problem in today's most popular terms: gosh-darn-light-speed-circle-of-death-Jenners.

Suppose you're trying to shoot someone. For this example, we'll use me piloting my mangy 149kph Jenner. From a networking standpoint, this is a problem with three participants: Your client, my client, and the server.

The 'netcode' issue that people are complaining about arises in the challenge of making things appear to happen simultaneously for all three participants.

There are two communication links at work here. One connects your client to the server, and the other connects my client to the server. Sending a signal over each link has a delay associated with it. This is essentially what your pink is measuring.

When you try to shoot me, a 'hit detection' problem needs to be solved. Using: your location, your aim direction, the speed of your shot, and my location at the time the shot hits/passes me, an algorithm has to determine whether or not there was an impact. Unfortunately, non of the three participants in this problem has all of the required information:

• Your client knows where you are and where you are aiming at the instant you press the trigger.
  
• My client knows where I am at the instant you press the trigger.
  
• At best, the server won't know these things until messages sent from our clients reach the server. Sending these messages takes time on the order of tens to hundreds of milliseconds.

Now at this point, you could be saying, what's the big deal? It take some milliseconds to get the data all in one place on the server, but then the calculation can be done, no problem, and voila! We know if there was a hit.


There is (isn't there always!) something else at work here. The question is: what were you aiming at? Your client rendered and displayed on your screen an image of my Jenner streaking across the battlefield. You aimed at that image and you fired.

But was that an image of my actual location? Well, sort of. Your client's estimation of my location is based on the information your client received from the server, which was sent some time in the past. The server based that information on a message sent by my client some time even farther in the past. Who's information was correct? Well, 'netcode' would answer: everyone's.

The 'netcode' tries to minimize the difference between what your client is telling you, and what my client is telling me. If you register a hit on your screen, then that should count as a hit, right? But what if I juked at the last second and, on my screen, successfully evaded your strike? Do you see a hit, I see a miss, a hit is registered anyway, and I get angry? Do you see a hit, I see a miss, a hit is NOT registered, and you get angry?

The answer to that last question is a yes for most of the 'netcode' problems we're seeing now. The difference between what you see and what I see gets bigger if:

• The mechs are fast (Damnable Jenners!)
  
• There is a large delay (Go Lag-Shield!)

Better 'netcode' will resolve these conflicts more proactively. It will likely:

• Allow your client to better predict my current location based on where I was and where I was going and at what speed, etc.
  
• Allow my client to correctly see whether or not you've hit me (with, of course, a slight delay for it to figure out if you've hit me)

Hopefully it gets straightened out soon. I know you asked for a technical answer, and I hope this helps. I'm not sure you want to hear about packets and networking protocols and switching delays and server ticks and other other low-level internet operations. I can answer a lot of those questions (so can Wikipedia and Google). If you want to know about the proprietary techniques that PGI and other companies use to solve this problem, I'm not your man. Companies keep specifics like that pretty close to the vest.

[endeceive]

There's also a big issue with the client side prediction, like when you try to go over fairly big pipes in the Caustic Valley map.

The client predicts that you can go over it, so you start moving up.

The server disagrees, so after a fraction of a second you snap back down to where the server says you actually are.

The client, ever the optimist, still thinks you can go over, so you start lifting up again...

This results in that annoying jittery up-and-down motion. It also happens when you're trying to walk past a mech but you're brushing it; it seems like the client doesn't take mechs into account at all, but the server treats them as completely blocking, so you end up jittering back and forth until you get past them.

I think a lot of this could be fixed if the client's predictions more closely based what the server was actually going to do, especially when it only involves one mech interacting with the environment.

[Keifomofutu]

"It's bad"

[nitra]

TheMightyWashburn, on 16 November 2012 - 12:39 PM, said:

So ive been playing about a month and I use the forums a lot as some of you may have noticed.

Anyway, I have heard tons of ******** about this "netcode" problem but little explanation of what it is and how it presents itself in game.

NO ANECDOTAL STORIES!

I want someone to be as technical as they can and explain what it is, how it is wrong, and how it is different from other games.

Thank you for your expertise!

kinda hard to explain when we have no technicalities to feed off of.

no dev has given us any details on what the underlying problem/problems is .

we just now they reference issues such as collision issues and weapons not hitting properly to be attributed to the netcode.

the previous linkage by tikedoff tank and phig will help in understanding what we are talking about .

but as far as what is exactly wrong . we have no idea except that it is broken.

3PV

Edited by nitra, 16 November 2012 - 02:20 PM.

[The Herrick]

Hitboxes aren't where the mechs appear to be. Most of the time they hover few feet ahead, the precise distance varies frequently.

Additionally, when firing weapons you can press the button and see the shot only to have the ACTUAL attack happen a moment later. This is for all guns but naturally missiles and ballistics are most affected by it.

[Avin]

Do a google search on "message ordering" or for a more text book explanation: http://www.cs.uic.ed...yk/Chapter6.pdf


In short, it doesn't matter how good the developers are all they can do is try to make lag less obvious to the players (PhigNewtenz post is quite good). People are saying "Fix the netcode! Now!" and the truth is it cannot be "fixed" (at least not in the way everyone would want it to be). All they can do is put algorithms and such in place to make it less obvious and some of those algorithms won't work in all situations (weapons fire v's collisions and knockdowns for example).

The only way to reduce lag is to have the servers geographically located near the players. This obviously isn't practical when one team is in Australia and the other is in the US. Its simply not possible to geographically locate both teams at the same time.
Another option (as some of the bigger MMOs do) is to have servers that are all in the same country (US usually) but encourage players from the same geographic location to play on them. World of Warcraft is an example of this. They have American, AsiaPac and European servers... that are all physically located in the US. This just means that you're likely to have a level playing field for all the players on a particular server ie: they all suffer from roughly the same amount of lag.

Splitting up the player base like that has its downsides however as it reduces the number of viable opponents for a given match/game/dungeon/whatever *cue Matchmaking discussion*. While "fixing the netcode" is the highest issue on the dev teams list at the moment what they are really doing is wrestling with what's the best way to make lag less obvious to the players and what are they going to trade off against to do that; *cue discussion on hitboxes, knockdowns and collisions*.

MWO is an extremely ambitious project. Think Eve Online ambitious. We got any Eve players with bad lag who can comment? I'm a fan of the Battletech lore, I actually quite like what they've done with the game so far and I'm very interested in how they address these issues.

[TheSneak]

Weapon convergence adds another complication - AFAIK your weapons converge at the ranges you see on your client-side (which is wrong). So when you lag-lead a light mech your weapons will be converged on a point hundreds of metres away (because you're not 'aiming' at the mech, your aiming at 'vacant' space in front of it) so even if you hit* your weapons probably wont hit one point. This depends on how far away your target is - problem is worse the closer your opponent is, also depends on background terrain determining where your weps converge.


In summary: fml.


*not a guarantee!

[nitra]

Avin, on 16 November 2012 - 03:02 PM, said:

Do a google search on "message ordering" or for a more text book explanation: http://www.cs.uic.ed...yk/Chapter6.pdf


In short, it doesn't matter how good the developers are all they can do is try to make lag less obvious to the players (PhigNewtenz post is quite good). People are saying "Fix the netcode! Now!" and the truth is it cannot be "fixed" (at least not in the way everyone would want it to be). All they can do is put algorithms and such in place to make it less obvious and some of those algorithms won't work in all situations (weapons fire v's collisions and knockdowns for example).

The only way to reduce lag is to have the servers geographically located near the players. This obviously isn't practical when one team is in Australia and the other is in the US. Its simply not possible to geographically locate both teams at the same time.
Another option (as some of the bigger MMOs do) is to have servers that are all in the same country (US usually) but encourage players from the same geographic location to play on them. World of Warcraft is an example of this. They have American, AsiaPac and European servers... that are all physically located in the US. This just means that you're likely to have a level playing field for all the players on a particular server ie: they all suffer from roughly the same amount of lag.

Splitting up the player base like that has its downsides however as it reduces the number of viable opponents for a given match/game/dungeon/whatever *cue Matchmaking discussion*. While "fixing the netcode" is the highest issue on the dev teams list at the moment what they are really doing is wrestling with what's the best way to make lag less obvious to the players and what are they going to trade off against to do that; *cue discussion on hitboxes, knockdowns and collisions*.

MWO is an extremely ambitious project. Think Eve Online ambitious. We got any Eve players with bad lag who can comment? I'm a fan of the Battletech lore, I actually quite like what they've done with the game so far and I'm very interested in how they address these issues.

the eve dev articles on their battles with lag and issues that caused server side lag are fascinating .

the whole drake causing the huge battles to slow to a stop or drop connection was particularly insightful as they were able to trace down the exact issue and found that all the missels being spammed by drakes were causing huge issues with the server in keeping up the action.

what was even more impressive is how they were able to hammer out the code and actually get it more optimized and working better .

In the end however and because they are working with an ancient gaming engine. they created a technology they called Time Dilation

Eve Online should be a case study in how to make a proper MMO for any budding MMO startup .

as the hurdles they have faced and the technical challenges they accomplished are sometimes mind blowing .

no other mmo has accomplished what eve has.

it is one of the games that i use as a metric for measuring for how far we have come in gaming technology .

unfortunately no other game has surpassed what they have accomplished.


eve fun fact : the core eve engine is a single threaded application.

Edited by nitra, 17 November 2012 - 01:19 AM.

[elbloom]

I´ve never seen a thread where PGI explains some of the actual problems they have with their code.

I sincerely hope they know what they´re doing...

If you drive a fast mech the problem is too obvious, you´ll get to see it when you chase another light and try to hit him. You have to hit the air before him else you will hear your laseres burning armor, but no damage will register !

You HAVE to hit AIR ! with no client indication of a hit - but it will register with the server somehow, it´s disgusting for a FPS.

[xenoglyph]

I had an idea for a system to reduce lag, not sure if anyone's ever tried it before.

Basically, game server caches game state for 250ms or so. Game client, when sending weapon fire requests, sticks a timestamp accurate to the millisecond on that datagram/packet. When game server receives request it goes back in time to the specified timestamp to calculate hits. Wouldn't eliminate lag, but would help quite a bit I think.

Edited by xenoglyph, 17 November 2012 - 01:49 AM.

[Budor]

Avin, on 16 November 2012 - 03:02 PM, said:

World of Warcraft is an example of this. They have American, AsiaPac and European servers... that are all physically located in the US. This just means that you're likely to have a level playing field for all the players on a particular server ie: they all suffer from roughly the same amount of lag.

The european servers for world of warcraft are physically located in france and in germany (not sure if the french datacenter still runs or if they migrated everything to germany). I wish MWO had european and asian/pacific servers to...

Edited by Budor, 17 November 2012 - 01:50 AM.