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 » Sun Jul 06, 2014 6:48 pm

Thanks for reporting Soitanen! I'll include a fix in tonight's update.

@Hooray, that's a completely different issue.
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9385
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 » Sun Jul 06, 2014 8:09 pm

Gijs wrote in Sun Jul 06, 2014 6:48 pm:@Hooray, that's a completely different issue.


not sure what you mean, I was referring to your posting here, where you said that you would be looking at "other ND bugs":

Subject: 777-Seattle ADF
Gijs wrote:Thanks for reporting! I'll have a look at this and other ND bugs this weekend, to make sure it's ready for the release.


For the sake of completeness, the WXR layer also still needs to be added to aircraftpos.controller as per: viewtopic.php?f=71&t=23413

Otherwise, I am not aware of any major issues, but I also haven't tested the ND extensively - but if there are any ND/MapStructure issues beyond your control, please make sure to report them in a timely fashion, so that we can take a look ASAP.
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: 11377
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Gijs » Sun Jul 06, 2014 9:26 pm

Sorry, thought you were referring to my post above. Anyhow, I've just pushed a couple of fixes to Git. I also moved some more code from the update() loop to navdisplay.styles. The remaining part is rather nasty, so that'll have to wait for another rainy Sunday.
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9385
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 » Sun Jul 06, 2014 9:28 pm

thanks for the update, I already responded via gitorious: https://gitorious.org/fg/fgdata/commit/ ... 6b#c107322

good job there - but regarding your updates to the *.draw files, I think you'll find that many of them are now unused, you'll probably want to update the corresponding .symbol files to change the z-index there. I don't think the ND still uses many of those draw files - last I checked there was only one left. Otherwise, it's just the airports.xml dialog that's still using them, which we are hoping to port to MapStructure post 3.2

In general, your changes look pretty good to me, and kudos for cleaning up the update() loop, really appreciated! Regarding the structure of the code, you'll find that ADF/VOR handling is basically copy&paste code for each instance, too (nav[0] vs. nav[1]) - so could be easily cleaned up and generalized, too post 3.2

BTW: The WXR changes I mentioned on the forum still need to be committed, or the WXR layer won't update properly

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

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Philosopher » Sun Jul 06, 2014 9:52 pm

  1. he already touched the *.symbol files to add the z-index
  2. he doesn't need to – I added a "z-index" field to the config hash for the very purpose ;) (I even did my best with copying the z-index from the *.draw files: https://gitorious.org/fg/fgdata/source/ ... styles#L58) It really shouldn't be hard-coded in the symbols though.
  3. only one *.draw file is used (airports-nd IIRC), and the rest can and should be deleted
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 » Sun Jul 06, 2014 9:59 pm

no, see my comments - and please remember our previous discussions: we probably cannot remove most *.draw files (yet) because of airports.xml not having been ported to MapStructure.
And regarding the commit, it contains changes to an unused draw file but is lacking the matching changes for the .symbol file in the case of ALT-profile if I am not mistaken ?
I agree that we'll usually want z-index handling to be handled by MS though - but those SVG symbols still lack any standard way for doing this.
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: 11377
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Philosopher » Sun Jul 06, 2014 10:07 pm

oh sorry, I keep forgetting about that. But how many does the dialog actually use? Probably not VOR, DME, etc., right?

And all layers support z-indexing, meaning RTE on top of VOR for example. Within each layer or symbol it must be managed though, but for layers themselves it will work.
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 » Sun Jul 06, 2014 10:13 pm

no, it's mainly those that we're still missing in MapStructure obviously (the others can go):

http://wiki.flightgear.org/MapStructure ... xml_dialog
  • parking
  • towers
  • airports
  • runways
  • taxiways

the first 2-3 can be easily ported (5 minutes each?), the remaining will be a bit of work due to the complexity involved.

I think in the case of airports vs. airports-ND and APT.symbol we're simply having one of those cases where appearance needs to be customizable, or at least such that the controller can be shared using an alternate .symbol file like you once mentioned. But we could also just provide a base class that allows the draw callback and/or the SVG file to be overridden for these purposes.
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: 11377
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Sun Jul 06, 2014 10:18 pm

One could also argue that the situation with airports is exemplary for our need to handle scale/LOD for different ranges, because then everything could be handled by a single .symbol file.
But I don't quite like the idea of cramming all the functionality into a single "APT.symbol" file - it would become kinda complex quickly, and not easily maintainable - I guess it would be better to maintain separate files and toggle between those, depending on current map range.

The other interesting thing is that airports.xml is supposed to only show a single airport for now, while our lcontrollers are designed to return a vector of airports.
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: 11377
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Gijs » Mon Jul 07, 2014 11:36 am

