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 Gijs » Thu May 01, 2014 6:28 pm

I believe it's not necessarily nautical miles. Scales are dimensionless in general, so it could be anything.
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9365
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 May 01, 2014 6:30 pm

I guess I am getting too distracted in all the other threads, thanks for clarifying though...
EDIT: actually, range does seem to be "unit-less", I just checked it ??
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby F-JYL » Mon May 05, 2014 7:57 pm

Hello,
Since commit 23b9b7065a7279184511e60ab7163636e803083e
the 777 ND display is still out of order with the latest Git fgdata version. What should be done to get it back anything to change in 777 ND code ?
Code: Select all
Nasal runtime error: in_range: Invalid query range!
  at /home/jylebleu/devmisc/fg/fgfs/install/flightgear/fgdata/Nasal/canvas/MapStructure.nas, line 581
  called from: /home/jylebleu/devmisc/fg/fgfs/install/flightgear/fgdata/Nasal/canvas/map/TFC.lcontroller, line 84
  called from: /home/jylebleu/devmisc/fg/fgfs/install/flightgear/fgdata/Nasal/canvas/MapStructure.nas, line 487
  called from: /home/jylebleu/devmisc/fg/fgfs/install/flightgear/fgdata/Nasal/geo.nas, line 384
  called from: /home/jylebleu/devmisc/fg/fgfs/install/flightgear/fgdata/Nasal/canvas/MapStructure.nas, line 436
  called from: /home/jylebleu/devmisc/fg/fgfs/install/flightgear/fgdata/Nasal/canvas/MapStructure.nas, line 447
  called from: /home/jylebleu/devmisc/fg/fgfs/install/flightgear/fgdata/Nasal/canvas/MapStructure.nas, line 427
  called from: /home/jylebleu/devmisc/fg/fgfs/install/flightgear/fgdata/Nasal/canvas/api.nas, line 478
  called from: /home/jylebleu/devmisc/fg/fgfs/install/flightgear/fgdata/Nasal/canvas/map/navdisplay.mfd, line 932
  called from: /home/jylebleu/devmisc/fg/Aircraft/777/Models/Instruments/ND/ND.nas, line 72
  called from: /home/jylebleu/devmisc/fg/fgfs/install/flightgear/fgdata/Nasal/globals.nas, line 110

Image
Thank you for your answer.
F-JYL
 
Posts: 54
Joined: Mon Mar 11, 2013 8:34 pm
Callsign: F-JYL
Version: git
OS: Ubuntu 13.10

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Tue May 06, 2014 8:02 pm

I think the branch on canvas-hackers should contain a fix for this, need to check again - but last I checked, we knew where & why this was caused, basically all the layer setup requires map-range et al to be set up properly first, because the init stuff depends on that stuff - which isn't the case currently - that's what needed to be fixed in the dialog we used for testing (shuffling around a few lines of code did it basically), and I suppose it's the same thing here (?), it would make sense given the error message, but it would probably be found in navdisplay.mfd. I guess we need to harden the framework a bit and die() whenever a ctor is called without required properties being set up first.
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby F-JYL » Fri May 09, 2014 4:40 am

So can you tell what have to be done to make it usable again ?
F-JYL
 
Posts: 54
Joined: Mon Mar 11, 2013 8:34 pm
Callsign: F-JYL
Version: git
OS: Ubuntu 13.10

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Fri May 09, 2014 6:52 pm

F-JYL wrote in Fri May 09, 2014 4:40 am:So can you tell what have to be done to make it usable again ?


