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 Hyde » Tue Apr 29, 2014 4:37 am

Quick test.

Philosopher, I get following nasal errors.
Please check.
Code: Select all
Nasal runtime error: in_range: Invalid query range!
  at /home/hyde/work/FlightGear/fgdata/Nasal/canvas/MapStructure.nas, line 581
  called from: /home/hyde/work/FlightGear/fgdata/Nasal/canvas/map/TFC.lcontroller, line 84
  called from: /home/hyde/work/FlightGear/fgdata/Nasal/canvas/MapStructure.nas, line 487
  called from: /home/hyde/work/FlightGear/fgdata/Nasal/geo.nas, line 384
  called from: /home/hyde/work/FlightGear/fgdata/Nasal/canvas/MapStructure.nas, line 436
  called from: /home/hyde/work/FlightGear/fgdata/Nasal/canvas/MapStructure.nas, line 447
  called from: /home/hyde/work/FlightGear/fgdata/Nasal/canvas/MapStructure.nas, line 427
  called from: /home/hyde/work/FlightGear/fgdata/Nasal/canvas/api.nas, line 478
  called from: /home/hyde/work/FlightGear/fgdata/Nasal/canvas/map/navdisplay.mfd, line 932
  called from: /home/hyde/work/FlightGear/Aircraft/777/Models/Instruments/ND/ND.nas, line 72
  called from: /home/hyde/work/FlightGear/fgdata/Nasal/globals.nas, line 110

Thanks,
Hyde
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 » Tue Apr 29, 2014 2:45 pm

will test this tonight (I promise) and report back/provide a patch. @P: thanks for your work here, I realize that I should have been a bit more involved than I was probably.
As mentioned elsewhere, I don't currently quite see how we can finish porting those two map/airport dialogs in time for 3.2 to get rid of map.nas once and for all.
map-canvas.xml should only take 2-3 weekends, but the other dialog is still using *.draw files exclusively, i.e. those would need to be turned into *.symbol files for MapStructure, and unless someone else is going to step up to help with this, there's just the two of us obviously. It's not exactly difficult work, but also not exactly "exciting" either.

And I think there's still some controller magic missing to do airports.xml without map.nas ...
However, the MapStructure article on the wiki has seen almost 11k views meanwhile, so we're gathering a following here, but so far it seems to be mostly lurkers :lol:
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 » Tue Apr 29, 2014 2:54 pm

lol, true, but I've been dropping the ball here too (it's almost worse than writing documentation IMHO, but that's mostly just bias...). Thanks for your comments, I can test and fix most of these, maybe today (si felix esse potero...). While map.nas is deprecated, it probably isn't worth it (yet) to port the airport selection dialog yet, but creating a map dialog should be easy now - as long as we ignore panning/translating for the time being, and the flightplan. We should get adequate performance right now, but I will need to check with the 747, 777 to make sure.
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Tue Apr 29, 2014 3:04 pm

I am currently pushing master to the canvas-team clone (kinda forgot to keep it sync, and all the recent stuff is adding up, really need to set up a cron job to keep it up to date), but we should have a fresh branch based on fgdata:master in a few minutes, I will then also add the existing map-canvas.xml dialog there so that we can check what's missing. I agree, looking at airport.xml only makes sense once map-canvas.xml works as expected. flightplan stuff should actually be there, i.e. Gijs' code is showing routes just fine. panning/translating should be a matter of adding a handful of custom map controllers - that part should be more straightforward than actually porting airport.xml, because that's using a ton of non-generic Nasal code, even without the ugly map.nas stuff

Performance-wise, we really only need to add two optional systime() statementss at the controller level to see if there's anything heavy remaining, which would then be a candidate for SymbolCache.
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 » Tue Apr 29, 2014 3:08 pm

I'm such a non-pilot... I meant flight history :D
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Tue Apr 29, 2014 3:13 pm

