Point well taken, I was not thinking about the space shuttle, but a conventional airplane - you are right that more complex cockpits/aircraft require more changes.
But under the hood, it is mainly about formalizing state management - which is overlapping with the way the flight recorder has to work, but also the MP protocol.
To some degree, you can model this analogous to entities (objects) with varying access specifiers (think public, protected and private state).
private state would only ever be mutated by the locally running fgfs instance, while public/protected state would need to be channeled through a wrapper.
You are right that the MP protocol is not sufficiently flexible for this in its current form, but the way AndersG has implemented the Dual Control system, it is piggy-backed on top of a transport mechanism using "string" properties, which are used as the transport mechanism for "I/O channels" on top of Nasal data.
Like you say, HLA should make these things much easier.
However, let's be honest: any aircraft that 1) supports multiplayer and 2) supports the flight recorder/replay feature and 3) distributed setups (like those at FSWeekend/LinuxTag), could /in theory/ also support "Dual Control" - certainly once/if the underlying systems are merged.
The building blocks to make something like this possible are already there - the difficult stuff is convincing aircraft developers (like yourself) to adopt the corresponding systems (multiplayer and the flight recorder).
So the whole "global" thing would be possible to pull off, but it should not be done using Nasal and the existing MP system.
In the case of the shuttle, or even just complex airliners, formalizing data dependencies (switch states, annunicator states etc), that would be tons of work to do manually, given the plethora of switches and state indicators - which is why I am not convinced that this should be done manually, but done semi-automatically by annotating properties (and possibly even branches of properties in the tree).
A while ago, I did experiment with replicating a Canvas-based PFD/ND display in another fgfs instance using the "brute force" approach - i.e. copying the whole property branch of the corresponding Canvas via telnet and patching it up via Nasal subsequently, the whole thing was not very elegant, but it actually worked.
So I do understand how difficult this is, as well as the limitations of the current system - however, if aircraft/cockpit developers had a handful of property attributes to differentiate between different kinds of simulator state (local/remote vs. switches vs. displays), it would be possible to pull this off, pretty much by using the existing technology stack - the main limitation would be bandwidth then, i.e. you would have to be on the same LAN as the other instances, because it simply isn't feasible to replicate a PFD/ND using low-level calls (primitives) - instead, the whole instrument logic would need to be running in each fgfs instance, with only events being propagated accordingly - i.e .in a master/slave fashion.
Admittedly, this is a restriction/challenge that even recent MFD cockpits are sharing with ODGauge-based cockpits (think wxradar, agradar, navdisplay etc), but that does not have to be the case necessarily, because we can already readily access all the internal state by looking at the property tree.
But even if such a system were in place today, the way we are using Nasal and Canvas to create MFDs would need to change, i.e. to formalize data dependencies, and to move away from low-level primitives that are only understood by Nasal code - which is to say that new Canvas-based features (e.g. MFDs) would need to be themselves registered as Canvas::Element instances, implemented in scripting space, to ensure that a sane
property-based interface is provided and used, without adding explicit Nasal dependencies all over the place:
http://wiki.flightgear.org/Canvas_Devel ... ementationSo we would need both 1) an updated transport/IPC mechanism, and 2) a better way to encapsulate Canvas-based features in a way that properties are the primary I/O means, which is ironically how hard-coded instruments are working already - we are just violating the whole design concept via Nasal currently, which is also making it more difficult to augment/replace Nasal-based components that turn out to be performance-critical.
Given that HLA seems to become increasingly relevant, it does make sense for subsystems to primarily use the property tree for IPC, but to also stop having the assumption that other properties are directly accessible, because an instrument may be created/provided or running by a separate process/computer in a few years time, including Canvas-based MFDs.
(Note that this is exactly what ARINC661 and CIGI are all about)