[NO BUG] AIM120:countermeasure spoofing returned to the old value, Why??

[Datajack]

I am certainly not an expert on this subject matter, but I do clearly remember Nick Grey say in an interview that his goal was absolute realism, even at the cost of game balance. I truly hope this change was done to make the AMRAAM more realistic, because if it was done for game balance (or to make a group of community members happy), then this goes completely against the desires of the company owner. I would be very interested to hear what he has to say about this change.

[Frostie]

I am certainly not an expert on this subject matter, but I do clearly remember Nick Grey say in an interview that his goal was absolute realism, even at the cost of game balance. I truly hope this change was done to make the AMRAAM more realistic, because if it was done for game balance (or to make a group of community members happy), then this goes completely against the desires of the company owner. I would be very interested to hear what he has to say about this change.

Your fears have already been layed to bed as the answer has already been posted by ED only a few posts ago, best use that as reference instead of tin hat conspiracy drama created elsewhere.

Hey guys, this is the answer I received:

 

"Balance has nothing to do with it. Everything is simpler. We first increased AMRAAM's ability to chaff reject on the erroneous assumption that its CCM capability would diminish with the new autopilot and navigation. But the missile capabilities did not diminish, but rather increased. After this was shown to us and we checked ourselves, we returned the old values."

 

I apologize for the delay, we should have had this answer at the time of update. I hope this clears things up.

[gavagai]

It's nonsensical to trigger kills based on a client's PoV' date=' while all other clients see something else. It brings so much inconsistency that even if you tune the other things it will make it extremely hard to monitor the results and determine if something works as intended or not.[/quote']

 

In the 1990s the latency could be over 1000ms for multiplayer dogfighting. Today the combined latency might be 1/5 of that (or less) between 2 clients.

 

What else do you propose? This has been the nature of online air combat since the earliest days. You don't see others as they are, you see them as they were. :)

[TAW_Blaze]

In the 1990s the latency could be over 1000ms for multiplayer dogfighting. Today the combined latency might be 1/5 of that (or less) between 2 clients.

 

What else do you propose? This has been the nature of online air combat since the earliest days. You don't see others as they are, you see them as they were. :)

 

 

You don't understand the problem. I'm sure you've been in a scenario in an FPS game where you shot someone on your client side, you pressed the button, but this was not registered by the server and you died. Nothing happened, the other guy happily lived ever after.

 

Translating the DCS implementation to the above FPS scenario the person you hit on your client side would die afterwards. I can't think of a single FPS game that works like that.

 

To make it worse in DCS you have a lot larger history of movement, especially for missiles or bullets where this has a HUGE impact on the other client side who is trying to defend that threat. If you see desynced bullets going in the wrong direction you might not defend and yet you might still die. If you see a missile on your client crash into the mountain you might still die because on the shooter's PoV it did not. This is madness.

 

 

There are plenty other games including flight sims that managed to get this right.

[gavagai]

No, I haven't experienced that because I don't play FPS games. This is how it has been in flight sims since the old days.

 

It probably has something to do with the velocities inherent in flight simulation. Like, how would you know where to align your gun pipper if the hit detection were server side? Bullets are much faster than people walking/running, but that relative difference isn't as large when the engagement distance is a half-mile and the target is doing 400knots indicicated.

[nighthawk2174]

I am certainly not an expert on this subject matter, but I do clearly remember Nick Grey say in an interview that his goal was absolute realism, even at the cost of game balance. I truly hope this change was done to make the AMRAAM more realistic, because if it was done for game balance (or to make a group of community members happy), then this goes completely against the desires of the company owner. I would be very interested to hear what he has to say about this change.

 

IMHO what has been done is not a realistic depiction of the performance of chaff against missiles. The previous value was just a better representation. Now they did do this not for that specific reason but they should go back to that value for realism purposes or just remove chaff outright till it can be reworked.

[BlackPixxel]

TBH they should remove chaff alltogether, rework multiplayer architecture to get rid of all desync issues and then tune missiles to work well without chaff or any EW. Then subsequently add all these elements.

 

It's nonsensical to trigger kills based on a client's PoV, while all other clients see something else. It brings so much inconsistency that even if you tune the other things it will make it extremely hard to monitor the results and determine if something works as intended or not.

 

Best solution in my opinion would be to always transfer the main missile calculation to the current target of the missile, because the target is what the desync has to be minimized for.

[Coxy_99]

The whole core of dcs needs re work along with its network then things would maybe improve.

[GGTharos]

Best solution in my opinion would be to always transfer the main missile calculation to the current target of the missile, because the target is what the desync has to be minimized for.

 

That was attempted a long time ago and had its own kind of problems.

 

There are ways to deal with the issue, some better than others, but none perfect.

[Noctrach]

The real solution as Coxy mentioned is a complete overhaul of the network code.

 

 

This is just another case in which flightsims lag behind the rest of the games industry by a good amount of time. Shooter games figured out the benefits of a server-authoritative networking structure more than a decade ago.

 

In such a setup, all gameplay-critical calculations (like missile intercepts, snapshots, hit confirmations, etc.) are done by the server. This would eliminate the kind of issues we're having with desync. All missile traffic would be server-sided and clients only get positional updates, resulting in one single unified result. It also greatly reduces the possibility of malicious client activity, since they are not an authoritative source.

 

Example: in an architecture like DCS's a malicious client would technically be able kill you without even firing a missile, just by spoofing the "missile hits target is dead" message sent to the server.

In a server-authoritative setup, the client would request missile fire. If the server deems this a valid request, it will handle the launch and intercept (positional updates to clients) and dispatches the "missile hit or missed" to all clients.

 

 

Downsides to this are obviously that you offload a large amount of work to the server and that latency to server will skew the visual result on the local client (although lag compensation algorithms exist in every FPS game that all but eliminate this aspect).

 

 

Key problem is that it'd require a complete overhaul of the 90s engine extravaganza we have now.

[Jester2138]

Key problem is that it'd require a complete overhaul of the 90s engine extravaganza we have now.

 

The game engine desperately needs this anyway. IMO continuing to make compromise solutions to get around having to rewrite the engine is going to kill the game eventually. ED needs to figure out how to re-do the engine. Whatever it takes. It's never going to be easy, and only ever gets harder and harder to do. We all know that. Just get it done, because the company cannot survive the continuously building technical (and therefore financial) future obligations.

Edited October 3, 2020 by Jester2138

[gavagai]

Can someone explain how server-side hit detection would work in a flight sim with jets moving at 400 knots?

 

I can see how missiles would be handled, but what about bullets (or other unguided weapons)? Even with a good connection, ~50-75ms, we're looking at 10m of discrepancy between the server and the client.

 

----------------

 

P.S. cheating is far more rampant in shooter games than flight sims :)

