Board index FlightGear Development Aircraft

IDG A32X Development Archive - Closed

Questions and discussion about creating aircraft. Flight dynamics, 3d models, cockpits, systems, animation, textures.

Re: IDG A32X Development

Postby vaipe » Tue Jan 02, 2018 10:27 am

Wow... there is a lot to digest with this multicompiting/monitor share issue... Maybe one option could be to invest enough €'s into PC/GPU to run all monitors from one machine.
vaipe
 
Posts: 12
Joined: Thu Dec 18, 2014 12:15 pm
Location: Finland
Version: 2017.3.1
OS: Ubuntu 17.10

Re: IDG A32X Development

Postby Hooray » Tue Jan 02, 2018 1:34 pm

it0uchpods wrote in Mon Jan 01, 2018 5:41 pm:I think you and I are talking about different things, I am speaking about dual control. I do not want Emesary to act on the Canvas itself, as the lag in updates may cause the displays to display incorrect/strange information. Instead, the Systems on the Master side and Slave side would talk to each other, for example:


We really weren't talking about different things at all - even your suggested approach is overlapping with mine.
The thing however is that this sort of thing becomes messy fairly quickly
You really need to design, develop and maintain all your aircraft systems code with these requirements in mind, i.e. the master/slave setup (think multiple inter-connected fgfs instances, but also the multi-crew use-case).
Overall, this has very much to do with the way the MP system works, the way the flight recorder subsystem has to track certain properties and serialize them - but also the way saving/loading and resuming a flight would have to work (think reset/re-init).

The way we're have been seeing aircraft developed for FlightGear doesn't easily lend itself to this sort of "distributed setup", certainly not with additional hooks provided at the infrastructure/systems level.

From a Canvas standpoint, it's relatively easy to deal with this by just "streaming" either the final image, or the underlying properties (data) - but many other systems cannot as easily support the distributed use-case

vaipe wrote in Tue Jan 02, 2018 10:27 am:Wow... there is a lot to digest with this multicompiting/monitor share issue... Maybe one option could be to invest enough €'s into PC/GPU to run all monitors from one machine.


That is possible, but people wanting to display a Canvas MFD in a separate window, would still require dedicated C++ code for that - because the existing CameraGroup/View stuff isn't at all integrated with the Canvas system.


it0uchpods wrote in Mon Jan 01, 2018 5:41 pm:Where is this feature request? Maybe I am blind, but I do not find it. Is it just the mailing list?

I guess many things got lost during the gitorious/gitlab shutdown/transition - I'd probably use the issue tracker for that, because these discussions (forum topics) don't seem to work very well after all. As a matter of fact, even the wiki seems to work better to gather feature requests and ideas than using the forum or the devel list ...

This is not to say that anyone is going to start working on this anytime soon, but it's at least a good way to measure interest/support (or even just feedback) - especially if people interested in this (say airliner/biz-jet developers) share the link to the feature request with others, and encourage them to leave their feedback there: https://sourceforge.net/p/flightgear/codetickets/
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: 11987
Joined: Tue Mar 25, 2008 8:40 am

Re: IDG A32X Development

Postby Octal450 » Tue Jan 02, 2018 2:54 pm

Hi Hooray,
Makes sense, but with the simple nature of how I design my systems, with a controls "layer", a logic "layer", and output "layer", it shouldn't take too much work to make it work, but I won't be looking deep into it until we begin to actually add dual control closer to V1.0, or, at least, when all the cockpit elements are functioning. Still, I am against Canvas streaming, as it means the display won't be connected in real time to the systems, which would cause bad behavior.

I'll probably be away for a bit for medical reasons, so I will look into the external Canvas when I get back

Thanks for the insight.

Kind Regards,
Josh
What I do: Flight Dynamics, Systems, Canvas Displays, Autoflight, FlyByWire, Cockpit Animations
Aircraft I currently develop: MD-11 (Mainly), Secret, A320-family (Quality over Quantity)

My GitHub|MD-11 and ITAF Dev Discord|Airbus Dev Discord
User avatar
Octal450
 
Posts: 4716
Joined: Tue Oct 06, 2015 12:51 pm
Callsign: WTF411/Octal
Version: next
OS: Windows 7/10 x64

Re: IDG A32X Development

Postby Hooray » Tue Jan 02, 2018 6:03 pm

