Board index FlightGear Development Canvas

Mapstructure request for help - nasal error

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: Mapstructure request for help - nasal error

Postby legoboyvdlp » Thu Jun 13, 2019 9:15 am

Looks like Hooray and Philosopher wrote it? :?

I think I have a clue - if it is correct that will show why the error is different in Borings and on Airbuses :)
User avatar
legoboyvdlp
 
Posts: 7009
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: 2018.3.1
OS: Windows 10 HP

Re: Mapstructure request for help - nasal error

Postby Gijs » Thu Jun 13, 2019 9:20 am

Hi all,

When I created the original ND some six years ago, there was no Mapstructure. Canvas itself was actually a very new thing in FlightGear back then. My original hard-coded display got adapted by Philosopher and Hooray to ensure that it could be re-used on other aircraft, added as multiple stand-alone displays to one aircraft and many other features. The Airbus 'style' was done by some-one else (I think Artix?). The current state is far beyond my level of Nasal, so unfortunately I'm probably not much of a help in debugging the issue*.

You must understand that the current structure is the result of an organically growing piece of code, based on something that was never intended to end up like this. As such it is far from the best solution and I don't think it's fair to get mad at the people who've created it in a time when there wasn't anything alike. If someone is interested in writing a new ND from scratch he can probably come up with a much better system now thanks to the fact that there's much more experience with Canvas these days, as well as several improvements to the navigation database/API. Same applies to my PFD, which was the first to use Canvas and is far from optimized.

I'd wholeheartedly support such an initiative, as I think there's a lot to be gained. But, don't underestimate the difficulty of providing a solution that is both flexible and solid.

Cheers,
Gijs

* I haven't looked at it in detail due to my graduation consuming all of my time, but from the reports I've seen the issue is hard to reproduce consistently. I've just tried Jonathan's recipe at EGAA with the 744, but everything looks fine here. That makes it difficult to trace down the cause.
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: Mapstructure request for help - nasal error

Postby legoboyvdlp » Thu Jun 13, 2019 10:28 am

That's rather odd indeed.

Anyway - in the 777 I can reproduce this every time. I cannot however reproduce the error I have been trying to reproduce... :?
Code: Select all
Nasal runtime error: vector index -1 out of bounds (size: 0)
  180.20 [ALRT]:nasal        at C:/Users/redpa/Documents/Programs/FlightGear 2018.3.0/data/Nasal/canvas/map/WPT.lcontroller, line 62
  180.20 [ALRT]:nasal        called from: C:/Users/redpa/Documents/Programs/FlightGear 2018.3.0/data/Nasal/canvas/map/WPT.lcontroller, line 86
  180.20 [ALRT]:nasal        called from: C:/Users/redpa/Documents/Programs/FlightGear 2018.3.0/data/Nasal/canvas/MapStructure.nas, line 1088
  180.20 [ALRT]:nasal        called from: C:/Users/redpa/Documents/Programs/FlightGear 2018.3.0/data/Nasal/geo.nas, line 384
  180.21 [ALRT]:nasal        called from: C:/Users/redpa/Documents/Programs/FlightGear 2018.3.0/data/Nasal/canvas/MapStructure.nas, line 1051
  180.21 [ALRT]:nasal        called from: C:/Users/redpa/Documents/Programs/FlightGear 2018.3.0/data/Nasal/canvas/MapStructure.nas, line 1059
  180.21 [ALRT]:nasal        called from: C:/Users/redpa/Documents/Programs/FlightGear 2018.3.0/data/Nasal/canvas/map/WPT.lcontroller, line 26
  180.21 [ALRT]:nasal        called from: C:/Users/redpa/Documents/Programs/FlightGear 2018.3.0/data/Nasal/globals.nas, line 119


It happens immediately after hitting activate.

The steps were the same: load FlightGear, depart EGAA runway 35, DEFAULT sid, then EDDF 25L ILSZ25L and UNO25S STAR, then enter IOM and WOD between DEP-4 and UNOKU, and hit activate.

The waypoints aren't showing on the navigation display.