[dundun92]

Can someone explain how server-side hit detection would work in a flight sim with jets moving at 400 knots?

 

I can see how missiles would be handled, but what about bullets (or other unguided weapons)? Even with a good connection, ~50-75ms, we're looking at 10m of discrepancy between the server and the client.

 

----------------

 

P.S. cheating is far more rampant in shooter games than flight sims :)

And this is why when players have bad ping in BFM you often get hit by bullets from a guy in 30deg lag pursuit

 

Sent from my SM-T580 using Tapatalk

[Noctrach]

Can someone explain how server-side hit detection would work in a flight sim with jets moving at 400 knots?

 

I can see how missiles would be handled, but what about bullets (or other unguided weapons)? Even with a good connection, ~50-75ms, we're looking at 10m of discrepancy between the server and the client.

 

----------------

 

P.S. cheating is far more rampant in shooter games than flight sims

 

Frankly I don't understand why people would think this is a problem... DCS does exactly this on the client side right now. There is literally no difference in doing this on the side of the server.

Actually, there is a difference: Instead of two different results across two different clients, there is now a single unified result. Bam, no more desync.

 

You will always have some discrepancy due to lag, but the discrepancy is identical when it's client-client or server-client. In fact, server-client is usually the shorter route of the two.

Lag compensation.. as long as there's no dropped packets and you have a steady connection, it's not really a problem. 200 milliseconds is about 12 frames, you're not even gonna notice that discrepancy. Your RWR lag is an order of magnitude worse.

 

 

Physics predictions are pretty doable even at well beyond the speed of sound, but it starts depending largely on server tickrate, which in turn affects hardware requirements.