Well, as I mentioned already previously, due to some recent refactoring, the .setRange()/getPosCoord() methods now need to be called prior to the MapStructure layers getting added (the constructors depend on those properties now), or you need to return early if any of those calls return nil (in searchCmd) - so as a quick workaround, something like the following one-liner should probably work if added to MapStructure.nas itself:
Code: Select all
diff --git a/Nasal/canvas/MapStructure.nas b/Nasal/canvas/MapStructure.nas
index 1bc20fe..12778ce 100644
--- a/Nasal/canvas/MapStructure.nas
+++ b/Nasal/canvas/MapStructure.nas
@@ -484,6 +484,7 @@ var SymbolLayer = {
                return nil;
        },
        searchCmd: func() {
+               if (me.map.getPosCoord() == nil or me.map.getRange() == nil) return []; # handle layers not yet fully initialized
                var result = me.controller.searchCmd();
                # some hardening TODO: don't do this always - only do it once during initialization, i.e. layer creation ?
                var type=typeof(result);



This should check if the map isn't yet initialized properly (i.e. range/position being n/a), and return an empty set of results (i.e. a vector) instead of running the actual searchCmd() as provided by the MapStructure .lcontroller file, which "depends" on those properties being available now.
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Philosopher » Fri May 09, 2014 7:43 pm

Hallo,

I'm terribly sorry - life, school and music have been pulling me away lately. But this weekend should be relatively free, so I can do stuff then. I promise :)

I have some changes that are piling up. Most issues have been fixed I think, particularly that one. There's still things I need to work on - and I guess I would like the see the ND fully initialized when we start MapStructure construction, but I don't quite know how/if that will work. I've been cleaning up various parts as well, and am considering removing the *.draw files etc. for the next commit. Once I get those prepared (tested!), merged, and pushed to fgdata I'll continue on with the map-dialog itself, hoping that we'll have support for enough things.

@H: I was thinking of working on the styling a bit more - supporting that I think will be key for diverse uses. Once I start loading files by extension, we should be able to have say both a VOR-ND.symbol and a VOR-MAP.symbol yet use the same VOR.lcontroller. Similarly, styles and other options (e.g. radio or autopilot properties) should be doable, and I know we have stubs for these right now, it's a matter of using them. Is there anything else we need addressed right now? (Other than WPT.) Is there also something I can do to help with your flight history patch? I would be willing to aim for a map-dialog with flight history pretty soon, so having Tom or James commit that would be crucial. I could test it locally and start on a layer if needed.

Thanks for your support, all!
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 Soitanen » Fri May 09, 2014 7:56 pm

From last PM from Hooray:

I'm using latest fgdata and FG from git.
Bugs:
- ND still broken, like 5 posts above;
- route drawing do not update, if I make changes in route, or activate it. I need to change mode of ND and go back to previous mode to see changes;
- don't remember correctly (now it doesn't work, so I can't check), groundspeed or TAS (more likely) is wrong on ND. I think wrong source for this number is selected;
- in my 737 I have created 2 ND objects for captain and FO, but I have some problems with FO's ND. It doesn't shows, but is clickable. I don't know what's wrong and can't solve this by myself (may be it's not ND bug);
Performance:
I don't see any performance bugs, maybe only first showing of airports.
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 Hooray » Fri May 09, 2014 8:13 pm

wow, lots of developments... I didn't expect you had that much stuff up your sleeve, otherwise I wouldn't have touched anything. Styling-wise I just committed a quick workaround so that APT ends up with basic "LOD" support on top of styling via setScale(). Feel free to revert my stuff, I just wanted to make sure that aircraft devs can still use the code.

- full ND initialization: should be pretty simple, but update() is no longer straightforward, so need to check first
- completely removing *.draw files: tricky at best, requires porting all the stuff to MapStructure, and then porting the airport-select dialog - so better postpone this ??
- there are still a few "heavy" layers, especially runways & taxiways that are not yet ported to MapStructure, I once looked into it, and I would prefer to generalize SymbolCache to help with runways, and possibly even taxiways (to some extent). I am thinking of having at least a SymbolCache that caches runways and taxiways for a handful of airports, so that those can be shared among different displays (NDs and/or GUI dialogs, without having to be procedurally redrawn)
- I don't think we should remove most draw files until the map dialog itself works, and until things have been ported to MapStructure - the airports.xml dialog is not exactly "generic" ATM either, but will check your work and make up my mind ...
- styling: sounds good to me, and very clean - so far, I was just thinking of putting this all into the same .symbol file, but your idea sounds even better. Even though I'd prefer to use SVGs and parameterize those via callbacks/style hashes
- also, styles should maybe "merged" with the default style, so that styles can be partially customized ? I just had to work around that by replicating the full default style :-/
- styles are currently not yet integrated with caching, I prototyped that in DME.symbol, but didn't finish anything, let alone generalize/extract useful bits to become part of MapStructure.nas
- options is actually prepared - but both, options AND styles are just implemented as hashes, so we better add a method that validates a passed hash to check for supported/unsupported keys, i.e. better usability and improved debugging ?
- WPT/RTE not sure if Gijs or Hyde ever looked into it, maybe I should get this started.
- flight_history() is being reviewed by Tom already, thanks for asking though!
- the layer itself should be trivial actually
- to fully port the map dialog, we may need some "non-symbol" layers, i.e. cartographic stuff like a lat/lon grid and maybe Gijs' extended projection support ?

