What's going on with the Navdisplay

[Jabberwocky]

Hi,

I work with SkyBoat on the MD-10 and all was fine with the Canvas-Navdisplay in 3.0. Now, SkyBoat has installed the release candidate for 3.2 and ...

Nasal runtime error: non-objects have no members
at F:\FlightGear 3.2.0\data/Nasal/canvas/map/navdisplay.mfd, line 136
called from: F:/FlightGear 3.2.0/data/Nasal/canvas/map/navdisplay.styles, line
530
called from: F:\FlightGear 3.2.0\data/Nasal/canvas/map/navdisplay.mfd, line 68
8
called from: F:/FlightGear 3.2.0/data/Aircraft/MD-10/Models/Flightdeck/Instrum
ents/Center-mfd/ND.nas, line 72
called from: F:/FlightGear 3.2.0/data/Nasal/globals.nas, line 119
KLN-90B GPS ...Check
Chronometer ... Check
Nasal runtime error: non-objects have no members
at F:\FlightGear 3.2.0\data/Nasal/canvas/map/navdisplay.mfd, line 136
called from: F:/FlightGear 3.2.0/data/Nasal/canvas/map/navdisplay.styles, line
530
called from: F:\FlightGear 3.2.0\data/Nasal/canvas/map/navdisplay.mfd, line 68
8
called from: F:\FlightGear 3.2.0\data/Nasal/canvas/map/navdisplay.mfd, line 21
9
Nasal runtime error: non-objects have no members
at F:\FlightGear 3.2.0\data/Nasal/canvas/map/navdisplay.mfd, line 136
called from: F:/FlightGear 3.2.0/data/Nasal/canvas/map/navdisplay.styles, line
530
called from: F:\FlightGear 3.2.0\data/Nasal/canvas/map/navdisplay.mfd, line 68
8
called from: F:\FlightGear 3.2.0\data/Nasal/canvas/map/navdisplay.mfd, line 21
9
Nasal runtime error: non-objects have no members
at F:\FlightGear 3.2.0\data/Nasal/canvas/map/navdisplay.mfd, line 136
called from: F:/FlightGear 3.2.0/data/Nasal/canvas/map/navdisplay.styles, line
530
called from: F:\FlightGear 3.2.0\data/Nasal/canvas/map/navdisplay.mfd, line 68
8
called from: F:\FlightGear 3.2.0\data/Nasal/canvas/map/navdisplay.mfd, line 21
9
Nasal runtime error: non-objects have no members
at F:\FlightGear 3.2.0\data/Nasal/canvas/map/navdisplay.mfd, line 136
called from: F:/FlightGear 3.2.0/data/Nasal/canvas/map/navdisplay.styles, line
530
called from: F:\FlightGear 3.2.0\data/Nasal/canvas/map/navdisplay.mfd, line 68
8
called from: F:\FlightGear 3.2.0\data/Nasal/canvas/map/navdisplay.mfd, line 21
9
Nasal runtime error: non-objects have no members
at F:\FlightGear 3.2.0\data/Nasal/canvas/map/navdisplay.mfd, line 136
called from: F:/FlightGear 3.2.0/data/Nasal/canvas/map/navdisplay.styles, line
530
called from: F:\FlightGear 3.2.0\data/Nasal/canvas/map/navdisplay.mfd, line 68
8
called from: F:\FlightGear 3.2.0\data/Nasal/canvas/map/navdisplay.mfd, line 21
9
Nasal runtime error: non-objects have no members
at F:\FlightGear 3.2.0\data/Nasal/canvas/map/navdisplay.mfd, line 136
called from: F:/FlightGear 3.2.0/data/Nasal/canvas/map/navdisplay.styles, line
530
called from: F:\FlightGear 3.2.0\data/Nasal/canvas/map/navdisplay.mfd, line 68
8
called from: F:\FlightGear 3.2.0\data/Nasal/canvas/map/navdisplay.mfd, line 21
9

Well, as you can see, this is moslty inside navdisplay.mfd. How many new standard properties I have to define and where are they documented? Styles seems to be new with 3.2 and since I am still on 3.0, I don't have it. So ... backwards-compatibility for all Canvas navdisplay is in doubt at this point? Or what's the problem here?

