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 Hooray » Tue Jan 28, 2014 4:34 pm

Looking through Philosopher's latest TFC changes, and I think this is one those "layers" that could greatly benefit from having a dedicated "Drawable" class - once we introduce a Drawable class, we could directly add support for LOD, styling (colors, svg filenames, callbacks) and caching. People would then only need to implement the interface of the drawable class to override symbols or animations.
I think we already started with this when we were working on the fixed grid caching scheme.
And draw() vs. update() could then be a part of the drawable class.

Just some food for thought for the 3.2 release cycle...
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: 11325
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Wed Feb 05, 2014 3:53 am

http://code.google.com/p/flightgear-bug ... id=1320#c4
gijs wrote:I'm only seeing a delay when enabling APT now. Stations and waypoints cause no significant delay...

@Philosopher, does APT have a different implementation?


Yeah, it does - it's still using your old code that uses removeAllChildren() - we (I) completely missed that one, I only just updated the MapStructure article about this - it's not a difficult thing actually, especially not when compared to TFC - but we missed it because it's such a trivial layer (we were focusing on the more difficult ones). This one is "static" and trivial.

You can basically look at the navaid layers (NDB, DME or VOR) and copy them exactly and just replace the APT.symbol implementation with the one that you added to airport.draw - and then you need to adjust the searchCmd - and edit navdisplay.mfd to add the "disabled:1" field to the old layer and add a new "isMapStructure:1" field to the new layer - and you're done.
You only need to edit MapStructure.nas and add APT to the vector of layers

EDIT: Okay, here's a patch:
Canvas/MapStructure/NavDisplay:
- add FGAirport ghost support to MapStructure
- add new MapStructure-based airports layer (APT)
- integrate with NavDisplay
- disable old layer

includes various *.lcontroller fixes for accidentally hard-coded query ranges (oops)

Note: I do not currently have any good way to test these changes - so these should be tested first by Gijs & Hyde, and ok'ed by Philosopher or TheTom

Make sure to check the hack in navdisplay.mfd - I don't think we need to add controllers to both hashes here ...