Overall, I would prefer to identify common building blocks and move functionality into MapStructure.nas instead of requiring coders to remember certain things and manually check if something is nil and return early...I think this is something that belongs into the framework, we cannot expect people to do "defensive programming". And styling/options is something that could be generalized, we really just need to extend the lcontroller or symbol ctors to register a set of supported keys for those hashes, and then validate those during startup/construction, i.e. bail out if a key is missing or unsupported.
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Fri May 09, 2014 8:24 pm

When I edited APT.symbol I was actually wondering if we should really keep the df_style in the lcontroller file, or maybe better make it a part of the symbol file ?
The main point being that having a helper function that looks up a style and assigns a sane default value would be simple to implement there, e.g.:

lookup (key:"font_color", default:[1,0,0]);

maybe that would be more convenient to maintain/use for people ?
We could use the same mechanism for options, and even provide a required:1 flag to bail out if it's missing ?

EDIT: RTE/flightplan() is another thing that would benefit from supporting options, as most airliner CDUs seem to support multiple routes (at least ACTIVE/INACTIVE)
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Fri May 09, 2014 8:49 pm

Is there anything else we need addressed right now? (


zooming/panning etc will require integration with canvas event handling and MapStructure controllers (map/layer/symbol).
I looked into simply extending addLayer() accordingly to accept additional/optional arguments for these purposes.

As mentioned previously, I have been playing around with showing tooltips for individual airport symbols, by rendering a full airport view with runways on "mouseover" events.
Obviously, that's primarily of interest for GUI stuff -but it's something that we'll want to support infrastructure-wise - eventually, we could then also preload such "tooltips" with other useful info, such as comm/navaid frequencies.

Currently, the main issue is that PUI CanvasWidgets and native Canvas windows are competing for mouse input, but also visibility - but it's something that I wanted to keep in mind, i.e. having a simple way to register event handlers would allow us to provide simple interactive editing support, too - for starters, that's something that we could hook up to Marius_A's missions system - for example, in order to visually place scenery elements on a map by moving an oilrig symbol around, that actually ends up calling geo.put_model() in the background. We seem to be more than halfway there already, and Thorsten also once mentioned that he was considering to use such a system for visual weather pattern placement
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Johan G » Sat May 10, 2014 1:37 am

Hooray wrote in Fri May 09, 2014 8:49 pm:Currently, the main issue is that PUI CanvasWidgets and native Canvas windows are competing for mouse input, but also visibility...

My experience is that the PUI windows does the same in between each other (FG 2.4.0 and 3.0.0). I have never been able to have two windows overlapping each other without having the bottom one pop up now and then unless I am very careful to not move the mouse pointer over areas where the hidden window is. Something I think I probably should have filed a bug report for years ago, though of course someone might already have done that.

I.e. it might be a deeper problem.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5513
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Sat May 10, 2014 6:30 pm

@P.: I am going to touch a few more files to prototype event handling support for layers (e.g. for tooltips or mouse interaction), if there are any files that you don't want me to touch at all due reduce the chance of introducing merge conflicts just say so, so that I'll use a few other files, or introduce a new layer for testing (could use TUT if 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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Philosopher » Sat May 10, 2014 6:43 pm

Nope, you're fine - I don't have anything pending yet (just an idea for drawing lines in MapStructure so that FLT will be just a few lines).
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 » Sat May 10, 2014 6:49 pm

yeah, makes sense to look at the selected map range, determine how many pixels equal 1 nm (actually, that should be provided by canvas somewhere, as it could also help determine if an update is necessary or not) and then use that as a rough approximation to plot a few connected line segments
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

PreviousNext

Return to Canvas

Who is online

Users browsing this forum: No registered users and 6 guests