J.

[Gijs]

The navdisplay is not backwards compatible, because it was not designed to be so. Your case seems to be about forwards compatibility though (ie something that runs on 3.0 doesn't run on 3.2).

Do you have /mfd/rangearc defined (e.g. instrumentation/efis/mfd/rangearc)? I see we didn't add that one to the wiki, so maybe you've missed it. I've just updated the wiki: http://wiki.flightgear.org/Canvas_ND_Fr ... t_switches

[Hooray]

supporting backward compatibility would not be too difficult as long as people only use the purely-declarative hash configuration method for setting up their own ND, so that we only have to deal with the aircraft agnostic code

[Jabberwocky]

Hi Hooray,

sorry, I was a little busy, so only now a reply ...

The way to aircraft agnostic code would be in this case navdisplay.styles, only that one is located in canvas/map, not in the aircraft. And it didn't even exist in 3.0. And since, as I found out, the include of navdisplay/styles seems to be hard-coded in nacdiaplay.mfd, I can't even lead it around to a specific file in the airport, at least not without touching "general" as in "non-.aircraft-specific" code.

And it appears, we are both right, for- as backward-compatibility-wise. At least, I don'T see a way to use the 3.2 utilities that make it also working for 3.0, nor can I do it vice-versa. I can't even use a local copy for a quick fiy to gain some time win here because the objects are not loaded into the canvas then by the generla canvas system. Which hurts a little because SkyBoat would really like to fly his plane with his 3.2 installation on FlightGear Weekend. So, how do I get out of this catch-22 thing?

J.

[Hooray]

Sorry, completely missed your response - also kinda busy ATM, so just briefly:

• navdisplay.styles is a container file, its location doesn't matter in terms of functionality available to a certain aircraft and/or GUI dialog etc
• for integration details/tutorials, please refer to the official wiki article
• for the time being, the underlying code isn't yet completely aircraft agnostic
• but like you say, this is being increasingly generalized and refactored
• yeah, the include directive is there for a reason and it doesn't need to be touched at all
• backward compatibility itself could indeed be tackled by simply using hashed and using an io.include() directive that incorporates the version number requested
• it is not difficult per se, it just isn't done currently - Tom's own code uses function generators for pretty much the same purpose
• using 3.2 in 3.0 is obviously not possible - search "forward compatibility", the opposite is not difficult - a compromise would also be possible, artix has been doing that to support his recent Airbus work on 3.0, too - simply by copying and changing updated 3.2 files - so it is possible and not necessarily too difficult. Even though the approach was kinda hackish - he's been working towards cleaning this up meanwhile
• if you cannot get that to work, it's not a FG/Nasal or Canvas problem, but it's on your side - I'd suggest to look at artix' repo/thread as a reference, but don't expect any of this/such code to be committed "as is" - it is a huge maintenance nightmare in that form and would cause many problems in the mid-term (the local copy)

Overall, we may sooner or later support backward compatibility by using something like io.include() with a nested version number and/or API call, it is not exactly difficult. For now, it would require just a few lines of code. The real challenge is that the code is very much evolving still, so it would be premature to implement something like that currently, especially because there's still many features missing so that establishing feature parity would be difficult at best - once things stabilize, and once multiple styles/aircraft are supported, we could/should revisit that. But unless someone else steps up to implement a working scheme, I am not currently interested in establishing such an API, at a time when things are being constantly refactored - we are seeing a handful of related efforts currently. And even Gijs mentioned a few times that he's still hoping to add new features - so adding API-level versioning/backward compatibility would probably become pretty awkward soon, and it would also involve other parts that don't actively support backward compatibility - Tom is using a getprop("/sim/version") check in api.nas - so it is possible, but only makes sense once the dust settles.

At least for the time being, I'd estimate that it might take another 2-3 release cycles until this should be re-considered, unless we'll see more ND contributions rolling in shortly.

If you do want to work out some kind of BC scheme, you are obviously invited to post your thoughts, I won't object any suggestions and will surely help review them to get them committed - but I'd probably not target 3.0, but instead 3.2 so that you have some kind of baseline to work with.