Board index FlightGear Development Canvas

NavDisplay & MapStructure discussion (previously via PM)

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: NavDisplay & MapStructure discussion (previously via PM)

Postby Soitanen » Sat Feb 22, 2014 5:07 pm

Now I have question, that I can't fix by myself.
In Boeing 737, left ND and right ND shows different courses (for nav, from left and right MCP parts) and have different NAV sources (NAV1 for captain and NAV2 for FO) for APP and VOR mode. How can I realize this feature?
Boeing 737-300. Reworked cockpit, FDM, autopilot and much more. WIP.
Boeing 737-800. WIP. Canvas PFD and ND.
Antonov An-24B. Made from scratch. Very good FDM. 3D model by Adrian. WIP.
Project Russia (some cities, based on OSM with custom objects).
Soitanen
 
Posts: 489
Joined: Sat Jun 16, 2012 7:50 am
Location: Saint-Petersburg, Russia
Version: git
OS: Linux Mint 17

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Sat Feb 22, 2014 5:15 pm

it's already supported - in fact, you can have dozens of ND "instances" per aircraft if you really wanted to - technically, this is accomplished via the "configuration hash" (myCockpit_Switches) at the top of the file. You can check that the NDs on the 747 or 777 are indeed totally separate. However, the underlying aircraft systems do not (yet) currently expose different "systems" usually. But that's mostly a matter of adding some XML code for each independent instance.
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: NavDisplay & MapStructure discussion (previously via PM)

Postby Soitanen » Sat Feb 22, 2014 5:25 pm

That's my question! I have now two different ND (for Cpt and FO), but, I think, we need to have ability to specify source for this data, when creating new instance of ND. As I can understand, it's question of framework. (If I correctly understand, what is framework generally, because English is not my native language and I can totally misunderstand something :) )
Boeing 737-300. Reworked cockpit, FDM, autopilot and much more. WIP.
Boeing 737-800. WIP. Canvas PFD and ND.
Antonov An-24B. Made from scratch. Very good FDM. 3D model by Adrian. WIP.
Project Russia (some cities, based on OSM with custom objects).
Soitanen
 
Posts: 489
Joined: Sat Jun 16, 2012 7:50 am
Location: Saint-Petersburg, Russia
Version: git
OS: Linux Mint 17

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Sat Feb 22, 2014 5:38 pm

In simple terms, this is pretty straightforward thanks to the way the MapStructure back-end is designed: Its layers (VOR, DME, FIX, APT) never make any assumptions about their front-end (for example GUI dialog or cockpit instrument) - therefore, all front-end specific stuff is not part of those drawing routines, but it's part of so called "controllers" that are typically 10-15 lines of code (of which only ~5-8 lines need customizing, the rest is typically copy/paste programmming) - that way, you can easily add controllers to support additional avionics.

Consider the image below, the "controller" is the orange box:
Image

For example, let's say we were to come up with an aircraft that has 5 navradios - the only thing required to use those in a ND/MapStructure layer is changing the index number of the radio in the property tree. Now, let's look at one of the controllers that's actually using the navradio, e.g. the DME or VOR layer: https://gitorious.org/fg/fgdata/source/ ... roller#L20

You can see, that this layer will automatically register listeners for ALL navradios automatically. So that part is already working - the only problem is that you won't see a difference, because all instances work like this at the moment
So this would need to be made configurable so that each layer could handle only certain navradios - that would take 2-3 minutes to change/test and commit, so no big deal :D

PS: No need to work on this, I can implement that within a few minutes, I just need to pull --rebase my own stuff first, juggling too many branches and starting to get lost ...
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: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Sat Feb 22, 2014 10:37 pm

@Gijs/Hyde: I haven't checked yet, but it seems that the CTR mode in navdisplay.mfd has some hard-coded assumptions regarding the offset/size of the canvas, i.e. when used on other aircraft (or the dialog), it's not properly aligned - so there must be some hard-coded calculation taking place presumably.
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: NavDisplay & MapStructure discussion (previously via PM)

Postby Hyde » Sat Feb 22, 2014 10:52 pm

