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.

NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Fri Dec 06, 2013 10:13 pm

Gijs wrote in Fri Mar 13, 2009 3:42 pm:Hi guys,

finally managed to fix the in_mode issue. Turned out this code was incorrect (not returning 0 when the set-mode was not in modes):
Code: Select all
in_mode:func(switch, modes)   foreach(var m; modes) {
   if (me.get_switch(switch)==m) return 1;
   else continue;
   print("not in checked mode");
   return 0;
},
changed it to:
Code: Select all
in_mode:func(switch, modes)   {
   foreach(var m; modes)
      if (me.get_switch(switch)==m) return 1;
   return 0;
},

@Hyde, I fixed both your issues, before you reported them. We were using track, but below 80kt, we should use heading, because one cannot calculate a track when you're not really moving ;-)

@Hooray, altitudes are now shown for the waypoints. The VSD thing is nice, but it's low on my priority list. There's still lots of basic functionality missing that I'd like to have before 3.0. And then there's also the PFD that needs to be done...

Next to the above mentioned fixes I have a couple of new features. I'll push an update later today.

Feature requests/bugs:
  • ND framework
    • every layer should have a z-index parameter.
    • update_on should support non-efis properties (like /autopilot/route-manager/activate).
  • Canvas
    • setColor should, when applied to a group, set the color of all group members.
    • setText/sprintf does not accept the degree symbol (or maybe I've tried the wrong symbol number?)

Cheers,
Gijs


Philosopher wrote:Just a quick response, I don't think osgText actually handles non-ascii, e.g. see this commit by Clément: https://gitorious.org/fg/fgdata/commit/ ... 9df4fb1827

Gijs wrote in Fri Mar 13, 2009 3:42 pm:We were using track, but below 80kt, we should use heading, because one cannot calculate a track when you're not really moving ;-)

Sounds like we need.... more controllers here! The point of a controller (at least for this specific case), is that it can be a neutral arbitrator and decide which properties we need to use and when. I'm working to see if we can get a better framework here...




  • thanks for fixing the in_mode bug, should have probably looked more carefully :D
  • track vs heading: this part is currently all done through "behavior hashes" in the ND code, so straightforward to change actually - the ND code doesn't use MapStructure here (yet), so having more controllers/support for them does not immediately help us, until all used layers are indeed ported an adopted by the ND code.
  • I was originally planning on moving those huge hashes to some form of PropertyList-XML file, to allow aircraft developers to easily implement their own NDs, but I'll better wait for this until we have at least half a dozen aircraft using the framework, to see what will be needed design-wise.
  • The VSD part, I'm just planning on preparing support for it, i.e. having "sub-displays" (clipped rectangles) as part of the ND, and stuff like that - overall, a "vertical situation display" can be pretty cool, and it's cool and novel features that end up being adopted by aircraft developers more quickly - in its current form, the ND code is also still "competing" with the original (hardcoded) NavDisplay code: http://wiki.flightgear.org/Navigation_display
  • I still need to check how many a/c have adopted the hardcoded system - if there are many, as in >=10, I would *consider* writing a parser for the old config format, that returns a canvas-driven NavDisplay instead.
  • feature requests NavDisplay: should be a no-brainer once MapStructure is adopted
  • update_on() and non-EFIS properties - should be simple, too - instead of having a vector with properties, you would use a hash with keys that determine if it's an EFIS property or a "global" one.
  • regarding Canvas feature requests, better post them publicly, i.e. in the Canvas forum - I don't think we've been including TheTom in the ND/MapStructure discussions that's been taking place so far.

PS: Thanks for adding altitude labels to the waypoints!
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 » Fri Dec 06, 2013 10:23 pm

Just tried with latest fgdata, apparently someone added a property to a calculation that's not defaulted to 0, so that nil shows up after takeoff:
Code: Select all
Nasal runtime error: nil used in numeric context
  at /home/hooray/sources/fgroot/Nasal/canvas/map/navdisplay.mfd, line 642
  called from: /home/hooray/sources/fgroot/Nasal/canvas/map/navdisplay.mfd, line 419


In such cases, always use getprop() or 0.00 instead: http://wiki.flightgear.org/Nasal_Conditionals
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 F-JYL » Fri Dec 06, 2013 11:39 pm

Additional error :

Code: Select all
Nasal runtime error: No such member: drawvor
  at /home/jylebleu/devmisc/fg_fs/install/fgfs/fgdata/Nasal/canvas/map/navdisplay.mfd, line 534
  called from: /home/jylebleu/devmisc/fg_fs/install/fgfs/fgdata/Nasal/globals.nas, line 105
Nasal runtime error: No such member: drawvor
  at /home/jylebleu/devmisc/fg_fs/install/fgfs/fgdata/Nasal/canvas/map/navdisplay.mfd, line 534
  called from: /home/jylebleu/devmisc/fg_fs/install/fgfs/fgdata/Nasal/globals.nas, line 105


Anyway great job, especially the 2d panel and all options available ! tested on last 777 commit
F-JYL
 
Posts: 54
Joined: Mon Mar 11, 2013 9:34 pm
Callsign: F-JYL
Version: git
OS: Ubuntu 13.10

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Fri Dec 06, 2013 11:55 pm

thanks for testing, those last two are not bugs per se: the code was moved to different files, and the listener is still referring to routines that are no longer there when changing frequencies.

So this should be really done as part of the model, or even better, the controller - however, that part wasn't yet done/available in the old map.nas hack and it won't be done, because we will hopefully be using MapStructure "soon"(ish).

At the moment, the ND/MapStructure code is purely aircraft-specific, and really only being used by the 744 and 777, as such, updates to it are not subject to the feature freeze in fgdata, but it is up to aircraft developers/fgdata committers to decide on an individual basis to commit improvements & bug fixes: http://www.mail-archive.com/flightgear- ... 33596.html
http://www.mail-archive.com/flightgear- ... 38749.html

In the meantime, a simple "solution" is to do what is done for drawroute/drawrunways, i.e. adding empty stubs to avoid errors.

The ND code really isn't "beautiful", I didn't rewrite the original code - so the ND code is just getting the job done without a complete redesign, i.e. supporting multiple ND instances, and reuse of the ND by other aircraft - I think, there will be another 2-3 design iterations once we have ~10-15 airliners adopting it, at which point it should be clear how to generalize things for all different needs. Meanwhile, I would prefer coming up with a real MFD framework that manages different displays/screens and image sources, according to: http://wiki.flightgear.org/CanvasMFD

That should then also help with PFD/CDU stuff.

But overall, Philosopher's MapStructure framework has been specifically designed to support the notion of controllers for these things, so need to add any heavy hacks to the code - we should better work together and ensure that MapStructure ends up in fgdata soon enough ...
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 F-JYL » Sun Dec 08, 2013 8:51 pm

I tried to correct the problem, see my patch here :

https://gitorious.org/fg/fgdata/merge_requests/234
F-JYL
 
Posts: 54
Joined: Mon Mar 11, 2013 9:34 pm
Callsign: F-JYL
Version: git
OS: Ubuntu 13.10

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Sun Dec 08, 2013 9:01 pm

good job, that's the defaulting paradigm that we're trying to get established as a best practice when using properties in mathematical expressions/calculations.
I never saw those errors/problems, but I also think that this is code that got recently added (?), otherwise I don't remember any issues with it.

@Gijs: this looks fine to me (not tested though), please test & commit if it works for you.
EDIT: http://code.google.com/p/flightgear-bug ... id=1294#c1
Last edited by Hooray on Tue Dec 10, 2013 3:42 am, edited 1 time in total.
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 Philosopher » Sun Dec 08, 2013 9:27 pm

Okay, I'm working on seeing if there's going to be room for MapStructure in the navdisplay.mfd.. ;) Now I face the problem of: how do I control the ND? I need to get VORs to show :? .
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Sun Dec 08, 2013 9:28 pm