simply streaming a canvas does have its pros & cons - but usually, this makes really only sense to evaluate in a non-LAN setting, where roundtrip times (latencies) are an actual issue. Assuming a sufficiently fast connection (local network), streaming a Canvas to another fgfs instance/process (browser) is a simple and effective way to solve the problem.

Other than that, the terminology "real time" is at best an illusion given FlightGear's architecture - there are far more critical issues (think subsystems) that conflict with these terms, regardless of the Canvas and Nasal systems.

If your separation into "layers" would suffice to actually implement any kind of master/slave synchronization depends largely on how you structure everything - my suggestion would definitely be not to work on anything related to this unless you understand how related features, namely MP, dual-control, the flight recorder system and especially Emesary relate to this - if in doubt, I'd suggest to get in people with the folks who have actually worked out these systems.

For the same reason it may be interesting to get in touch with Thorsten or just look up what he said about "state vector" management in the context of the shuttle's capability to load/resume certain flight scenarios.

Speaking in general, FlightGear is not currently designed with any of this in mind, which is why we are seeing so many different implementations and underlying approaches that are basically trying to solve the problem still.

Which is to say, even just doing one weekend of research looking up what Erik (Remote Properties), Oliver (fgms), AndersG (dual-control), ThorstenB(fgtapes), wlbragg (state overlays), Richard (MFD/Emesary), Thorsten (shuttle) and others have said (and done!), may literally save you months of your precious spare time pursuing potential dead-end approaches.

If in doubt, try to put your own background into perspective and consider for yourself how likely it is that you are going to come up with something that these people haven't already thought about, inspite of their massive cumulative track record contributing to the project.

We are standing of the shoulders on giants here - but only if we look up what's been previously said and done and if/how that may relate to your own work.
I am saying that because there are countless examples of features that were literally coded for months without taking into account existing work related to such features.
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: 11987
Joined: Tue Mar 25, 2008 8:40 am

Re: IDG A32X Development

Postby vslash » Tue Jan 02, 2018 6:22 pm

and perhaps a good way to avoid all the unnecessary work you're talking about - I totally agree with you on this - would be to suggest that authors document their own work. A coding or a project without full doc. and / or working examples remains only half done. Hence perhaps a lack of use, misuse or misunderstanding.
vslash
Retired
 
Posts: 39
Joined: Fri May 27, 2016 9:43 pm
Location: Paris
Callsign: FGX412
IRC name: vslash
OS: BSD

Re: IDG A32X Development

Postby Octal450 » Tue Jan 02, 2018 6:54 pm

A full documentation on how to use the craft will be added along with video tutorials by V1.0.

Hooray wrote:simply streaming a canvas does have its pros & cons - but usually, this makes really only sense to evaluate in a non-LAN setting, where roundtrip times (latencies) are an actual issue. Assuming a sufficiently fast connection (local network), streaming a Canvas to another fgfs instance/process (browser) is a simple and effective way to solve the problem.

I don't know what you mean here. How does streaming Canvas is better over linking the systems? That way, even on LAN, the displays are still connected with the systems, plus, if the connection is lost, both users can continue the flight normally, since the systems are all ready up and running.

Hooray wrote:If your separation into "layers" would suffice to actually implement any kind of master/slave synchronization depends largely on how you structure everything

Let me explain it a bit more:
* The controls "layer" is the switches, the inputs.
* The logic "layer" process the information, and conditions
* The output "layer" is the outputs, which go to other systems, displays, and lights.

Syncing a display will not, for example, power up the hydraulic flight controls, or cause the RAT to extend, the system must be synced to do that. Just sending the thousands or thousands of properties over is much worse, than simply, for example, sending hash of states which are used by the systems to sync data. Then, the systems could drive the related properties, and everything else "just works".

No offence to the developers, but the dual-control system doesn't work well at all. I can't name a single plane where it works completely properly. Emesary looks more promising, and by only syncing systems state, flight controls, sidestick commands, and basics, like position, attitude, and such, instead of worrying about sending everything over, while the copilot is just in a "dummy" aircraft which doesn't do anything.

Kind Regards,
Josh
What I do: Flight Dynamics, Systems, Canvas Displays, Autoflight, FlyByWire, Cockpit Animations
Aircraft I currently develop: MD-11 (Mainly), Secret, A320-family (Quality over Quantity)

