The current MP-co-piloting is slow (network) and has in most planes bib problems. For example when I fle as co with KL-666 in a 747-8i, I couldn't see instruments or look out of the windows (the HUD told me anyway what I wanted to see, so it was good for me anyway, but's that's not the purpose).
the existing MP system was never designed with such requirements in mind, the dual pilot add-on was developed by AndersG on top of the existing system (and all its limitations), and it is using generic properties and chat to extend things beyond the original design concepts. Thus, you could also extend things even more - but there's no explicit support for stuff like this, and we're all hesitating to touch the MP code due to the HLA efforts.
The idea is, and maybe it's a stupid idea, but if I can get for example two local computers on one plane (pilot and co-pilot) and get all this data together on the level of my local network, it would be for the MP-network not more of a burden than ONE plane with ONE player while the coordination in the local network would be clearly faster and thus enable a real co-piloting.
this could be done by making creative use of existing features - for example by having your own fgms MP server in your LAN, and setting it up as a relay.
But as I say, it's maybe a stupid idea running into thousand technical problems.
Well, two FG instances can also be hooked up without fgms - so the dual pilot addon could probably be modified to work with such a setup.
Basically, it requires creative use of existing features, like for example master/slave setups - you could set up two instances to use the dual-pilot add-on, and then set up a slave instance that is driven by it, where only the slave instance would have an actual connection to the MP network. The two instances/computers running the pilot/copilot stuff would be "offline" and just mirrored by the slave instance.
It's not impossible with some tinkering, but it was never designed to work like that, so requires willingness to experiment a little and read our docs, interpret them in novel ways - and ideally, document the whole process for people doing something similar.
Without ever having done anything like this, I don't think that it will work "out-of-the-box", i.e. it will almost certainly require tinkering with 1) XML, 2) properties, 3) Nasal and 4) various network settings (dual pilot, master/slave setups and MP)
https://www.draw.io/#LJabberwocky