Philosopher wrote in Sun Dec 08, 2013 9:27 pm:Okay, I'm working on seeing if there's going to be room for MapStructure in the navdisplay.mfd.. ;)

that part is straightforward actually, it's prepared for MapStructure after all, i.e.:

- change trigger_update() to update a map layer
- rename the layer names in NDStyles to match MapStructure names (e.g. vor becomes VOR)
- edit newMFD() and use your factory helpers instead of this: canvas.MAP_LAYERS[layer.name].new( render_target, layer.name, controller );
- get rid of those controller hacks (or ignore them for now)

to make this work without having all the other layers ready, just add a new VOR layer (copy paste a layer section), and use a contains() conditional to see if the key is in the hash, if it isn't, use your own factory helpers instead. Instead of calling trigger_update then, you'll want to directly call MapStructure's update (show/hide etc). That should get you going quickly, without having to port/remove/disable the other layers first. Obviously, just rename the original vor layer, or you will get two identical layers (visually, not functionally)

EDIT: Here's a stub/hack that shows how to disable things without touching tons of places: https://gitorious.org/fg/hoorays-fgdata ... 2006e9bd14

Now I face the problem of: how do I control the ND? I need to get VORs to show :? .


see those buttons directly above it, a handful of buttons, next to dials for range/map mode (744, it also shows tooltips once you found them)
those buttons control layer visibility (and apparently seem to trigger removeAllChildren() currently & surprisingly).