right, history would be kind of a hack ATM, but I can ask Tom to review & commit the patch that I came up with a while ago - otherwise, we would need to register a timer that samples things like lat/lon/alt without being tied to MapStructure, i.e. a tiny helper class inside a Nasal submodule that gets instantiated during startup, so that MapStructure can rely on it, and share all sampled data, rather than having map-specific samplers that only have data for the lifetime of the shown map ... but given the known GC implications, that should be an entirely optional feature if implemented in Nasal - I guess it would be better to expose the corresponding history/replay hooks here instead. And it should take Tom/James less than 2-3 minutes to review & commit this, because the patch is kinda trivial.

PS: Performance-wise the main thing is ensuring that caching is used for dynamic/volatile layers with non-static objects (namely TFC for the time being)
And I am sure that Gijs & Hyde would agree that such changes qualify as "bug fixes", i.e. are not subject to the feature freeze as such :twisted:
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 Apr 29, 2014 4:26 pm

ok, the error/problem seems to be because getRange() is trying to access the range property, which simply isn't set at all (checked via the property browser).
According to navdisplay.mfd, there's a range property called "screen-range", added by Gijs.
as a workaround you can simply call query_range() for now, which defaults everything to 30 nm

but basically the toggle_range property is kept separate from the canvas/map range property, so needs to be sync'ed here
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 » Wed Apr 30, 2014 4:27 am

The range is definitely is synch'ed there, does rangeNm() not work anymore??? We aren't using a listener, just polling in update(). In the other layers I've cancelled the search if range == nil, so I could do that in TFC as well as an easy fix. I'm wondering if we need the whole "draw on init" thing, since that can cause problems, and a change like that wouldn't be noticeable to the user (difference of one frame, during which the splash screen is fading anyways).

P.S. query_range should be considered DEPRECATED, because the actual properties of the map control it now, and it's an error if there's no range set for the map (or should be - otherwise how would it render well?).
P.P.S. I didn't get time tonight - sorry, tomorrow should be a lot better.p
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Wed Apr 30, 2014 6:10 am

I'll check again, but what I saw here was a map group with a corresponding range property, while there was some kind of screen-range property
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 » Thu May 01, 2014 2:37 am

Okay, fixed the Nasal error (as I said, just don't update TFC is range is invalid). No idea what the screen-range is for, probably should just remove it.

Anyways, the ND does not seem to be a big issue (at least in the 747): besides lag when switching things on/off, it shouldn't contribute to frame rate loss. Normally it takes less that 0.3ms to update TFC (which is about the only volatile layer), although toggling FIX for the first time took about 135ms, while VOR/DME about 6ms each. The whole update of ND normally takes about 0.3ms but occasionally spikes up to 1.7ms, without the MapStructure update being affected. Other Nasal events seem to have a lot bigger effect on the 747, about 100ms vs 30ms according to system monitor. So the ND is pretty good right now. (I thought at first that it was worse than it looked.)
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Thu May 01, 2014 3:30 am

Ok, thank you !
FIX/135ms: we could pre-populate things by listening to the reset/re-init or FDM-iniitalized properties, so that it doesn't start at zero.
I think some of omega95/rednecks aircraft are doing this while "booting"
Regarding screen range, I think Gijs should comment 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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Gijs » Thu May 01, 2014 7:03 am

What screen-range?
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 » Thu May 01, 2014 7:44 am

see navdisplay.mfd, according to git blame you added that there

BTW: I think I figured out why range wasn't defined: https://gitorious.org/fg/canvas-hackers ... c65d6a94f9
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 » Thu May 01, 2014 6:18 pm

There are two kinds of ranges on a Canvas map: range and screen-range. Quoting Tom:
TheTom wrote in Thu Jan 09, 2014 11:17 pm: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.

I've set it to 700, because on the ND, 700 map units correspond to the range as set by the pilot. If you remove it, you'll get wrong scaled maps, as it defaults to 200 ;-)
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 » Thu May 01, 2014 6:33 pm

thx, I totally missed that (despite having responded there right after Tom's posting....) it makes sense, even though the property should be renamed screen-range-nm to be more self-explanatory, and in line with other properties having the same unit...
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

PreviousNext

Return to Canvas

Who is online

Users browsing this forum: No registered users and 8 guests