Rubberbanding is really bad with the last update, but I noticed something interesting

[jers]

No matter how crazy the server gets with rubber banding (And boys it's getting really crazy these days), weapons always seem to never be affected.

 

My theory is that the weapons are all server authoritative, I obviously have no way to verify thatbut whatever it is in the netcode that handles the weapons desperately needs to be the way that client aircraft are handled as well.

[Grimes]

Fairly confident weapons aren't synced the same way as all of the other objects. As in the position and orientation isn't handled server side and sent to every single client at whatever rate it sends it. Instead at least some level of tracking is done client side. For example:

 

Client A launches a missile. Network syncs with client B telling them that Client A launched a missile, what type, velocity, orientation, and at what. Then both clients games do the math for how that missile tracks a target. Both clients might see slightly different things based on the launch parameters. If Client A's game determines the missile hit, then it is synced.

 

Saw this behavior play out recently with how other clients didn't see a missile loft. As the shooter my missile lofted, while the other client didn't see it loft. He was able to defeat the missile his system saw, but the "real" one wasn't defeated and he was destroyed.

[Cake]

Wouldn’t it make more sense for client B to determine if the Missile hits? For example, if client A launches a missile that flies 6 seconds toward client B, and 30ms before the missile hits client B maneuvers to defeat it.

 

Client A, which may not have the info yet of the evasive maneuver, thinks it is a kill, so client B is down even though the missile was avoided?

[AMRAAM_Missiles]

I'm not sure if weapons aren't affected though. From the same flight above, just a few second after the capture above, all 3 120C just simply gave up midway even though the 9 Mike was okay.

[Grimes]

It'd require the ability to transfer "control" to the target client, which adds complexity in needing to verify it is a client and potentially handing off control to someone else if it switches targets. Either way one person would feel cheated by the netcode. Whoever shot it is likely just the simplest and quickest solution.

 

Herein lies the joy of netcode synchronization with projectiles. For instance syncing up two objects that can be moving at 300 m/s and another object intercepting another moving at upwards of 800 m/s. Its not exactly hitscan weapons you see with games utilizing high tick rates. With those velocities that 30 ms value is a ridiculously short period of time to defeat a missile, it could be around 30 meters away and cover that distance in within that time. If you did anything in that timespan to make it miss, then chances are it was all ready at least marginally defeated. At those distances any positional error that results in a kill could be chalked up to lag created proximity fusing. Point is at high velocities you can only be so precise with synchronization between clients.

[Lawlcat]

Wouldn’t it make more sense for client B to determine if the Missile hits? For example, if client A launches a missile that flies 6 seconds toward client B, and 30ms before the missile hits client B maneuvers to defeat it.

 

Client A, which may not have the info yet of the evasive maneuver, thinks it is a kill, so client B is down even though the missile was avoided?

 

There's a reason you're never supposed to take the client's word for anything in game networking. Client B could lag switch, or somehow spoof it to say the missile missed every time. Client A would then have to basically accept this fact, even if the missile should have hit and Client B was cheating.

 

On the same point, if it's currently expecting Client A to just say "Hey my missile hit you" then that's also bad. With regards to networking at least, clients should be effectively dumb and report only their current position and actions to the server. The server should then perform the trajectories and analysis if what the client is saying they are doing is possible (to stop things like teleporting). The server should then report positions to the clients (who can interpolate positions between updates for smooth motion, but not for hit registration). It's game networking 101