Board index FlightGear Development New features

Global Feature Suggestion for FlightGear: Cockpit Sharing

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

Global Feature Suggestion for FlightGear: Cockpit Sharing

Postby CaptainTech » Tue Dec 29, 2015 2:30 pm

Hello, FlightGear Pilots.
It's a beautiful day today. Clear weather, good Air Pressure and 6 knots of Wind.
But I've got a feature suggestion for the multiplayers here:


It would be a great feature, if multiplayer mode could allow two or more online or local network players to share one cockpit. Is this already possible or not yet?
Then one player can be the captain, another one the first officier, and the third one is the flight engineer. Maybe another second officier :mrgreen: That can be a great fun.
In multiplayer mode, somebody wanted to be my Co-Pilot, so I decided to put this Feature Suggestion into the forums.

It would really be great to have Cockpit Sharing as a Global feature. Maybe in FlightGear 3.8.0, if possible.;)
CaptainTech
 
Posts: 67
Joined: Wed Sep 02, 2015 7:12 pm
Callsign: CaptainTech
Version: Newest
OS: Windows 7 Ultimate

Re: Global Feature Suggestion for FlightGear: Cockpit Sharin

Postby Thorsten » Tue Dec 29, 2015 2:32 pm

Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Global Feature Suggestion for FlightGear: Cockpit Sharin

Postby CaptainTech » Tue Dec 29, 2015 2:36 pm

Thorsten wrote in Tue Dec 29, 2015 2:32 pm:http://wiki.flightgear.org/Dual_control

Ah great! A340 is supported.
But I would really like the 777, A380 and the 707 to be supported too. I really love my darling 777
CaptainTech
 
Posts: 67
Joined: Wed Sep 02, 2015 7:12 pm
Callsign: CaptainTech
Version: Newest
OS: Windows 7 Ultimate

Global Feature

Postby CaptainTech » Tue Dec 29, 2015 2:43 pm

And it would be great as a Global Feature
CaptainTech
 
Posts: 67
Joined: Wed Sep 02, 2015 7:12 pm
Callsign: CaptainTech
Version: Newest
OS: Windows 7 Ultimate

Re: Global Feature Suggestion for FlightGear: Cockpit Sharin

Postby Hooray » Tue Dec 29, 2015 2:50 pm

please elaborate - and please consider spending a few minutes to learn how the feature is currently working.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Global Feature Suggestion for FlightGear: Cockpit Sharin

Postby Thorsten » Tue Dec 29, 2015 4:44 pm

I'd like all planes to have realistic flight dynamics as a global feature. Unfortunately they're all different, so it has to be done plane by plane :-)
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Global Feature Suggestion for FlightGear: Cockpit Sharin

Postby Hooray » Tue Dec 29, 2015 4:50 pm

Thorsten wrote in Tue Dec 29, 2015 4:44 pm:I'd like all planes to have realistic flight dynamics as a global feature. Unfortunately they're all different, so it has to be done plane by plane :-)

To be fair, AndersG implemented the whole system in scripting space - it would be possible to support the whole thing in a "global" fashion with a handful of minor additions, mainly based on looking at related subsystems, e.g. the "instant replay" (flight recorder) feature - and hooking that up to the multiplayer system by XDR-encoding the corresponding properties.

The main thing that aircraft developers would still have to do is to create a corresponding "flightrecorder" configuration for their aircraft/cockpit to encode the transmission/update semantics accordingly.

This could be handled by using XML attributes which are parsed by C++ code to automatically register the corresponding XDR helpers.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Global Feature Suggestion for FlightGear: Cockpit Sharin

Postby Thorsten » Tue Dec 29, 2015 7:23 pm

I'm sure you can right now imagine how to make the Space Shuttle dual control capable with just a handful of additions, but admittedly I can't even imagine what it'd take. :-)

(I frankly have my doubts that the MP protocol is suitable to transmit even the internal state of the orbiter without some very serious custom encoding...)
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Global Feature Suggestion for FlightGear: Cockpit Sharin

Postby Hooray » Tue Dec 29, 2015 7:42 pm

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 ... ementation

So 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)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU


Return to New features

Who is online

Users browsing this forum: No registered users and 6 guests