http://codepad.org/ZapPq1My
Code: Select all
diff --git a/Nasal/canvas/MapStructure.nas b/Nasal/canvas/MapStructure.nas
index 0afdcd2..326dd85 100644
--- a/Nasal/canvas/MapStructure.nas
+++ b/Nasal/canvas/MapStructure.nas
@@ -180,7 +180,8 @@ var getpos_fromghost = func(positioned_g)
 # (geo.Coord and positioned ghost currently)
 Symbol.Controller.getpos = func(obj) {
    if (typeof(obj) == 'ghost')
-      if (ghosttype(obj) == 'positioned' or ghosttype(obj) == 'Navaid' or ghosttype(obj)=='Fix' or ghosttype(obj)=='flightplan-leg')
+      # FIXME: use a foreach/vector here ?
+      if (ghosttype(obj) == 'positioned' or ghosttype(obj) == 'Navaid' or ghosttype(obj)=='Fix' or ghosttype(obj)=='flightplan-leg' or ghosttype(obj)=='FGAirport' )
          return getpos_fromghost(obj);
       else
          die("bad ghost of type '"~ghosttype(obj)~"'");
@@ -480,7 +481,8 @@ var load_MapStructure = func {
       load(FG_ROOT~"/Nasal/canvas/map/"~name~".scontroller", name);
       }
 
-      foreach( var name; ['VOR','FIX','NDB','DME','WPT','TFC'] )
+      # add your own MapStructure layers here, see the wiki for details
+      foreach( var name; ['APT','VOR','FIX','NDB','DME','WPT','TFC',] )
          load_deps( name );
       load(FG_ROOT~"/Nasal/canvas/map/aircraftpos.controller", name);
 
diff --git a/Nasal/canvas/map/APT.lcontroller b/Nasal/canvas/map/APT.lcontroller
new file mode 100644
index 0000000..32c2a93
--- /dev/null
+++ b/Nasal/canvas/map/APT.lcontroller
@@ -0,0 +1,31 @@
+# Class things:
+var name = 'APT';
+var parents = [SymbolLayer.Controller];
+var __self__ = caller(0)[0];
+SymbolLayer.Controller.add(name, __self__);
+SymbolLayer.add(name, {
+   parents: [SymbolLayer],
+   type: name, # Symbol type
+   df_controller: __self__, # controller to use by default -- this one
+});
+var a_instance = nil;
+var new = func(layer) {
+   var m = {
+      parents: [__self__],
+      layer: layer,
+      listeners: [],
+   };
+   __self__.a_instance = m;
+   return m;
+};
+var del = func() {
+   #print(name,".lcontroller.del()");
+   foreach (var l; me.listeners)
+      removelistener(l);
+};
+
+var searchCmd = func {
+   #print("Running query:", name);
+   return positioned.findAirportsWithinRange( me.query_range() ); # FIXME: the range should also be exposed, it will typically be controlled via a GUI widget or NavDisplay switch
+};
+
diff --git a/Nasal/canvas/map/APT.scontroller b/Nasal/canvas/map/APT.scontroller
new file mode 100644
index 0000000..1248bc4
--- /dev/null
+++ b/Nasal/canvas/map/APT.scontroller
@@ -0,0 +1,12 @@
+# Class things:
+var name = 'APT';
+var parents = [Symbol.Controller];
+var __self__ = caller(0)[0];
+Symbol.Controller.add(name, __self__);
+Symbol.registry[ name ].df_controller = __self__;
+var new = func(model) ; # this controller doesn't need an instance
+var LayerController = SymbolLayer.Controller.registry[ name ];
+var isActive = func(model) LayerController.a_instance.isActive(model);
+var query_range = func()
+   die( name~".scontroller.query_range /MUST/ be provided by implementation" );
+
diff --git a/Nasal/canvas/map/APT.symbol b/Nasal/canvas/map/APT.symbol
new file mode 100644
index 0000000..105d969
--- /dev/null
+++ b/Nasal/canvas/map/APT.symbol
@@ -0,0 +1,51 @@
+# Class things:
+var name = 'APT';
+var parents = [DotSym];
+var __self__ = caller(0)[0];
+DotSym.makeinstance( name, __self__ );
+
+var element_type = "group"; # we want a group, becomes "me.element"
+var icon_fix = nil;
+var text_fix = nil;
+
+# add the draw routine from airports-nd.draw here
+var draw = func {
+   if (me.icon_fix != nil) return;
+      var icon_apt = me.element.createChild("path", name ~ " icon" )
+         .moveTo(-17,0)
+         .arcSmallCW(17,17,0,34,0)
+         .arcSmallCW(17,17,0,-34,0)
+         .close()
+         .setColor(0,0.6,0.85)
+         .setStrokeLineWidth(3);
+      var text_apt = me.element.createChild("text", name ~ " label")
+         .setDrawMode( canvas.Text.TEXT )
+         .setTranslation(17,35)
+         .setText(me.model.id)
+         .setFont("LiberationFonts/LiberationSans-Regular.ttf")
+         .setColor(0,0.6,0.85)
+         .setFontSize(28);
+      #me.element.setGeoPosition(lat, lon)
+      #   .set("z-index",1); # FIXME: this needs to be configurable!!
+
+# disabled:
+if(0) {
+   # the fix symbol
+   me.icon_fix = me.element.createChild("path")
+      .moveTo(-15,15)
+      .lineTo(0,-15)
+      .lineTo(15,15)
+      .close()
+      .setStrokeLineWidth(3)
+      .setColor(0,0.6,0.85)
+      .setScale(0.5,0.5); # FIXME: do proper LOD handling here - we need to scale according to current texture dimensions vs. original/design dimensions
+   # the fix label
+   me.text_fix = me.element.createChild("text")
+      .setDrawMode( canvas.Text.TEXT )
+      .setText(me.model.id)
+      .setFont("LiberationFonts/LiberationSans-Regular.ttf")
+      .setFontSize(28)
+      .setTranslation(5,25);
+ }
+};
+
diff --git a/Nasal/canvas/map/DME.lcontroller b/Nasal/canvas/map/DME.lcontroller
index b2d3c71..3ac267d 100644
--- a/Nasal/canvas/map/DME.lcontroller
+++ b/Nasal/canvas/map/DME.lcontroller
@@ -14,7 +14,7 @@ var new = func(layer) {
       parents: [__self__],
       layer: layer,
       listeners: [],
-      query_range_nm: 25,
+      # query_range_nm: 25,
       query_type:'dme',
    };
    __self__.a_instance = m;
@@ -27,6 +27,6 @@ var del = func() {
 
 var searchCmd = func {
    #print("Running query:", me.query_type);
-   return positioned.findWithinRange(me.query_range_nm, me.query_type); # the range should also be exposed, it will typically be controlled via a GUI widget or NavDisplay switch
+   return positioned.findWithinRange(me.query_range(), me.query_type); # the range should also be exposed, it will typically be controlled via a GUI widget or NavDisplay switch
 };
 
diff --git a/Nasal/canvas/map/FIX.lcontroller b/Nasal/canvas/map/FIX.lcontroller
index ed89fb0..4da89e4 100644
--- a/Nasal/canvas/map/FIX.lcontroller
+++ b/Nasal/canvas/map/FIX.lcontroller
@@ -14,7 +14,7 @@ var new = func(layer) {
       parents: [__self__],
       layer: layer,
       listeners: [],
-      query_range_nm: 25,
+      #query_range_nm: 25,
       query_type:'fix',
    };
    __self__.a_instance = m;
@@ -28,6 +28,6 @@ var del = func() {
 
 var searchCmd = func {
    #print("Running query:", me.query_type);
-   return positioned.findWithinRange(me.query_range_nm, me.query_type); # the range should also be exposed, it will typically be controlled via a GUI widget or NavDisplay switch
+   return positioned.findWithinRange(me.query_range(), me.query_type); # the range should also be exposed, it will typically be controlled via a GUI widget or NavDisplay switch
 };
 
diff --git a/Nasal/canvas/map/NDB.lcontroller b/Nasal/canvas/map/NDB.lcontroller
index 3250fc0..605525d 100644
--- a/Nasal/canvas/map/NDB.lcontroller
+++ b/Nasal/canvas/map/NDB.lcontroller
@@ -13,7 +13,7 @@ var new = func(layer) {
       parents: [__self__],
       layer: layer,
       listeners: [],
-      query_range_nm: 25,
+      #query_range_nm: 25,
       query_type:'ndb',
    };
    return m;
@@ -25,6 +25,6 @@ var del = func() {
 
 var searchCmd = func {
    #print("Running query:", me.query_type);
-   return positioned.findWithinRange(me.query_range_nm, me.query_type); # the range should also be exposed, it will typically be controlled via a GUI widget or NavDisplay switch
+   return positioned.findWithinRange(me.query_range(), me.query_type); # the range should also be exposed, it will typically be controlled via a GUI widget or NavDisplay switch
 };
 
diff --git a/Nasal/canvas/map/VOR.lcontroller b/Nasal/canvas/map/VOR.lcontroller
index e7adb3d..b393387 100644
--- a/Nasal/canvas/map/VOR.lcontroller
+++ b/Nasal/canvas/map/VOR.lcontroller
@@ -50,6 +50,6 @@ var changed_freq = func(update=1) {
 };
 var searchCmd = func {
    printlog(_MP_dbg_lvl, "Running query:", me.query_type);
-   return positioned.findWithinRange(100, me.query_type); # the range should also be exposed, it will typically be controlled via a GUI widget or NavDisplay switch
+   return positioned.findWithinRange(me.query_range(), me.query_type); # FIXME: the range should also be exposed, it will typically be controlled via a GUI widget or NavDisplay switch
 };
 
diff --git a/Nasal/canvas/map/navdisplay.mfd b/Nasal/canvas/map/navdisplay.mfd
index 8b14ebd..f5bcc46 100644
--- a/Nasal/canvas/map/navdisplay.mfd
+++ b/Nasal/canvas/map/navdisplay.mfd
@@ -89,7 +89,7 @@ var NDStyles = {
                } layer._view.setVisible(visible);
             },
          },
-         { name:'airports-nd', update_on:['toggle_range','toggle_airports','toggle_display_mode'],
+         { name:'airports-nd', disabled:1, update_on:['toggle_range','toggle_airports','toggle_display_mode'],
             predicate: func(nd, layer) {
                # print("Running airports-nd predicate");
                var visible = nd.get_switch('toggle_airports') and nd.in_mode('toggle_display_mode', ['MAP']);
@@ -100,6 +100,20 @@ var NDStyles = {
             }, # end of layer update predicate
          }, # end of airports layer
 
+         { name:'APT', isMapStructure:1, update_on:['toggle_range','toggle_airports','toggle_display_mode'],
+            predicate: func(nd, layer) {
+               # print("Running APT layer predicate");
+               # toggle visibility here
+               var visible=nd.get_switch('toggle_airports') and nd.in_mode('toggle_display_mode', ['MAP']);
+               layer.group.setVisible( nd.get_switch('toggle_airports') );
+               if (visible) {
+                  #print("Updating MapStructure ND layer: APT");
+                  # (Hopefully) smart update
+                  layer.update();
+               }
+            }, # end of layer update predicate
+         }, # end of APT layer
+   
          # Should distinct between low and high altitude navaids. Hiding above 40 NM for now, to prevent clutter/lag.
          { name:'vor', disabled:1, update_on:['toggle_range','toggle_stations','toggle_display_mode'],
             predicate: func(nd, layer) {
@@ -883,7 +897,12 @@ var NavDisplay = {
          get_position: get_current_position,
       };
 
-      # FIXME: MapStructure: big hack
+      # FIXME: MapStructure: big hack @Philosopher: I don't think we need both lines here ??
+      foreach(var hack; var monster_hack = ['APT', 'DME','FIX','NDB','VOR',]) {
+         canvas.SymbolLayer.Controller.get( hack ).query_range = controller.query_range;
+         canvas.Symbol.Controller.get( hack ).query_range = controller.query_range;
+      }
+
       canvas.Symbol.Controller.get("VOR").query_range = controller.query_range;
       canvas.Symbol.Controller.get("VOR").get_tuned_course = controller.get_tuned_course;
       canvas.Symbol.Controller.get("DME").is_tuned = controller.is_tuned;

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

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Gijs » Wed Feb 05, 2014 11:40 am

Your patch does remove the lag from switching APT on/off, but I only get a single airport displayed now :-)
Looks like the range isn't working as expected. The other navaid layers only show objects within 10NM or so, independent of the selected range. If I don't apply your lcontroller changes, we're back to the old behaviour for the navaids (fixed range of 25NM), but with a faster loading APT layer (fixed range instead of the previous dynamic range).
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9363
Joined: Tue Jul 03, 2007 2:55 pm
Location: Amsterdam/Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Wed Feb 05, 2014 4:17 pm

then it's almost certainly the controller hack I added to navdisplay.mfd - I guess Philosopher will spot immediately what's wrong there... better wait for his feedback

EDIT: Okay, I tested it now - and the patch applied cleanly, not seeing any issues here (747-400 @KSFO):

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

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby 5H1N0B1 » Thu Feb 06, 2014 8:05 am

Hi dudes,
I'm at work but I can acces to the forum. 2 things :
- The picture there http://wiki.flightgear.org/MapStructure is a realy good idea, and actually this helps me to understand.
- The NavDispaly is just too awesome, and I think if you don't mind that I'll input it on the 2000 (instead of the old central mfd, which have a transparency issue)
So if you need me for some testing stuff...
5H1N0B1
"Each day, with every person you meet, there is something to learn"
5H1N0B1
 
Posts: 209
Joined: Thu Aug 30, 2012 9:36 am
Location: France
Callsign: 5H1N0B1
IRC name: _5H1N0B1
Version: GIT
OS: Ubuntu

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Gijs » Thu Feb 06, 2014 8:08 am

Hooray wrote in Wed Feb 05, 2014 4:17 pm: not seeing any issues here (747-400 @KSFO):

Well, your shot only shows airports within 10NM (which is exactly the issue :p) Try increasing the range and compare to the GUI map.

ps: is the panel really white? Missing a texture?
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9363
Joined: Tue Jul 03, 2007 2:55 pm
Location: Amsterdam/Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Thu Feb 06, 2014 10:05 am

I am not missing anything, it's fresh fgdata - I think others have posted similar screen shots previously, I was under the impression that this would be either due to a shader-based texture or a file naming issue (linux being case-sensitive) - but the 777 shows up properly. Also, the GPU/driver is definitely not the problem. So I didn't pay attention.

Will check the ND stuff once I got in touch with Philosopher, who's currently busy with other stuff - otherwise, I will be able to spend time on this on Sunday, but I need you (or Hyde) to test, review and commit things then ...
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: 11325
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Fri Feb 07, 2014 3:17 am

Regarding TFC: I looked into it, there are apparently quite a few issues with it - this cannot be just due to all the sophisticated code in there (I don't claim to understand all of it tho):

  • node.getValue(path) instead of node.getNode(path).getValue() in various places causing nil errors
  • TFC.symbol has two bugs related to the tcas_arrow in it, the draw/update instructions there using it call methods need to be fixed to read: me.arrow_tcas[arrow_type].foo() instead of just me.arrow_tcas[arrow_type].foo()
  • using those model-added/removed signals is a bit problematic and maybe too clever - currently, it's not even updating the layer, or using the latlon/getpos APIs
  • then there's the also the issue of multiple inheritance in TrafficModel (TFC.lcontroller) this is basically overshadowing the APIs for props.Node/geo.Coord handling, i.e. redundant stuff: node field, geo.Coord field, and Props.Node inheritance - latlong() isn't even called by MapStructure apparently (?)
  • also, those controllers should not just use listeners, but also parse all traffic during init, or things will break inevitably.

It took me quite a while (and dozens of print statements) to see what's going on there.

Overall, I am not sure if we should include TFC for now - unless we can get it fixed in time, we should better use the old method...which is slow, but at least works properly.
TFC contains quite a bit of (too) sophisticated hacking and obviously hasn't been tested sufficiently.

I am not sure if fixing is worth it, I am inclined to rewrite it from scratch ... because fully understanding TFC is going to take me more time than starting fresh.

EDIT: Maybe I was a bit too harsh with the code, I tried to fix it now - and some of the issues are meanwhile gone (but it's not really much faster than before):
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: 11325
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Philosopher » Fri Feb 07, 2014 2:29 pm

lol, but apologies "tibi" (to you) for several things here (not enough testing, too many hacks, not responding, ...) :P

Comments in lack of due testing:
  • Please do remove the listeners - it'll be fine if they aren't there (esp. if it causes problems to have them!) since the models should be picked up by layer.update() (aka searchCmd)
  • It would actually make more sense to have a live update of position, versus listening for added/removed models, which does seem to be problematic.
  • In fact, I would rather like to implement the same algorithm that you pasted above (C++ map widget) in Nasal, since that should just work, it just requires .update() being called...
  • And so, regarding .update():
    • it should be called once when the layer is created, though, but we definitely need it to be called several other times, if not just to update the positions
    • but it is timed in the aircraftpos.controller, and unfortunately the aircraftpos controller has heuristics to only update if there's been too much distance since last update - which is GOOD for positioned but BAD for live/AI/MP objects :(.
    • thus we need to distinguish these updates - maybe the layer controllers themselves decide to ignore updates, otherwise the map controller itself sets a high default/baseline rate.
    • this would particularly make sense as a specific object to handle rejecting updates for positioned - or even a derived class from Layer.Controller. I would need to work this through.

  • TFC.symbol has two bugs related to the tcas_arrow in it, the draw/update instructions there using it call methods need to be fixed to read: me.arrow_tcas[arrow_type].foo() instead of just me.arrow_tcas[arrow_type].foo()

What do you mean by this?
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Fri Feb 07, 2014 6:50 pm

Just briefly:

there's an oversight in TFC.symbol - which took me a while to figure out, because it's so ... sophisticated what you did there: but, you missed to use me.arrow[tcas_type] to look up the correct call drawback afterwards - remember what you did there ? Pretty clever but not completely implemented. Methods need to use me.arrow_tcas[arrow_type].foo() and currently they're using me.arrow_tcas.foo()
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: 11325
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Fri Feb 07, 2014 7:30 pm

regarding aircraftpos.controller:

My suggestion would be to generalize this into some "MovingObjectController" and create instances, i.e. for the main aircraft - but also for AI/MP traffic-using custom position properties and update intervals-i.e. based on groundspeed, what do you think ?
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: 11325
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Fri Feb 07, 2014 9:55 pm

Gijs was right about APT (and others) being restricted to 10nm.
But fixing APT was not a real problem, it was just because of our controller workarounds:

Image

Gijs wrote in Thu Feb 06, 2014 8:08 am:
Hooray wrote in Wed Feb 05, 2014 4:17 pm: not seeing any issues here (747-400 @KSFO):

Well, your shot only shows airports within 10NM (which is exactly the issue :p) Try increasing the range and compare to the GUI map.

ps: is the panel really white? Missing a texture?



The main issue here is the portion of code that Philosopher added to make controllers work, which essentially OVERWRITES the first (CPT) range settings with the one from the 2nd ND instance, i.e. FO:

Subject: On board radar Canvas integration
Philosopher wrote:yeah, as I've mentioned before, we really need map controllers that handle this, and just provide access to the "upper-level" controller(s) - so TARGET.lcontroller will end up calling "me.map.controller.query_range()" instead of "me.query_range()", etc. etc. This is not something I want to do ATM, so yeah... If anyone else wants to look into it, it should be fairly easy - it just requires touching a lot of places, but I can provide guidance. The ND will also need a map controller, but it essentially has one. The aircraftpos.controller will need to be updated to use query_range(). And once that's done, we might as well start using query_range() as an actual query_range() for the positioned layers. Oh, and we can remove these big hacks as well.

Code: Select all
# FIXME: MapStructure: big hack
        canvas.Symbol.Controller.get("VOR").query_range = controller.query_range;
        canvas.Symbol.Controller.get("VOR").get_tuned_course = controller.get_tuned_course;
        canvas.Symbol.Controller.get("DME").is_tuned = controller.is_tuned;
        canvas.SymbolLayer.Controller.get("TFC").query_range = controller.query_range;
        canvas.SymbolLayer.Controller.get("TFC").get_position = controller.get_position;


Or maybe I'll just do it...


So we basically NEED instances here, because each controller uses different switches, or otherwise the controller added last "wins".
To see for yourself, just adjust the settings on the 2nd ND and everything works again as expected.
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: 11325
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Soitanen » Sat Feb 08, 2014 4:34 pm

Hi all in this topic! Hooray has invited me to install ND on 737-300.

I understand, that EHSI from 737CL is different from 737NG ND, but I have found some bugs, not related to EHSI-ND difference. Maybe I'm doing something wrong, please point me.

Left canvas window - APP mode, expanded mode.
Right canvas window - APP mode, expanded mode.

Image
In left window runway symbol moves not in 90 degrees to the course. Right window do not have this localizer needle at all.

Image
The same as above and wrong glideslope pointer position (you can see right pointer on EADI, in ND it's inverted...).

Image
COURSE is the same, but in left window it pointing not to 23 degrees.

In all screens:
- full mode - heading rose - number 4 instead 6;
- track line (in expanded mode) or drift angle pointer (in full rose mode) is missed;
- full rose mode when not in MAP mode must have another rose (in 737CL EHSI, so maybe this is not a bug).

So, is this bugs? How can I help to improve ND?
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 6:50 am
Location: Saint-Petersburg, Russia
Version: git
OS: Linux Mint 17

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Gijs » Sat Feb 08, 2014 4:49 pm

All known bugs and being worked on (see bug tracker). ;-)
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9363
Joined: Tue Jul 03, 2007 2:55 pm
Location: Amsterdam/Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Sat Feb 08, 2014 8:05 pm

@Soitanen: thanks for taking the time to report those issues - as Gijs mentioned already, Hyde and others have reported these previously.
Of course we appreciate people adopting the ND framework and providing feedback - but obviously it's a work in progress, and many things will probably not be solved in time for 3.0
If you are interested in improving the ND, you will need to know Nasal and Canvas scripting and Inkscape skills would also be useful.
You can look at navdisplay.mfd to see if you understand what's going on there - most of the recent additions are simply inside the update() method, where symbols are added and animated.
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: 11325
Joined: Tue Mar 25, 2008 8:40 am

PreviousNext

Return to Canvas

Who is online

Users browsing this forum: No registered users and 1 guest