Right - I removed runway 35 and set runway 25 including its SID. It worked just fine as expected.

Then, I removed IOM and WOD waypoints.

And... it is not reproducing here either... only the wpt.lcontroller error....???




Ok - I then changed the runway at EDDF to 25R, ILS25R, UNO25N... and changed the runway again from 25 to 35. This time it failed:

Image

So... I will ammend my steps I suppose.
User avatar
legoboyvdlp
 
Posts: 7009
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: 2018.3.1
OS: Windows 10 HP

Re: Mapstructure request for help - nasal error

Postby legoboyvdlp » Thu Jun 13, 2019 10:49 am

So - new steps:

Let's see if this finally works...

  • Load EGAA35 - DEFAULT - IOM - WOD - 25L EDDF ILSZ25L, UNO25S
  • Make EGAA-35 the active waypoint
  • Activate flightplan, then remove IOM and WOD
  • change EDDF to 25R, ILS, UNO25N.
  • change the departure runway to EGAA25, set the default SID

Image

You should see:
- no waypoint names or waypoint "stars" on the ND until you change the runway of arrival to EDDF25R
- broken waypoint names and stars after you change the runway of departure to EGAA25.

This was in the 777. I have reproduced this three consecutive times. I really hope someone else can reproduce it... but it certainly is an odd error :?



The cruicial thing is - this only happens when you remove waypoints, THEN change the arrival runway!

Notice this is not reproduceable with the IDG-A32X, since it doesn't use the Boeing wpt.lcontroller, but the Airbus one. I only ever get
Code: Select all
Nasal runtime error: flightplan.insertWaypoints expects vector as first arg
  264.44 [ALRT]:nasal        at C:/Users/redpa/Documents/Programs/FlightGear 2018.3.0/data/Nasal/route_manager.nas, line 63
on the Airbus.
Last edited by legoboyvdlp on Thu Jun 13, 2019 10:59 am, edited 2 times in total.
User avatar
legoboyvdlp
 
Posts: 7009
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: 2018.3.1
OS: Windows 10 HP

Re: Mapstructure request for help - nasal error

Postby Gijs » Thu Jun 13, 2019 10:58 am

Oooh, I don't have a Navigraph subscription. I guess this does not happen with the default FlightGear STARs?
Excuse me if this has been tested before, but would be interesting to know if the in-sim map dialog has the same issue.

Notice this is not reproduceable with the IDG-A32X, since it doesn't use the Boeing wpt.lcontroller, but the Airbus one.
It would make sense then to compare the two and see where they differ.
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: Mapstructure request for help - nasal error

Postby legoboyvdlp » Thu Jun 13, 2019 10:58 am

That would be good to know - I'll check it right now using DEFAULT at EDDF.


Edit - I cannot reproduce it. I do not know unfortunately if its because the error only happens when I have a STAR or whether its something to do with Navigraph procedures...


If anyone is interested in testing, I can send them a copy of EDDF.procedures.xml via direct message for testing purposes...?
User avatar
legoboyvdlp
 
Posts: 7009
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: 2018.3.1
OS: Windows 10 HP

Re: Mapstructure request for help - nasal error

Postby legoboyvdlp » Thu Jun 13, 2019 11:37 am

Right - the error occurs because wp.path is returning a vector of zero length. So, at line 62, this code:

Code: Select all
if (idx) var n = wp.path()[-1];


fails.

The route manager also reports a similar error on line 40:
Code: Select all
me.flightplan.insertWaypoints(sid.route(me.flightplan.departure_runway), 1);


Where sid.route(me.flightplan.departure_runway) also returns a vector of zero length.



Anyone know where the source code of sid.route() is? Is that https://sourceforge.net/p/flightgear/fl ... .cxx#l1620? (function f_airport_sids)?
User avatar
legoboyvdlp
 
Posts: 7009
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: 2018.3.1
OS: Windows 10 HP

Re: Mapstructure request for help - nasal error

Postby wkitty42 » Thu Jun 13, 2019 6:53 pm

legoboyvdlp wrote in Thu Jun 13, 2019 9:15 am:Looks like Hooray and Philosopher wrote it? :?

