Centralized Dual Control

[p7810456]

I want to see if it is possible to add a centralized dual control system rather than one that is per aircraft. This will allow all aircraft with 2 seats to have dual control support, like the one in FSX. One way (in my opinion) is to send the data on different ports through the multiplayer network and use the generic protocol to make it change switches, yoke, etc. I am willing to help since I have some experience in C/C++ but i do not know where to start and I do not know the whole architecture of Flightgear. Thanks for any replies!

[Thorsten]

The Space Shuttle has a couple of hundred switches in the cockpit, the ASK-13 has pretty much none and just flight controls.

The Space Shuttle has an internal state comprised of thousands (!) of properties and Nasal variables, the ASK-13 essentially has no internal state.

Why do you think a centralized system is a good idea when the challenges are so vastly different?

Don't get me wrong, having a common system that manages all that efficiently would be great to have (just like a common save/resume system) - I just don't think that's possible without an unholy amount of work because the way aircraft represent their internal state may vary a lot.

[Hooray]

Yeah, unfortunately Thorsten hit the nail on the head - it's a fairly ambitious undertaking, and one that involves more work than people may think.

Obviously, it would be possible to implement such a system, but sooner or later it would approach the complexity of features we already have - basically, this is all about "state management" - cockpit state in thiss particular case, and you'd want to be able to synchronize/replicate state in a well-defined fashion across multiple fgfs instances (think multiplayer, dual-pilot etc).

Technically, this would sooner or later resemble the approach that ThorstenB took when he revamped the "instant replay" system to become the "flight recorder subsystem": He ended up creating an XML configurable wrapper that allows (and, the point being, requires) aircraft developers to encode relevant state in the form of properties, by assigning types and valid value ranges to them.

This is also heavily overlapping with the way the multiplayer system, and its XDR component are implement - but unfortunately these modules are not at all integrated.
See ThorstenB's comments quoted at: http://wiki.flightgear.org/Redesigning_ ... lay_System

Thus, someone wanting to implement "centralized multi-crew cockpit/controls" is actually asking for a flight-recorder like interface to specify relevant cockpit/aircraft state, and have that encoded in the form of XML/properties that are transparently encoded/decoded using XDR packets - which is also approaching functionality that the generic protocol and teh telnet protocols already have.

For some more background info, refer to: http://wiki.flightgear.org/Reusing_the_ ... n_purposes

As usual, many of these systems were developed with years, and even decades, apart - so that they are often not at all integrated - and then there's also the HLA/DIS effort, as well as various efforts to optimize the existing MP protocol.

Anyway, anybody seriously interested in this sort of thing would be well advised to look at ThorstenB's work in the flight recorder department, and work out a way to hook that up to the networking/MP component, so that the shared control setup can be implemented on top of this layer. This could be accomplished by generalizing the generic protocol system so that it supports XDR directly, which would make it fairly straightforward to come up with an UDP/XDR-enabled SGPropertyNode, along the lines of Erik's original "Remote Properties" idea: http://wiki.flightgear.org/Remote_Properties

The whole idea is regularly re-invented: http://wiki.flightgear.org/Distributed_ ... FlightGear

At that point, many existing features could be easily re-implemented on top of these building blocks, including the multiplayer/dual control component, but also anything involving master/slave setups (i.e. those regularly shown at FSWeekend/LinuxTag).

At the end of the day however, Thorsten remains right: regardless of the system in place, it will require aircraft developers to adopt it, and actually do the leg work to encode relevant aircraft state accordingly, so that the corresponding systems are aware of relevant state - no matter if that is internal/cockpit state or exterior stuff (think animations).

For the time being, Richard's Emesary effort probably remains the best bet: http://wiki.flightgear.org/Emesary

In general, there's quite a few lessons to be learnt by looking at overlapping developments that took place over the years, no matter if that is Emesary, SGRemoteProperty, Torsten's mongoose/AJAX approach or the MP system - what is really needed is someone taking a careful look at these use-cases and working out the interfacing machinery to make this possible, just like Tim did originally with his effects framework, which still is the groundwork for tons of features, despite it not being actively developed these days.