@Hooray,
Which simptom are you talking about?
What object is not alingend?
Hyde
 
Posts: 724
Joined: Fri Aug 12, 2011 2:09 pm
Location: Peachtree city, GA
Callsign: N407DS
Version: GIT
OS: Fedora 25

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Sat Feb 22, 2014 11:01 pm

ND in center mode, when NOT using identical settings, i.e. differently sized canvas (different aircraft or GUI 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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hyde » Sat Feb 22, 2014 11:18 pm

I changed screen size even distored but it woks fine.
Image
Hyde
 
Posts: 724
Joined: Fri Aug 12, 2011 2:09 pm
Location: Peachtree city, GA
Callsign: N407DS
Version: GIT
OS: Fedora 25

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Sat Feb 22, 2014 11:25 pm

thanks for checking, then I need to check if we're using an outdated version of navdisplay.mfd obviously...
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: NavDisplay & MapStructure discussion (previously via PM)

Postby Hyde » Sat Feb 22, 2014 11:31 pm

Yeah, my navdisplay.mfd has lots of fixes.
I asked Gijs to add my changes but not get answer yet.
I'm gonna push the changes tonight if not get answer still.
Hyde
 
Posts: 724
Joined: Fri Aug 12, 2011 2:09 pm
Location: Peachtree city, GA
Callsign: N407DS
Version: GIT
OS: Fedora 25

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Sat Feb 22, 2014 11:33 pm

if you're happy with Soitanen's fixes, please also commit those
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: NavDisplay & MapStructure discussion (previously via PM)

Postby Hyde » Sat Feb 22, 2014 11:34 pm

It's already in. :D

Edit:
O.K. I pushed the changes and updated the downloadhttp://forum.flightgear.org/viewtopic.php?f=4&t=21870&p=201566#p201536 for windows user also.

@Soitanen
I added your fix also but not exactly same. Please check if it is O.K.
And also I added 2 new hashes in ND.nas. Please add the same to your model too. Otherwise you will get the nasal error.

Remaining issues are
1. Simulation stops when select ARPT. #1320
2. Route is not drawn when activate the route manager. #1326
Could someone teach me how to set listener for /autopilot/route-manager/active property?
3. Display flickering every update cycle when traffic enabled and other ship exists. #1344
4. PLAN mode route is rotating. Should not rotate. #1383 Fixed.
5. Range size is not correct when CTR mode. Should be half. #1385
6. Track line for CTR mode is not correct. #1387
7. Range arc for CTR mode is not displayed. #1388
8. Display flickering every 5sec in PLAN mode. #1386

I will submit the issue report for 5,6,7 and 8.
Edit:Edit:
@Soitanen
Sorry, forgot to get altArc fix. Will do.

Edit:Edit:Edit
Done.
Last edited by Hyde on Tue Mar 25, 2014 2:01 pm, edited 1 time in total.
Hyde
 
Posts: 724
Joined: Fri Aug 12, 2011 2:09 pm
Location: Peachtree city, GA
Callsign: N407DS
Version: GIT
OS: Fedora 25

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Soitanen » Tue Mar 25, 2014 1:44 pm

Could you, please, check this fix - https://gitorious.org/fg/fgdata/merge_requests/244
And I find, that DME values was wrong (they were taken directly to localizer, not GS and not using bias from GS DME system). So I have fix, but I can't upload it to gitorious due to errors when git push. So, here is patch:
Code: Select all
Author: Michael Soitanen <soitanen.michael@gmail.com>  2014-03-25 16:31:01
Committer: Michael Soitanen <soitanen.michael@gmail.com>  2014-03-25 16:37:54
Parent: d04dbf187f117ecf8913dfe40145dfcbf505cbc8 (Fixing filling of course and gs deviation indicator)
Branch: navdisplay
Follows: version/3.1.0
Precedes:

    Fixed ND bug with showing DME (data was taken from wrong source)

----------------------- Nasal/canvas/map/navdisplay.mfd -----------------------
index 1687e05..a856349 100644
@@ -483,7 +483,7 @@ var NDStyles = {
                is_true: func(nd) {
                   nd.symbols.dme.show();
                   if(getprop("instrumentation/dme/in-range"))
-                     nd.symbols.dme.setText(sprintf("%3.1f",getprop("instrumentation/nav/nav-distance")*0.000539));
+                     nd.symbols.dme.setText(sprintf("%3.1f",getprop("instrumentation/dme/indicated-distance-nm")));
                },
                is_false: func(nd) nd.symbols.dme.hide(),
             },
@@ -1051,7 +1051,7 @@ var NavDisplay = {
             me.symbols.vorLId.setText(getprop("instrumentation/nav/frequencies/selected-mhz-fmt"));
          me.symbols.vorLId.setColor(0.195,0.96,0.097);
          if(getprop("instrumentation/dme/in-range"))
-            me.symbols.dmeLDist.setText(sprintf("%3.1f",getprop("instrumentation/nav/nav-distance")*0.000539));
+            me.symbols.dmeLDist.setText(sprintf("%3.1f",getprop("instrumentation/dme/indicated-distance-nm")));
          else me.symbols.dmeLDist.setText(" ---");
          me.symbols.dmeLDist.setColor(0.195,0.96,0.097);
       } elsif(me.get_switch('toggle_lh_vor_adf') == -1) {
@@ -1082,7 +1082,7 @@ var NavDisplay = {
             me.symbols.vorRId.setText(getprop("instrumentation/nav[1]/frequencies/selected-mhz-fmt"));
          me.symbols.vorRId.setColor(0.195,0.96,0.097);
          if(getprop("instrumentation/dme[1]/in-range"))
-            me.symbols.dmeRDist.setText(sprintf("%3.1f",getprop("instrumentation/nav[1]/nav-distance")*0.000539));
+            me.symbols.dmeRDist.setText(sprintf("%3.1f",getprop("instrumentation/dme[1]/indicated-distance-nm")));
          else me.symbols.dmeRDist.setText(" ---");
          me.symbols.dmeRDist.setColor(0.195,0.96,0.097);
       } elsif(me.get_switch('toggle_rh_vor_adf') == -1) {

Boeing 737-300. Reworked cockpit, FDM, autopilot and much more. WIP.
Boeing 737-800. WIP. Canvas PFD and ND.
Antonov An-24B. Made from scratch. Very good FDM. 3D model by Adrian. WIP.
Project Russia (some cities, based on OSM with custom objects).
Soitanen
 
Posts: 489
Joined: Sat Jun 16, 2012 7:50 am
Location: Saint-Petersburg, Russia
Version: git
OS: Linux Mint 17

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Tue Mar 25, 2014 2:03 pm

Gijs or Hyde should probably have a look - but I don't think that we should be "hard-coding" things like nav[x] or dme[x] here - this sort of stuff needs to be configurable, so that the ND code supports multiple radios like the real thing does - otherwise, two separate ND instances would still be using the same radios internally:

Subject: NavDisplay & MapStructure discussion (previously via PM)
Soitanen wrote:That's my question! I have now two different ND (for Cpt and FO), but, I think, we need to have ability to specify source for this data, when creating new instance of ND. As I can understand, it's question of framework. (If I correctly understand, what is framework generally, because English is not my native language and I can totally misunderstand something :) )
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: NavDisplay & MapStructure discussion (previously via PM)

Postby Hyde » Tue Mar 25, 2014 10:31 pm

but I don't think that we should be "hard-coding" things like nav[x] or dme[x] here - this sort of stuff needs to be configurable, so that the ND code supports multiple radios like the real thing does - otherwise, two separate ND instances would still be using the same radios internally:

I agree for the first one which should be the reference receiver selected by FMC. Second and third one are O.K. since they are fixed receivers.
There is no plain using reference receiver for navigation so far but it might be better to change it to new hash "reference_rcvr" or something.
I will push as is so far.
Thanks for your change, Soitenen.
Hyde
 
Posts: 724
Joined: Fri Aug 12, 2011 2:09 pm
Location: Peachtree city, GA
Callsign: N407DS
Version: GIT
OS: Fedora 25

PreviousNext

Return to Canvas

Who is online

Users browsing this forum: No registered users and 2 guests