Synchronize absolute TADS camera rotation instead of trying to calculate the rotation based on player inputs

[FalcoGer]

From my observations, it seems like the method in which the TADS is synchronized between the CPG and the PLT, is that the CPGs inputs are fed to the PLT and then some complex code is used to calculate the same rotation for both clients independently. I propose that instead of synchronizing player inputs, the aircraft state be synchronized instead. Instead of sending "Man track controller x-axis 63% left for 0.08 seconds", you should just send a new tads camera position. This reduces code complexity and, more importantly is easily expandable later on as new systems to move the TADS are added. Code complexity is what breeds bugs and makes finding them, fixing them and expanding the system a time consuming nightmare.

The make my point, current ways to move the TADS are:

• Man track controller - this is the only thing that always worked, I think
• LMC - this was initially broken, leading to desync and is now stable
• Slave to ACQ - this would often have a desynced state initially where it was slaved for CPG but unslaved for PLT, seems stable now
• IAT, this is currently broken, but at least this is known
• Others (turn off and on again and such, any others I might have missed)

From this track record and other similar bugs is where I draw my conclusions about synchronization, because obviously I don't have the actual code, but this allows for some educated guesses. As you can see, it isn't ideal. A synchronization bug was introduced every step of the way which had to be fixed over months.

In the future more systems will be added, which also need to be synchronized, and there is no reason to believe that without changing the method, those will also have problems initially:

• Laser spot tracker (LST)
• Radar Link
• Cued search (unsure if that moves TADS, possibly only with radar link?)

Those would solve itself if only the CPG (or PLT) calculates the TADS new position (this code is needed anyway) for each update and sends that to the pilot, instead of the pilot also receiving the button presses and then more code is needed. This would also improve performance because the pilot doesn't need to compute the TADS position and just gets it's absolute value and perhaps a rotation speed from the CPG instead of having to calculate those values based on the CPGs inputs. This also has the benefit of self fixing if a desync does occur. Code exists once, bugs need to be fixed in a localized, private function if they exists. It's a good time for everybody involved.

A principle in software design is that one thing does one thing. Let the TADS figure out it's position, then call up that position and send it to the pilots TADS. Whatever the current method is has had led to issues every time a new thing was introduced, doubtlessly adding development time to try and synchronize that system. Had a universal way to synchronize the system been implemented from the start, it would have been a lot easier to implement new methods to move the tads and be reasonably sure that it would just plug in and work, with only symbology needing to be synchronized or recalculated.

To put it another way, the things you need to develop:

1. TADS
2. The 8 different ways to move the TADS
3. A single, universal way to synchronize TADS based on where it's looking, with as few special cases as possible, avoiding complexity where at all possible

Or

1. TADS
2. The 8 different ways to move the TADS
3. 8 different, error prone (there were errors), complex code paths to synchronize where the TADS is looking based on what buttons the CPG had pressed.

Just to me it looks like the second option is a nightmare for maintenance, finding bugs and expanding things.

I understand that DCS is complex software, I'm just trying to add food for thought and maybe suggest an alternative way. All roads lead to rome as they say, but some are 3 lane highways and others are not. Please also understand that as a paying customer who has spent hundreds on this software and as a software developer myself, I am frustrated to see those things that to me look like obvious, bad architectural design choices. I don't know what thoughts went into those choices and I can't know. I can't even be 100% certain that those choices are what I think they are even though plenty of evidence points to them, and I don't feel like rummaging through assembly code (probably against ToS anyway). But from my perspective it's just frustrating to watch long times between updates, and every time there is a new sync bug when there is an update.

Edited January 8, 2023 by FalcoGer

[Swift.]

Well put. I've noticed this with a lot of the multicrew systems in the apache. It all seems to be input synced rather than status synced. Which means its tremendously prone to desyncing.

It feels like every multicrew bug that arises is as a result of this kind of desync. There appears to be no way to resynchronise once someone drops for a bit, unless its through an input with only a single possible outcome, ie slaving the TADS to FXD.

[Scaley]

As far as I can see from testing, this is true of all of DCS' netcode, and the track system. All of DCS uses input syncing, meaning (like Swift says) once you are are out of sync unless there is a method to drive the system back to a fixed status, you will remain out of sync forever. There are a few ways round this, which can include changing to a status based code, or can be using intermittent state-updates (like, say, every 30 seconds) that ensure that if a system de-syncs it it automatically brought back into sync at some point. The only way the current code works is if you have such a good connection that there is never any desync, which is practically not possible with current technology on bigger servers or with significant ping times. I suspect that's why most of the MP sync bugs only start showing up in the public beta on bigger dedicated servers with more complex missions and geographically distant players. If you test on a locally hosted MP session with 2 players you'll probably find most of the code works perfectly much of the time. 

Edited January 15, 2023 by Scaley