i couldn't think of Hooray the other day when i wrote what i wrote... but, yeah, i remember them being quite involved and pushing it for use/adoption... they certainly haven't been around very much lately... at least, not visibly (aka by posting messages)...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5651
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Mapstructure request for help - nasal error

Postby legoboyvdlp » Sat Jun 15, 2019 10:00 am

Right -

I have traced the error to f_procedure_route:

I added a debug statement on line 3160, and sure enough:

Code: Select all
 saw arrival changed
  271.06 [ALRT]:nasal      routing via STAR UNO25N
  271.06 [INFO]:navaid     approach ILSY25R has no transition for IAF: DF422
  271.06 [WARN]:nasal      returning nil on line 3160 NasalPositioned.cxx
  271.06 [ALRT]:nasal      couldn't route approach based on specified IAF DF422
  271.06 [ALRT]:nasal      routing via approach ILSY25R


(also, I don't know why I never got these messages before - surely the default log level is higher than ALERT? I don't even get the "couldn't route approach based on... )
User avatar
legoboyvdlp
 
Posts: 7009
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: 2018.3.1
OS: Windows 10 HP

Re: Mapstructure request for help - nasal error

Postby Octal450 » Sat Jun 15, 2019 3:56 pm

Good work Lego! Look at you going above and beyond.

Kind Regards,
Josh
Octal450
 
Posts: 4397
Joined: Tue Oct 06, 2015 12:51 pm

Re: Mapstructure request for help - nasal error

Postby Hooray » Sat Jun 15, 2019 7:57 pm

Hi,

just briefly (based on skimming a few postings on the first page of this thread), and to provide a little background information/context:

- the error shown on the first page of the thread shows a conventional "vector out of bounds" error, that's a standard Nasal thing - it's unrelated to MapStructure per se, it just says that some kind of API call returned something that was either not a vector or the vector didn't have the right size (length, number of elements).

- as far as I can tell, this is not specific or related to the MapStructure side of things, because everybody who responded to that posting said quite clearly that this showed up in recent binaries, the MapStructure stuff hasn't changed in years as far as I am aware.

- MapStructure itself evolved indeed "organically" as Gijs has alluded to, i.e. he came up with the ND code orignally, and it was highly specific to a single aircraft, and didn't support different aircraft, multiple independent instances or any kind of code reuse.

- Subsequently, a few of had the discussion whether/how to address these goals, i.e. to make Gijs code more modular and better reusable, what happened then, was that the ND code was basically copied/pasted to a different file and all mapping/charting related aspects of it were moved into a MVC-based architecture with different files for "layers of symbols", with a handful of generic classes to provide support for different kind of layers and symbols.

- The next thing that needed changing was to support "generic" handler so that different aircraft (cockpits) but also other means (UI dialogs) could be used to "control" those maps consisting of layers and layers consisting of symbols.

- Thus, what must have really happened here is that some kind of underlying system implemented in C++ changed either its behavior, or some edge case isn't properly handled.

Either way, fixing this is not difficult, but it's actually not the task of the MapStructure framework - I suppose that either front-end using those APIs, will trigger the same issue.

But the Nasal "fix" is simply to handle this case more gracefully, e.g. by doing a typeof()=="vector" check, that's it.

If in doubt, you can always shoot a PM to the people involved in writing the original code (or use the wiki to get in touch) - we are usually happy to provide answers, even if we are not currently around. You can look up the history of a file by looking at the commits logs, or the wiki pages documenting the framework.

PS: All that being said, please do feel free to rewrite whatever MapStructure code you'd like to see re-done, I would just suggest to tread carefully here: Be sure to really try to understand what the MapStructure framework is trying to do, how it came to be, and how it is structured to accomplish these goals, i.e. what it is doing, why and how. As Gijs said, nothing is set in stone here - but it doesn't make that much sense to redo (or even just ignore) MapStructure without understanding its scope and surrounding context. I'd even go as far as saying that you are unlikely to accomplish those goals, without going doing some kind of similar path (using a similarly decoupled approach). As far as I am aware though, the FG1000 remains the most "state of the art" avionics suite that satisfies these modularity/reuse requirements, and it too, happens to use the MapStructure framework.

Back when all this "happened", we were literally faced with a massive piece of code written single-handedly by Gijs, who never really shared his progress/approach until he considered it ready for primetime - so we saw some awesome looking screenshots/videos and loved the functionality, but all other aircraft developers wanting to reuse that instrument elsewhere, simply couldn't do so - and that also applied to people wanting to create/use similar displays, e.g. elsewhere in the UI. This, too, required support for certain changes - such as styling/theming support, so that different types of aircraft/displays could use different symbology. We came up with a fairly lightweight framework that ended up using delegates for many/most things, i.e. inversion-of-control (IOC), so that whatever code ends up calling those APIs, could highly customize the framework without having to touch any of the underlying files necessary - artix proved this extensively by creating how own set of Airbus related MapStructure files.

By the way, given the state of affairs today, such a framework would probably be best written using Richard's Emesary Framework (see the wiki).

Finally, most Canvas related Nasal code we've seen over the years suffers from pretty much the same limitations that the original ND/PFD code suffered from, and that MapStrucuture successfully addressed - however, in the process of coming up with that framework, we also learnt a number of important lessons over time, like Gijs said already - basically, the way we have come to expose/use and support the Canvas framework, is far too low-level for the average aircraft/cockpit/avionics developer, i.e. people without a corresponding IT/CS/SE background, that is why we ended up arriving at the conclusion, that we should stop writing "frameworks" for such purposes, but instead expose the sc::Element interface at the Nasal level, analogous to sc::Widget - so that new, custom, elements could be prototyped/implemented in scripting space, and registered with sc::Group as custom elements - this would neatly address many/most long-standing issues, and would make tons of "framework code" entirely obsolete quickly, while also providing a sane migration path for people (think versioning, but also profiling/optimizing elements, by moving certain functionality back into native code).

The full background can be found here: http://wiki.flightgear.org/Canvas_Devel ... FlightGear
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: Mapstructure request for help - nasal error

Postby Octal450 » Sat Jun 15, 2019 8:35 pm

Dear Hooray,
With all due respect, we understand exactly what mapstructure is trying to do, and have found that it only makes our lives harder rather than easier in regards to complex Canvas avionics. And we are not the only people who think so -- I won't name names out of respect for them, they can come forward if they like.

Essentially, as stated now several times -- generics are not always a good thing!

As regarded to our displays... we are rewriting them in our own framework which has proven to be much better for the complex avionics of our aircraft in regards to performance, ease of implementation, and stability.

As for the input, what I'd really like to see if an analysis as of what the issue is instead of information promoting/explaining mapstructure -- I am already aware of all of that. But again, we are fixing it with our own framework.

Kind Regards,
Josh
Octal450
 
Posts: 4397
Joined: Tue Oct 06, 2015 12:51 pm

Re: Mapstructure request for help - nasal error

Postby Hooray » Sat Jun 15, 2019 9:22 pm

Dear Josh,

I said so already: as far as I can see, the issue is unrelated to the MapStructure framework, it's either because of an edge case in the route/flight manager code, or because of a recent change in that core component (MapStructure not being a core component at all).

As others said already, a bug showing up only in certain recently released binaries, is unlikely to be due to the MapStructure framework, which lives in fgdata, and probably hasn't changed much in years - so, if the fgdata commit logs don't show any changes, it's because of C++ changes in FG/SG - probably in the flight plan/routing code (route manager).

That code in particular is kinda infamous for such breakages, and because of that numerous aircraft developers have over the years opted to re-implement flight manager/route manager functionality in scripting space, to isolate/shield themselves from such breaking changes, this is a long-standing issue that's been extensively discussed on the devel list, too.

Again, without having looked at the commit logs, and given that I am de-facto inactive for the time being, my suggestion would be to simply harden the corresponding Nasal code so that it fails more gracefully, other than that, my impression is that this is due to C++ code that MapStructure/Nasal have no control over at all.

Also, I have only looked at a few postings on the first page of the topic, and been skimming over a few others, so don't consider me an authority at all. Adding the (typeof()=="vector") check is simple to do, and can be committed to anybody with fgdata commit access, there is no need to be a Nasal/MapStructure or Canvas expert to see why doing so makes sense.

Whatever you end up doing in Nasal to create Canvas avionics, it would be an excellent idea to look at other efforts and learn from them, even if you never plan on using any of that code at all, e.g. you could look at the Extra500 Avidyne Entegra R9 code, and the discussions revolving around people wanting to use that avionics stack elsehwere.

For the time being, Emesary is your best bet to create reusable components - however, if/when the sc::Element is fully exposed to scripting space, most scripting space hacks could become obsolete within a few years - the neat thing about the MapStructure approach is that it is fully encapsulated: if/when MapStructure is updated/improved or even just optimized, all front-ends (aircraft/UI dialogs) will benefit automatically.

And that really is the key point to take away from this discussion: MapStructure was never about pushing its adoption, but about making functionality reusable, so that it can be integrated in a holistic fashion, including profiling/optimizing things as needed, and extending the Canvas system accordingly.

Exposing sc::Element to scripting space was the logical conclusion that followed based on this work, which would also help getting rid of the NavDisplay code.

Speaking in general, if a simple Nasal error like the one discussed here that clearly points to the underlying C++ code, makes people go haywire and yell at the people who originally wrote the Nasal code in question, those pointing fingers at others are obviously not in a good position to judge if/what and how the orignal code came to be, let alone in a good position to "rewrite" MapStructure (unfortunately).

No offense intended or taken, but look at the tiny amount of code that MapStructure.nas is and the few drivers files it is using to pull off what it is doing - we are deluding ourselves if we think this can be easily re-created from scratch without looking at the approach taken, and the lessons learnt from these and similar efforts, including the R9 in particular.

I do realize that some key folks around here opposed to the idea of always creating "frameworks" (Richard in particular), but at the time (early 2012), Canvas was still evolving, and some of us were really concerned seeing how Nasal and Canvas were being used, fast forward 7+ years later, those concerns were unfortunately justified obviously - we never wanted MapStructure to stay "as is", but to work out a roadmap to determine how to generalize/improve the Canvas system so that these issues could be addressed over time - the conclusion was to expose sc::Element to scripting space, to establish a well-defined mechanism for people to create/update and maintain custom elements.
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: Mapstructure request for help - nasal error

Postby legoboyvdlp » Sat Jun 15, 2019 9:44 pm

Hi Hooray,
Thanks for the extensive posts. Unfortunately at this point we are not considering using Mapstructure for our displays. Thanks all the same.


As for the error here, yes indeed it is in the C++ case. I believe the error to be that procedure.route() doesn't handle the case where a transition doesn't exist gracefully, instead returning nil. I am speaking of transitions from a STAR to an ILS specifically. I am unsure why changing the runway and SID would be affected by this but yes, I think you are right that adding nil checks to the nasal code is a good solution. Regardless I would like James to look at it and see if he can see how to solve it on the core code side because that is much more future proof than simply fixing it for one instance of mapstructure and the route manager, when instead it could be fixed everywhere :)

Regards,
Jonathan
User avatar
legoboyvdlp
 
Posts: 7009
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: 2018.3.1
OS: Windows 10 HP

Re: Mapstructure request for help - nasal error

Postby Octal450 » Sat Jun 15, 2019 9:49 pm

Indeed. We have looked over all examples of mapstructure and found it to be "overcomplicated" and "overengineered". I can achieve similar results with far less lines of code.

"MapStructure was never about pushing its adoption" - but every time Canvas is mentioned, someone comes and pushes them towards it...

Lastly, the best examples of Canvas code is the Canvas Nasal API. It gives me all I need. Many other people need to do different things, and it would be harder to use those examples rather than the core of Canvas itself...

Kind Regards,
Josh
Octal450
 
Posts: 4397
Joined: Tue Oct 06, 2015 12:51 pm

PreviousNext

Return to Canvas

Who is online

Users browsing this forum: No registered users and 1 guest