Board index FlightGear Development Canvas

Canvas ND on another aircraft than Boeing and Airbus

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby clm76 » Fri Oct 21, 2016 7:08 am

You can set up your own fgdata clone via sourceforge

It's done and a merge request sent.

Other question : In the navdisplay.mfd file, there is some lines of code very specific to the Boeing aircraft, such as
Code: Select all
me.symbols.vorR.setText("VOR R");
me.symbols.vorR.setColor(0.195,0.96,0.097);

wouldn't it be better to transfer this settings to the navdisplay.styles file ?
clm76
 
Posts: 149
Joined: Tue Oct 30, 2012 8:18 pm
Location: France - LFOH
Callsign: F-GCLM
Version: 2018.3.0
OS: Linux Mint 18.3

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby Hooray » Fri Oct 21, 2016 6:39 pm

yes, you are right - basically, you would add a helper function, and move such stuff to it - and then begin using it in the mfd file.

Personally, I would probably provide helpers to encapsulate the notion of a "navaid" and then create a child class inheriting from it to implement NDB/VOR classes.
At that point, you could easily encapsulate behavior such as setting the title/color, or even radial handling stuff.

Like I said, we still have tons of aircraft specific stuff in the mfd file, and that should really be moved to the style stuff (covering both styles we have obviously).
Once that is the case, we can look at refactoring the styles stuff to clean up things there and share more code.

But the first step really is cleaning up the mfd file to get rid of aircraft specifics, subsequently it may also make sense to get rid of ND specific assumptions there, so that the same mechanism could be used for other MFDs, at which point it may make sense to integrate that with Richard's MFD framework.

Anyway, for the time being, you can find tons of identical lines of code differing only slightly, e.g. due to the text/color or conditionals used - such things should be moved to helper functions.

If in doubt, I would first of all create a navdisplay.common file and move such stuff there, and simply use io.include() to still make it available.

But right now, the mfd file is an embarrassing, but highly functional ;-) - mess unfortunately, begging to be be cleaned up.

For future reference (and new styles), I would also strongly recommend to review artix's work (the Airbus style) which is much more sophisticated than the original Boeing work meanwhile, and which is also using better coding patterns to organize all the code

Hopefully, the dialog I have protoyped can help with some of this, even if just with testing the existing functionality tto ensure that all the refactoring work doesn't break anything.

Please do feel free to get in touch if you are interested in helping with any of that, or if you need additional features in that dialog - apart from that, I would like to reiterate my request to document your whole journey and help us add to the wiki, if in doubt, just create a new article.

Besides, if there is anything you'd like to see better document to help with this kind of work, let us know, so that I can add a corresponding tutorial to the wiki - if you understand how to generalize aircraft specific code and move it to the styles file, you are basically half-way there, because it's not very complicated anymore at that point
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby Hooray » Sun Oct 23, 2016 3:25 pm

Okay, I have another small patch for the navdisplay code to make the dialog more functional, details at: http://wiki.flightgear.org/Howto:Protot ... ge_changes

It would be great if Gijs and Hyde could if this breaks anything or not (ideally also testing an Airbus aircraft using the ND framework) and please report back here, or directly commit those changes if everything seems to work properly.

Image
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby Hooray » Mon Oct 24, 2016 7:50 pm

Another update, the dialog will now automatically reload the mfd/styles files from disk whenever it is opened or whenever the style is changed.
In addition, the dialog has been reworked to make the resolution of the ND configurable, and it also provides an option to easily add new NDs to the dialog (screen space permitting).

I've tested this only locally so far, and it obviously does require the base package changes detailed in the wiki article, so I am awaiting bug reports/feedback, but won't be changing much anytime soon.

People interesed in tinkering with different ND styles/features should hopefully find this pretty useful "as is".

http://wiki.flightgear.org/Howto:Protot ... Style#Code

Image
Image
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby clm76 » Tue Oct 25, 2016 5:24 pm

Hi Hooray,

I have an error using your last canvas-nd.xml.
Code: Select all
Error parsing dialog Path "/home/chris/fgfs2016_4/install/flightgear/fgdata/gui/dialogs/canvas-nd.xml"
clm76
 
Posts: 149
Joined: Tue Oct 30, 2012 8:18 pm
Location: France - LFOH
Callsign: F-GCLM
Version: 2018.3.0
OS: Linux Mint 18.3

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby Hooray » Tue Oct 25, 2016 5:29 pm

thanks for the feedback, must be a typo in the wiki, because I just tested the local file.
EDIT: yes, I just noticed it: copy & paste error, see the top of the file ... 2 times XML version in there.
Will fix it shortly, please do report if there are any other issues. thanks
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby clm76 » Wed Oct 26, 2016 6:44 am