In fact, right now it depends on client hardware to do the same thing. If my client is running at 30 fps, my physics calculations are taking 33 ms to finish on top of your 200 millisecond lag.

The evidence to this is in DCS right now for all to see... in online dogfights bullets will pass far behind an enemy jet and still tear off wings.

 

AAA games have been doing far more complicated things for decades. People just took that for granted because nobody pretended it couldn't be done.

 

----------------------------

 

P.S. Another non-argument. The amount of people playing shooter games far eclipses the amount of people playing flightsims. There's hacking and cheating in DCS all the same. In fact, about half a year back there was someone killing people on a server by simply connecting and executing scripts. There's just not much of a practical advantage to be gained outside of getting 30 people mildly upset for 10 minutes. There's enough advantage to be gained by simply exploiting inherent bugs (Hornet spark plugs anyone?).

Edited October 6, 2020 by Noctrach

[GGTharos]

You could even "cheat" and compute the probability of evading the missile given any type of maneuver at a given time based on the missile's and target's behavior, and you can avoid a lot of lag discrepancy again ... just detonate the warhead and deal damage appropriately.

 

It would be complicated but not impossible to deal with and not impossible to reduce.

[Noctrach]

Exactly, you're never getting rid of lag entirely, but you can compensate to the point that it won't be noticeable. Shooters are impacted far more by this than simulations and they manage this with good result.

[Jester2138]

Love the comments this discussion always gets about how "jets are fast tho." Yeah, but it doesn't matter because it's a fake 3D world with arbitrary scale, and the rapidity and lag-sensitivity of events is still massively higher in any competitive FPS. From a networking standpoint, if modern games like Valorant and R6S can manage the insane chaos of a large match nearly perfectly, there is absolutely no reason DCS can't except decades-old code.

[TAW_Blaze]

Frankly I don't understand why people would think this is a problem... DCS does exactly this on the client side right now. There is literally no difference in doing this on the side of the server.

Actually, there is a difference: Instead of two different results across two different clients, there is now a single unified result. Bam, no more desync.

 

You will always have some discrepancy due to lag, but the discrepancy is identical when it's client-client or server-client. In fact, server-client is usually the shorter route of the two.

Lag compensation.. as long as there's no dropped packets and you have a steady connection, it's not really a problem. 200 milliseconds is about 12 frames, you're not even gonna notice that discrepancy. Your RWR lag is an order of magnitude worse.

 

 

Physics predictions are pretty doable even at well beyond the speed of sound, but it starts depending largely on server tickrate, which in turn affects hardware requirements.

In fact, right now it depends on client hardware to do the same thing. If my client is running at 30 fps, my physics calculations are taking 33 ms to finish on top of your 200 millisecond lag.

The evidence to this is in DCS right now for all to see... in online dogfights bullets will pass far behind an enemy jet and still tear off wings.

 

AAA games have been doing far more complicated things for decades. People just took that for granted because nobody pretended it couldn't be done.

 

----------------------------

 

P.S. Another non-argument. The amount of people playing shooter games far eclipses the amount of people playing flightsims. There's hacking and cheating in DCS all the same. In fact, about half a year back there was someone killing people on a server by simply connecting and executing scripts. There's just not much of a practical advantage to be gained outside of getting 30 people mildly upset for 10 minutes. There's enough advantage to be gained by simply exploiting inherent bugs (Hornet spark plugs anyone?).

 

You described it much better than I could. Currently as far as I know there are a couple of triggers that result in synchronization (shooting, missile active, impact) but between that it's the wild west resulting extreme desync due to being totally independent for dozens of seconds throughout it's flight.

 

Even if you have an extremely poor tick rate like 16 ( most competitive shooters use 64 or 128 ) you would have completely negligible impact of lag because the general position and parameters of the missiles would be consistent between clients. Instead now you have often multiple miles desync with severe altitude and / or guidance showing a missile to be a no factor only for you to explode for seemingly no reason.

 

I'm not sure how bad it'd be for guns, but I'd rather have a robust platform for missiles at a minimal loss to guns (not like the current solution is perfect for guns either, high speed and / or high alpha shots are pretty far off) than the other way around. You'll never be able to implement anything that magically provides perfect solutions for lagging clients in a dogfighting environment anyway.