Philosopher wrote in Sun Jul 06, 2014 9:52 pm:I added a "z-index" field to the config hash for the very purpose ;)

Oops, I didn't notice that. I'll remove them from the symbols and update the config.

In the mean time I've found a bug with the airplane symbol on PLAN mode. It does not seem to move, it only rotates...
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9385
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 » Mon Jul 07, 2014 12:35 pm

that would make sense, see APS.symbol draw() - we're calling this each frame for now, but are assuming the centered mode, even though we should also be calling .setGeoPos() if in PLAN mode.
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: 11377
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Gijs » Mon Jul 07, 2014 12:39 pm

Well, it used to move (see airplane-symbol.draw) and now the positions on map itself are completely off as well (as in centered around the airplane symbol, no matter where you are).
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9385
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 » Mon Jul 07, 2014 12:45 pm

you're right - I think I (or Philosopher) "optimized" the whole thing without keeping the non-centered mode in mind.
For now, you can simply copy that line over to APS.symbol again - even though it would be better to only update this if the map mode isn't centered.
This is something that I've been discussing with Philosopher for a while: basically all the centering/translation handling should, IMO, be handled by the system, and not external code (navdisplay.mfd), because otherwise we need to introduce ugly workarounds.

Technically, we should also only have to update the rotation if it has changed - and update the position only in non-centered mode.
Otherwse, we're not exactly "canvas-friendly", due to unnecessary group updates - which is trivial here, but may add up with a few more less trivial layers.

Normally, MapStructure symbol files should rarely, if ever, have to use setGeoPos() directly on their groups, this should be handled by the framework - but APS was kind of a "corner case" and Philosopher extended the framework to specifically support "layers" with just a single symbol (which should also come in handy for porting airports.xml)

EDIT: just so that I don't forget about it: https://gitorious.org/fg/fgdata/commit/ ... 27d791423d

  • append(m.listeners ........ seems a common idiom: provide either a helper method or extend the underlying base class accordingly
  • WPT/RTE options should probably be exposed via the ctor, so that the ND code can override those defaults ?
  • unify WPT/RTE handling for wpt num ?
  • maybe provide a base class for both that encapsulates identical requirements ?
  • FIX.symbol still contains hard-coded colors, should be using styling there, TFC.symbol is using hard-coded colors & font size
  • navdisplay: swithcing between CTR & PLAN mode should be better supported by encapsulating setTranslation() etc
  • get rid of _draw_rwy_nd() calls
  • port runway-nd.draw , and support styling there
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: 11377
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Tue Jul 08, 2014 7:59 pm

Subject: NavDisplay & MapStructure discussion (previously via PM)
Gijs wrote:
Johan & Soitanen wrote: think this and similar problems will be coming up for more or less every aircraft as the properties differ between FDM:s and sometimes even between aircraft.
[...]
aircraft, which will use NavDisplay must have airspeed-indicator, created as built-in instrument, so I prefer to select airspeed indicator as source (which is close to reality).

We could implement a way for individual aircraft to feed the ND with their own properties. However, standardizing the properties would make more sense, also for other use cases (bindings for input devices, dialogs etc.). That is even more important for the PFD, since there are dozens of different autopilot properties being used in FlightGear.


This kind of thing is already done in both, MapStructure and the NavDisplay, it just isn't widely used yet - but we did establish the infrastructure for this. You must be aware of it, because you kept maintaining and fixing the NDSourceDriver logic that encapsulates properties for AI traffic. The same method can be found in aircraftpos.controller to hide aircraft specifics in a "delegate" hash that provides an "abstract interface" without the back-end code having to be aware of the underlying properties.

As long as aircraft developers agree to use, and help maintain, a corresponding hash, we can help enforce this as a "best practice" - but this should obviously be part of navdisplay.mfd itself (or even a separately-included file), so that it can be easily reused by PFD code eventually, without being specific to the MapStructure/ND code.

We reall only need to extend the ND.new() constructor to support such "overrides" and pass them on to the underlying callbacks, which is kinda touching the whole MVC approach already used by the MapStructure framework.
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: 11377
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Soitanen » Thu Jul 10, 2014 6:36 am

Gijs, about changing behavior of wind heading/speed/pointer, now it works slightly wrong. Now it disappears, if windspeed is less than 6 kt, but must be visible until 4 kts..
Here is citation from FCOM:
Displayed if wind magnitude is greater than 6 knots and blanked if wind magnitude becomes less than 4 knots.
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

PreviousNext

Return to Canvas

Who is online

Users browsing this forum: No registered users and 2 guests