It's ok now and running well.

Just a little thing : in the xml code I see :
Code: Select all
               <combo>
                  <label>Mode</label>
                  <name>unchanged mode!!!</name>
                  <property>WILL BE FILLED IN PROCEDURALLY</property>

                <binding>
                  <command>dialog-apply</command>
                  <object-name>unchanged mode !!!</object-name>
                </binding>   
               </combo>

Is it normal to have "unchanged mode!!!" for the "label name" and "unchanged mode !!!" with a space after "mode" in the <object-name> ?
No error before and after correction.
clm76
 
Posts: 149
Joined: Tue Oct 30, 2012 8:18 pm
Location: France - LFOH
Callsign: F-GCLM
Version: 2018.3.0
OS: Linux Mint 18.3

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby Hooray » Wed Oct 26, 2016 7:57 pm

Yes, you are right - the question is appropriate.

However, the short answer is that this simply isn't relevant if you really only want to use the dialog to help test/develop new styles.

The long/proper answer is that the "dialog" has become more sophisticated than originally planned.

In general, all PUI/XML dialogs should be using the markup for the widgets, and layouting directives, detailed in $FG_ROOT/Docs/README.gui and README.layout.

In addition to the features mentioned in those files there are some undocumented features, which can be found in the dialog building routines.

Internally, a dialog is just a property tree - it is read and loaded into the/a property tree and then further processed.

This is accomplished using so called "fgcommands", which is the stuff that you'd typically add to menubar.xml to make a new dialog item known to the GUI.

Some of the more typical GUI related fgcommands are:

- dialog-show
- dialog-close

Now, what is taking place internally is that dialogs may not only contain the known XML markup, but may also contain embedded Nasal code blocks.

There are really only two main ways to embed such code: at the dialog-level using nasal/open tags for code that is executed prior to showing a dialog that is already loaded from disk, and nasal/load blocks loaded per Canvas widget (the black area showing the ND texture).

To be fair, there also is a nasal/close tag to do some housekeeping/cleanup.

Anyway, what is so powerful about Nasal embedded in dialog files is that the code is typically executed prior to the creation/display of the dialog, and the Nasal code gets a handle to the property tree representation of the dialog markup (processed aready by the XML parser).


This "handle" is not just read-only, i.e. you get a mutable handy, which means you can traverse the tree and query it (e.g. to locate certain elements) and then freely add/remove or rename/duplicate elements, using the exact same APIs used to manipulate the global proeprty tree (e.g. props.nas).

And that is basically answering your question: The XML file posted in the wiki is incomplete - it would not make any sense at all without the embedded Nasal portions, but it contains a few redundant nodes that are not recognized by the existing GUI engine.

However, nasal/open block will specifically look for these redundant blocks and treat those as "templates" for certain widgets, e.g. those requiring dynamic contents (think a list of known styles, which cannot be hard-coded, think a list of MAP modes, ranges etc).

Internally, the Nasal code will then locate a handful of useful blocks, instantiate (copy/rename, and customize them) and insert them into the appropriate locations in the dialog/property tree.

This is why we may have only a single combo/select or "button" element in the XML markup, despite having possibly dozens of buttons: The code gets a copy to the dialog's property tree, and then duplicates useful/required nodes and customizes/renames them.

What you have now found are leftovers from one of my debugging sessions - basically, all these strings are irrelevant placeholders, because they get overridden anyway. However, at some point, the code wasn't working properly, so that I added strings like "unchanged mode" to the XML - this was so that I could tell immediately which routine would fail replacing those placeholders, because that would show up prominently in a dump of the "procedurally created dialog".

And that sums up the whole approach pretty well: The dialog only contains a subset of the required widgets/data, but it's using ~200 LOC to procedurally reuse those and replace those placeholders with more appropriate contents/variables.

Anyway, like I said, none of this should be relevant as long as you really only want to use the dialog. As a matter of fact, I don't think that there are many other dialogs making such elaborate use of this templating technique, but it is this that makes it possible to instantiate an arbitrary number of NDs using different resolutions - because what is really taking place is that the corresponding settings are written into the global property tree, and then the dialog is closed, the GUI subsystem reset and the same dialog opened, this time picking up the defaults you set up using the previously closed dialog.

I realize that this may sound complicated - but once you understand README.gui, README.layout and how embedded Nasal blocks work, and how those can manipulate the dialog before it is shown, it actually all makes sense, and isn't much unlike JavaScript/DOM traversal (akin to jQuery even).
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby clm76 » Thu Nov 10, 2016 5:22 pm

Hi,