VORs, is the STA button (stations)
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 Gijs » Wed Jan 08, 2014 9:50 pm

Hi guys,

I've justed pushed the latest updates to the navdisplay. Partly from Hyde, partly from myself :-)

I did encounter a few bugs in the frame work. Would be nice if you could comment/address them.
  • The range of the Canvas map item doesn't work correctly. I need to set the map's range to ca. 1/3.2 the selected range in order to get the geo items displayed at the right locations (measured with the range arcs).
  • me.controller.queryrange() (for example in airports-nd.model), is always 100. No matter what the range is set to in navdisplay.mfd. This means we're always drawing/loading items for 100 NM, even when we're just displaying 10 NM! Vice versa, when the range is set to 640 NM, only airports within 100 NM are shown, leaving a big part of the display empty.
  • default_switches are completely ignored when custom switches are used. Only default switches that are set in custom switches should be ignored. Else we'll have to update all aircraft when we add new switches. Aircraft should only use custom switches when they use properties that are really custom and not generic.
  • The default values from the switches (both custom and generic) are ignored.

Cheers,
Gijs
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9544
Joined: Tue Jul 03, 2007 3:55 pm
Location: Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Wed Jan 08, 2014 11:57 pm

We already addressed some of your comments over on gitorious.

But I think there are some misconceptions here - some of the features you consider broken/missing would definitely be useful (e.g. default switch handling) - but they were never designed like this, most of the code is still based on your original code - so there isn't a lot of new functionality actually. My priority really wasn't coming up with a super-flexible ND framework back then, but really just prevents others from having to do "copy & paste" programming to adopt your code in other aircraft, while also supporting multiple instances.
Many other features would obviously be very useful, but they would need to be explicitly added.

And I've been going through your latest commit, and frankly, the nature of your commits isn't going to make the implementation of such -desirable- features any more straightforward :D

Honestly, we really need to move away from having huge "super-methods", I was actually hoping to reduce the update() method down to ~20-25 lines, and now you've inflated it massively by adding tons of conditionals there, most of which could have been expressed in a more succinct fashion... Even if you and Hyde are never going to touch this code again, it's making our work more difficult once Philosopher or myself need to refactor so much code that's really just copied & pasted together.

All those ugly hashes at the top of the file have a point: facilitating a move into XML space - anything that's currently declared in such helper hashes can be trivially moved into XML space, probably in less than 90 minutes of hacking - but once people continue creating/adding to supermethods with dozens of lines, things will not be as straightforward anymore. We really want to have lose coupling here.

The way things are headed currently, aircraft developers like omega95 or redneck are going to have a really hard time trying to reuse the code in other aircraft, like their Airbus fleet. I am afraid they're simply going to take your existing update() method, copy & paste it, and rename it "update_airbus()" - this is already all too common, and we really need to work against it.