My GitHub|MD-11 and ITAF Dev Discord|Airbus Dev Discord
User avatar
Octal450
 
Posts: 4716
Joined: Tue Oct 06, 2015 12:51 pm
Callsign: WTF411/Octal
Version: next
OS: Windows 7/10 x64

Re: IDG A32X Development

Postby Thorsten » Tue Jan 02, 2018 7:21 pm

No offence to the developers, but the dual-control system doesn't work well at all.


I think it's fair to say it's not intended to work for complex aircraft and generally does not. We're facing the same issue with the Shuttle - while it would be cool to share ops, the internal state is just too huge to be synchronized in any realistic way.
Thorsten
 
Posts: 11752
Joined: Mon Nov 02, 2009 8:33 am

Re: IDG A32X Development

Postby Hooray » Tue Jan 02, 2018 7:36 pm

Thorsten hit the nail on the head - there's a certain point where the complexity of the simulation will make it impossible to support such use-cases, unless you begin explicitly designing your systems simulation accordingly - and that applies not just to "dual control", but also the underlying multiplayer protocol as a whole - as well as any other feature that requires a well-formalized way to do proper "state management" (think reset/re-init, saving/loading and resuming flights, but also the flight recorder (instant replay) system).

Sooner or later, it only makes sense to propagate relevant events (state changes) and have each instance runs its own systems simulation - but that isn't as atrivial as it may sound, because the more sophisticated your simulation is becoming, the more complex your synchronization heuristics would have to be, too.

The "dummy aircraft" simplification you mentioned may seem odd at first, but you literally need a master/slave separation in place - otherwise, you are approaching mind-boggling complexity, not unlike trying to sync a weather system across multiple fgfs instances, with each instance creating its own weather phenomena - thus, a master/slave setup does make sense - even in an actual airliner, there is the notion of system priority ("precedence") - i.e. being able to override inputs from one pilot.

Without being familiar with the shuttle specifically, complex state vectors (think hundreds and possibly thousands of "properties") can only be sync'ed across multiple fgfs instances in a reasonable fashion in a high-bandwidth setup, which will usually mean local area network (LAN)

Even if you aren't planning on using the dual-control in any of your own aircraft, if you are interested in tackling this properly, you can learn a lot from the way it is implemented, i.e. from a limitations perspective - that in and of itself will be a valuable lesson. For the same reason, it does make sense to understand how the fgtape system works, and how it has requirements that are overlapping with the MP system, and how the MFD/Emesary integration may help tackle some of these in a holistic fashion, without having to wait another decade for a working HLA/RTI integration.

Basically, even if you ignore what is working and what isn't, it'd be a good idea to look at the underlying source code (especially referring to the dual-control stuff)
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: 11987
Joined: Tue Mar 25, 2008 8:40 am

Re: IDG A32X Development

Postby Octal450 » Tue Jan 02, 2018 7:48 pm

Hi guys,
Yes, that makes sense too.

Only time will tell if merspieler and I can get it working. (And it will be great to test, since we are in different countries!) We still may have over a year before they reach V1.0, so I'm not really worrying about it quite yet. I still have to deal with my medical problems, so I'm not putting that much time into developing at the moment.

Kind Regards,
Josh
What I do: Flight Dynamics, Systems, Canvas Displays, Autoflight, FlyByWire, Cockpit Animations
Aircraft I currently develop: MD-11 (Mainly), Secret, A320-family (Quality over Quantity)

My GitHub|MD-11 and ITAF Dev Discord|Airbus Dev Discord
User avatar
Octal450
 
Posts: 4716
Joined: Tue Oct 06, 2015 12:51 pm
Callsign: WTF411/Octal
Version: next
OS: Windows 7/10 x64

Re: IDG A32X Development

Postby Hooray » Tue Jan 02, 2018 7:56 pm

Yes, the point really never was to make you adopt/use or build a certain system, but to provide pointers that hopefully enable you to better understand the underlying problem and challenges, and what has been previously tried to solve these (depending on priorities obviously), and by whom.
For the time being an IPC-enabled approach is most promising - and given that we don't have an actual HLA/RTI implementation available, Richard's Emesary approach is most likely to come in handy here, especially given Stuart's recent FG1000 work, which caused Richard to integrate his Canvas MFD framework with the Emesary system.