My work on the canvas Navdisplay for the Citation X moves forward correctly. The basic functions, ARPT, VOR, FIX, MAP and PLAN modes, are implemented.
I'm working now on the Traffic layer.
Is there some way to simulate other aircrafts (or other things) in the immediate neighbourghood (between 2 and 6 nm), to verify that all is correct ?
clm76
 
Posts: 149
Joined: Tue Oct 30, 2012 8:18 pm
Location: France - LFOH
Callsign: F-GCLM
Version: 2018.3.0
OS: Linux Mint 18.3

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby Hooray » Thu Nov 10, 2016 6:49 pm

clm76 wrote in Thu Nov 10, 2016 5:22 pm:Is there some way to simulate other aircrafts (or other things) in the immediate neighbourghood (between 2 and 6 nm), to verify that all is correct ?


Note that there really isn't anything you should have to touch other than the .symbol file - the lcontroller file remains "as is".

Anyway, the MP system works via the AI system - thus, you can use any AI scenario and/or interactive traffic -including the tanker.
We ended up using that for prototyping the whole radar layer originally.

http://wiki.flightgear.org/Canvas_Radar
Image

http://wiki.flightgear.org/Scripted_AI_Objects
Image
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby clm76 » Sun Nov 13, 2016 11:52 am

Hi,

It seems that there is a bug in TFC.lcontroller here :
Code: Select all
var get_alt_diff = func(model) {
   # debug.dump( keys(me) );
   var model_alt = model.get_alt();
   var alt = me.map.getAlt();
   if (alt == nil or model_alt == nil) return 0;
   return alt-model_alt;
};

With "var alt = me.map.getAlt()", the altitude of aircrafts are correct on the canvas(map) display but not on the aircraft mfd display and it's the same problem with the 777.
Image

By replacing with " var alt = getprop("/position/altitude-ft"); " all is correct in canvas(map) and on the mfd display.
Image

So I suggest this code for the TFC.lcontroller:
Code: Select all
var get_alt_diff = func(model) {
   # debug.dump( keys(me) );
   var model_alt = model.get_alt();
   var alt = getprop("/position/altitude-ft");
   if (alt == nil or model_alt == nil) return 0;
   return alt-model_alt;
};
clm76
 
Posts: 149
Joined: Tue Oct 30, 2012 8:18 pm
Location: France - LFOH
Callsign: F-GCLM
Version: 2018.3.0
OS: Linux Mint 18.3

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby Hooray » Sun Nov 13, 2016 12:07 pm

that seems correct - however, for that to work properly, you need to encapsulate the altlitude access, or it will fail for AI/MP traffic, i.e. NDs being shown from the point of view of an AI/MP entity, which shouldn't be using /position/altitude-ft at all, but the entity-specific equivalent.

That is one of the primary reasons why these properties are encapsulated in a so called "driver hash" (see the NDSourceDriver logic and related comments).

In general, none of the layers can make any assumptions about these properties, because they are designed to be "reusable", which means that a different position source can be specified at there mere cost of setting up a hash with the corresponding functions - this makes it possible to test-drive the ND with AI/MP traffic, and it is important that this remains functional.

However, it seems indeed that you have found an actual bug, so thanks for reporting!

PS: Why aren't you yet using the new ND dialog ?
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby clm76 » Sun Nov 13, 2016 4:51 pm

however, for that to work properly, you need to encapsulate the altitude access

Ok, I'm looking into that.

However, it seems indeed that you have found an actual bug, so thanks for reporting!

Ok, but after having found an encapsulate access to the altitude.

Why aren't you yet using the new ND dialog ?

What do you mean ? Which new ND dialog ?
clm76
 
Posts: 149
Joined: Tue Oct 30, 2012 8:18 pm
Location: France - LFOH
Callsign: F-GCLM
Version: 2018.3.0
OS: Linux Mint 18.3

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby clm76 » Sat Nov 19, 2016 6:30 am

Hi,

however, for that to work properly, you need to encapsulate the altitude access

However, it seems indeed that you have found an actual bug, so thanks for reporting!

I added some lines of code into navdisplay.mfd file to treat altitude like longitude and latitude. Now it's ok.
A merge request has been sent.
clm76
 
Posts: 149
Joined: Tue Oct 30, 2012 8:18 pm
Location: France - LFOH
Callsign: F-GCLM
Version: 2018.3.0
OS: Linux Mint 18.3

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby Hooray » Tue Nov 29, 2016 7:42 pm

Sorry for not getting back to this earlier - I am basically AFK for the time being, your best bet is pinging Gijs and/or Hyde to get this reviewed/integrated or one of the fgdata committers who's done Canvas/ND related work
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

PreviousNext

Return to Canvas

Who is online

Users browsing this forum: No registered users and 0 guests