Bottom line being: whenever there's something not supported, i.e. requiring massive hacks, it would be better to extend the underlying framework, rather than add more and more massive hacks to the code base - especially as long as there are only 2-3 different aircraft using this code, because there's nobody paying attention to all requirements here.

Note that I cannot currenlty run or test anything, and I am sure that the new features are great - but just from looking at the commits, I am concerned that we're adding too much to our plates like this.

Concerning priorities, I fully agree with Philosopher's comments over at gitorious - adopting MapStructure is most crucial right now, simply because it will improve performance for all use-cases.
But we really need to look into any ND method that has more than ~20 lines (excluding comments). - "code smell" you know ... :D
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 TheTom » Thu Jan 09, 2014 11:17 pm

Gijs wrote in Wed Jan 08, 2014 9:50 pm:The range of the Canvas map item doesn't work correctly. I need to set the map's range to ca. 1/3.2 the selected range in order to get the geo items displayed at the right locations (measured with the range arcs).

Seems to be very close to 1/pi :-)

I have just checked the map element (and pushed a small change):

The screen coordinates x and y describe the distance (given in NM) of the element along and perpendicular to the heading of the map. These distances are then scaled using the given range. The scaling factor depends on the screen-range given in map (canvas/screen) units and the corresponding "real" range in NM, and is calculated as screen-range/range. By this an object with a real distance of range NM will be drawn screen-range pixels (canvas units) away from the map center.

Previously screen-range was not changeable and fixed to 200. Now it can be changed by setting "screen-range" of the map element to the required value (200 is still the default value).
TheTom
 
Posts: 322
Joined: Sun Oct 09, 2011 11:20 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Mon Jan 27, 2014 5:05 pm

referring to navdisplay.mfd and its growing update() method:

what exactly is missing/the problem in order to instantiate new symbols via the hash lookup instead of adding everything to the update() method ?


Specifically referring to things like:
https://gitorious.org/fg/fgdata/source/ ... y.mfd#L999

- hdgGroup
- northUp
- aplSymMap
- aplSymVor
- planArcs

These are currently ALWAYS updated explicitly in the update() loop (via maketimer)
I think it would be better to communicate what's missing in order to move these things out of the update() method, so that they are no longer unconditionally updated - remember, we want to reduce the amount of unncessary updates.
And at the moment, a dt of 0.05 is pretty wasteful - so it would be much better to move things out the general update loop and only update them conditionally using a predicate.

Admittedly, using hashes for these things is a bit ugly, but it encourages decoupling and separation, so that we can later on move things to a different place or support other aircraft, without having to touch the update() method again

There's quite a few examples on adding new symbols accordingly: https://gitorious.org/fg/fgdata/source/ ... d#L181-999

I am mainly concerned about the separation issue, i.e. too much tight coupling going on, because I do not want to see "hard coded" statements that are aircraft specific - that is why the lookup hash was introduced.

Maybe we should add the ND to the 757, 767 and A320 so that aircraft developers can more clearly see the benefits of a decoupled design ?
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 Gijs » Mon Jan 27, 2014 5:21 pm

I've got some of it cleaned up already on my local system, hope to push it by the end of the week. Together with some fixes for Hyde's reports.

Just two more exams to go...

Cheers,
Gijs
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9544
Joined: Tue Jul 03, 2007 3:55 pm
Location: Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Mon Jan 27, 2014 5:41 pm

it would be also trivial to update things via listeners, or introduce custom timer objects for different elements - just let us know whats needed
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 » Tue Jan 28, 2014 1:20 pm

Update: I've been in touch with mueko, and he's interested in adopting the framework on the A320neo series, so this should help us ensure that things are indeed generalized, and that no Boeing-specific assumptions sneak in. I told him to get in touch with Gijs or Hyde if he has any integration questions that are specific to cockpit modeling (cannot help much here ...)

Also, if there are any other aircraft developers interested in adopting the ND framework, please DO get in touch, it really helps us design the whole thing
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

Next

Return to Canvas

Who is online

Users browsing this forum: No registered users and 8 guests