I usually recommend that people interested in using FlightGear for combat/dog-fighting purposes, do check out flug's existing groundwork (the bombable addon) oretty much for the same reason, - which is not to say that anybody would actually have to use any of his work/code or the Nasal approach itself, but flug actually solved a bunch of problems in a rather compelling fashion, using fairly creative methods -without ever touching a single line of C++ code but that still doesn't mean that it will magically turn FlightGear into a combat simulator.

Equally, people interested in a creating weather simulation in FlightGear would be well-advised to look at "prior art" - i.e. Thorsten's Advanced Weather system, as well as Torsten's Basic Weather System. And for the same reason, I would suggest that people interested in deferred rendering capabilities do check out Rembrandt and ALS and see if/how these relate to one another.
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: 11987
Joined: Tue Mar 25, 2008 8:40 am

Re: IDG A32X Development

Postby Octal450 » Tue Jan 02, 2018 8:07 pm

Yes, and trust me - the advise is always appreciated.

As soon as I begin to work on designing it, I will look into the previous tries.

Kind Regards,
Josh
What I do: Flight Dynamics, Systems, Canvas Displays, Autoflight, FlyByWire, Cockpit Animations
Aircraft I currently develop: MD-11 (Mainly), Secret, A320-family (Quality over Quantity)

My GitHub|MD-11 and ITAF Dev Discord|Airbus Dev Discord
User avatar
Octal450
 
Posts: 4716
Joined: Tue Oct 06, 2015 12:51 pm
Callsign: WTF411/Octal
Version: next
OS: Windows 7/10 x64

Re: IDG A32X Development

Postby merspieler » Wed Jan 03, 2018 9:55 am

vaipe wrote in Tue Jan 02, 2018 10:27 am: Maybe one option could be to invest enough €'s into PC/GPU to run all monitors from one machine.


Get a quadcore cpu and a GTX970 and you can run 3x FullHD at 60fps if your OS doesn't mess with your pc in the background(40fps on win7 vs 60fps on debian... on my machine).
If everything is going against you, keep in mind that airplanes take off against the wind, not with it.
merspieler
 
Posts: 738
Joined: Thu Oct 26, 2017 10:43 am
Location: Wish to be in YBCS
Callsign: JST935. ORI1711
IRC name: merspieler
Version: next
OS: Debian Bullseye

Re: IDG A32X Development

Postby Octal450 » Wed Jan 03, 2018 2:56 pm

offtopic ^ :wink:

The next steps is finishing the PERF then merge Canvas MCDU into master.

See you soon.
Kind Regards,
Josh
Last edited by Octal450 on Wed Jan 03, 2018 6:10 pm, edited 1 time in total.
What I do: Flight Dynamics, Systems, Canvas Displays, Autoflight, FlyByWire, Cockpit Animations
Aircraft I currently develop: MD-11 (Mainly), Secret, A320-family (Quality over Quantity)

My GitHub|MD-11 and ITAF Dev Discord|Airbus Dev Discord
User avatar
Octal450
 
Posts: 4716
Joined: Tue Oct 06, 2015 12:51 pm
Callsign: WTF411/Octal
Version: next
OS: Windows 7/10 x64

Re: IDG A32X Development

Postby merspieler » Wed Jan 03, 2018 2:58 pm

Is the github repo up to date with you private one?
I ask, cause I'm thinking about, compleeting the PERF
If everything is going against you, keep in mind that airplanes take off against the wind, not with it.
merspieler
 
Posts: 738
Joined: Thu Oct 26, 2017 10:43 am
Location: Wish to be in YBCS
Callsign: JST935. ORI1711
IRC name: merspieler
Version: next
OS: Debian Bullseye

Re: IDG A32X Development

Postby SVW » Wed Jan 03, 2018 3:07 pm

Regarding Dual Control / Shared Cockpit: here's a simple workaround that works reliably, tested in many VATSIM flights:
https://forum.flightgear.org/viewtopic.php?f=19&t=30614&p=296214&hilit=anydesk#p296214

cheers
svw
SVW
 
Posts: 75
Joined: Sat Jun 13, 2015 5:54 pm

PreviousNext

Return to Aircraft

Who is online

Users browsing this forum: Delta5142 and 1 guest