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 Hooray » Sun Jun 16, 2019 6:51 am

It seems you are missing the point, using Nasal code to this degree to implement avionics is rather unfortunate - in a perfect world, such avionics would only be set up from Nasal space, but all the runtime overhead would be handled by native code - so far, we're still making heavy use of timers and listeners, which means that the display code inevitably ends up in scripting space sooner or later, where all/most heuristics are handled.

We realized that this would be a huge issue early on, doing hundreds of getprop() calls without caching them via memoization, would add up unnecessarily. This is how MapStructure came to be, we wanted to create a framework where all the nitty gritty details were encapsulated, so that if/when things turn out to be too slow, we can instrument the code and optimize it accordingly (e.g. by re-implementing portions of it in C++ space).

That way, all front-ends (cockpits/UI dialogs) would automatically benefit from such optimizations.

A number of other teams developing Canvas based avionics ended up arriving at the same conclusion, e.g. look up the comments by the Extra500 team - they stated quite clearly that there were hitting performance issues, so they ended up looking at how MapStructure worked under the hood and re-implemented portions of it in their own code.

Realistically, MapStructure would not be needed at all, if the sc::Element was fully exposed to scripting space, so that new elements can be registered that way - equally, handling display and element animations/updates via timers and listeners is awkward and not a good way to update OSG/OpenGL state.

Also, the Canvas UI system does have styling support via properties (analogous to how Effects support inheritance) - basically, exposing these two, would mean that we'd solve a ton of problems automatically, including even support for multi-instance setups using Canvas avionics (think LinuxTag/FSWeekend-style setups with master/slave configurations, or multiplayer/dual control).

You could also take a look at the shuttle code, it's not using any MapStructure stuff at all - but it's using memoization, via some of Richard's work (property manager).

The thing is, you can argue all day long that generic code is inferior over what you may come up with - but that's not the point at all, the MapStructure stuff was developed to support an arbitrary number of independent "mapping/charting" displays that may be driven by different "drivers" - thus, this was also intended to be a stress-test for the Canvas system, at a time when many of us were still tinkering with Nasal/Canvas for the first time, we were hoping to help shape the API, and we didn't want people to use copy/paste to do their avionics coding, let alone the low-level Canvas API that you are referring to above.

Again, look at Thorsten's shuttle work, even there he ended up adopting higher level management helpers to optimize the system. That's a piece of work, where you have the need to fetch/update hundreds of properties and probably half a dozen of displays shown concurrently, if you screw up the coding there, it will show quickly.

This is why, MapStructure was developed out-of-aircraft, i.e. using just a set of UI dialogs, and drivers to hook up the display to the driver properties (aircraft specific), and that is also why it can handle/show different displays without using any copy/paste.

Conventionally, these sorts of things would have been implemented by copying/pasting the corresponding code and updating it manually, the MapStructure/MVC approach means that aircraft using MapStructure, contribute to the same system.

http://wiki.flightgear.org/Howto:Protot ... play_Style
Image

@lego: excellent job troubleshooting this, and thanks for explaining to others where the real problem lies, instead of pointing at something entirely unrelated like the MapStructure code. 8)
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: Mapstructure request for help - nasal error

Postby Octal450 » Sun Jun 16, 2019 7:19 am

Dear Hooray,
I've done my own implementation now that I am testing which is quite efficient and simple to manage hundreds of properties per refresh per display. So I do have at least some vague idea of what I am doing here.

Ultimately I decided to move away from MapStructure for a few main reasons:
1) Maintainers aren't around often (clearly, took 2 months to get any response at all) regardless of severity
2) Buggy -- the ND behaves unpredictably at times. Even not my Airbus version (which is based from artix's Airbus version from his repo, not the generic Airbus one which is even WORSE), your vanilla 777 or generic Boeing ones too
3) Overcomplex - even the simplest things are too complex than needed for some reason

I don't appreciate you calling my displays "unfortunate". You have absolutely no idea whatsoever about what I am doing. They happen to work extremely well, and my private dev version is even more performance friendly.

Sorry Hooray, you didn't understand a single thing I said for some reason - fine, I don't really care. Lets not waste any more topic here discussing it. :mrgreen:
So, now that the emotions are out of the way, lets focus on only solving this now please. Obviously you like MapStructure, and I don't. So lets agree to disagree.

Kind Regards,
Josh

PS: There are multiple errors here happening, they are related to mapstructure hence the titles.
Skillset: JSBsim Flight Dynamics, Systems, Canvas, Autoflight/Control, Instrumentation, Animations
Aircraft: A320-family, MD-11, MD-80, Contribs in a few others

Octal450's GitHub|Launcher Catalog
|Airbus Dev Discord|Octal450 Hangar Dev Discord
User avatar
Octal450
 
Posts: 5583
Joined: Tue Oct 06, 2015 1:51 pm
Location: Huntsville, AL
Callsign: WTF411
Version: next
OS: Windows 11

Re: Mapstructure request for help - nasal error

Postby legoboyvdlp » Tue Jun 18, 2019 6:00 pm

I'm not quite sure where or why but the Mapstructure model not found error seemingly has been fixed since 2019.1.1 --> at least its not showing up on any of two testers. It may well be related to James' changes recently - or maybe just coincidence. If it starts again on Pavlin's laptop then it has not been corrected - until then I'll assume it has been.

However, when using Navigraph it does remain broken reproducably when following these steps:

viewtopic.php?f=71&t=35930&start=15#p349732

I can reproduce this at various airports. It doesn't depend on Navigraph per se - it should occur at any airport having both a STAR and IAP defined, even if not Navigraph?

I'm at this time tracing the error in wp.path() - hopefully will find why it returns a zero-length vector.
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: Mapstructure request for help - nasal error

Postby legoboyvdlp » Tue Jun 18, 2019 8:25 pm

@Hooray, @Philosopher, @anyone
I have corrected the error by checking the vector's size before calling any function on it.


A ATC-vector waypoint or discontinuity waypoint has no coordinates and should not be drawn. Therefore the C++ code returns a vector zero length. Thus, calling path() returns a zero-length vector. Does anyone know how to tell Mapstructure not to draw a "vectors" waypoint? Would returning zero in the constructor WPT_model.new() suffice?

Image

I got this - it fails "nicely", not breaking the display when it gets a vector or discontinuity -- however I need to tell it not to draw that waypoint.

It's safe enough to simply draw nothing with discontinuities and vector waypoints - that's how Boeings and Airbuses behave.


I also need to remove the magenta line between vector / discontinuities and the next waypoint. Not so sure how to.


My new code in wpt.lcontroller:

Code: Select all
if (idx) {
            wpPathVec = wp.path();
            if (size(wpPathVec) > 0) {
                var n = wpPathVec[-1];
            } else {
                print("Error - skipping waypoint index " ~ idx ~ " since wp.path() returns nil");
            }
        } else {
            wpPathVec = fp.getWP(wp2idx).path();
            if (size(wpPathVec) > 0) {
                var n = wpPathVec[0];
            } else {
                print("Error - skipping waypoint index " ~ wp2idx ~ " since wp.path() returns nil");
            }
        }
      
        if (n != nil) {
            (m.lat,m.lon) = (n.lat,n.lon);
        }



Presently I also get a warning: "no suitable getpos() found!". Seemingly that is because it has no coordinates.
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: Mapstructure request for help - nasal error

Postby Octal450 » Tue Jun 18, 2019 10:00 pm

Very good work, thank you lego for all your efforts.

Kind Regards,
Josh
Skillset: JSBsim Flight Dynamics, Systems, Canvas, Autoflight/Control, Instrumentation, Animations
Aircraft: A320-family, MD-11, MD-80, Contribs in a few others

Octal450's GitHub|Launcher Catalog
|Airbus Dev Discord|Octal450 Hangar Dev Discord
User avatar
Octal450
 
Posts: 5583
Joined: Tue Oct 06, 2015 1:51 pm
Location: Huntsville, AL
Callsign: WTF411
Version: next
OS: Windows 11

Re: Mapstructure request for help - nasal error

Postby Isaak » Tue Jun 18, 2019 10:21 pm

Wow this is finally getting somewhere, thanks so much, Jonathan!
Want to support medical research with your pc? Start Folding at Home and join team FlightGear!
Isaak
 
Posts: 768
Joined: Sat Jun 04, 2011 3:52 pm
Location: Hamme, Belgium
Pronouns: he, him
Callsign: OO-ISA
Version: next
OS: Windows 10

Re: Mapstructure request for help - nasal error

Postby Richard » Wed Jun 19, 2019 12:21 pm

Octal450 wrote in Sun Jun 16, 2019 7:19 am:I don't appreciate you calling my displays "unfortunate".


I rather suspect that unfortunate in this sense refers to the amount of code that will have to be written to get functionality that is already available via the map structure; however equally I do understand that it is quite hard to follow what is going on inside map structure and that it doesn't seem to be too difficult to rewrite it all from scratch but almost certainly there will be the same set of problems to solve and the resulting code won't be that different.

When Hooray said that I'm against frameworks that's not quite accurate; as what I usually say is that designing a generic framework without a specific purpose can lead to a mess; but that's not true of the Map Structure - this is a framework that grew out of specialized code and it is will structured; but as always aircraft developers should be free to use whatever suits their purpose the best.

It might also be useful if Stuart were able to advise on this because of the considerable amount of work he did on the FG1000.
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Mapstructure request for help - nasal error

Postby legoboyvdlp » Wed Jun 19, 2019 1:39 pm

Image

I've got all the other waypoints rendering properly now - however I still need help to disable rendering of this vector waypoint.

If the result of wp.path() is nil, I have this code:

Code: Select all
if (n == nil) {
         m.isVector = 1;
      } else {
         m.name = wp.wp_name;
         var alt = wp.alt_cstr;
         if (alt != 0)
            m.name ~= "\n"~alt;
         
         (m.lat,m.lon) = (n.lat,n.lon);
      }


Then, in the symbol file I check me.model.isVector and only run init() and draw() if it has valid coordinates (ie is not a vector). Unfortunately it still renders this waypoint -- even though I specifically checked that init() and draw() are not being run. Maybe I need to pass it back to the DotSym layer and disable that as well, or....?
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: Mapstructure request for help - nasal error

Postby Hooray » Sun Jun 23, 2019 10:20 am

The heuristics are all handled by the model, so that is here you should run your checks.
searchCmd is the search/update function, you could check some flag there to skip/ignore certain elements.
searchCmd should return a vector of "drawables".

the leg/line drawing portion is handled separately.
Basically, there is one layer drawing waypoints, and one drawing legs between waypoints.

To be perfectly honest though, we didn't write any of that code - it was merely harvested (taken) from existing code, and we added the corresponding wrappers to use this via MapStructure. So, it's rather likely that this code was taken "as is" from Gijs' original work, or some other ND instrument.

We really only came up with the structure, for the reasons that Richard mentioned - i.e. regardless of the instrument/avionics you are developing, there is going to be a need for recurring "elements", "functions" and usage protocols/patterns, think instancing, caching, efficient updates, drawing etc

Also, I am pretty sure that we didn't have access to any NaviGraph data at the time, because that would have required a subscription, that certainly applies to Philosopher and myself - not sure about Gijs, but I believe most of the people who came up with those WPT/RTE drawing heuristics, never used that data - I even believe, we lacked support for NaviGraph at the time - which is to say, that some issues are to be expected, because new data/formats are being thrown at legacy code that was written around 2012.

I don't remember all the details, since it's been so long ago - but we did actually document the whole system fairly well, including a list of available, I would expect some kind of WPT and RTE layers, along with files handling the MODEL/VIEW/CONTROLLER portion - i.e. lcontroller, symbol and controller files.

http://wiki.flightgear.org/Canvas_MapStructure_Layers

Thus, regarding your other question, you can simply remove waypoints from the vector that you don't want to be drawn, you can use your existing heuristics for that - or simply update searchCmd() so that it skips those waypoints entirely (which I would consider cleaner).

Equally, the RTE handling logics will need to be updated to skip the leg portion

You can find the RTE.lcontroller file here: https://sourceforge.net/p/flightgear/fg ... controller
The searchCmd() function is what you want to look at for all the flight plan handling
At the bottom of this function, you will see an append() call that builds the vector for the leg drawing routine.
This is where you can add (prepend) your heuristics to exclude certain legs

Equally, in WPT.lcontroller you can refer to the searchCmd() function there: https://sourceforge.net/p/flightgear/fg ... controller

You will see two nested for-loops that traverse each flight plan, and each portion of the flight plan.
The inner loop is the one where you want to add your heuristics to skip those waypoints.
For testing purposes, you can add your heuristics and add some print/printlog statements, to see when your heuristics are triggered, once they work reliably, you can simply skip those waypoints.

For the sake of simplicity, you can just run your heuristics and then add "continue" after the if expression, e.g.:
Code: Select all
if (heuristics) continue;
# other update/append the vector inside searchcmd


This will skip the append() expression, so that the waypoint/route leg won't be added, and consequently also shouldn't be drawn

Feel free to update the wiki as needed to help clarify these things !

Also, @Richard/Gijs: since legoboyvdlp is clearly making enormous progress here, would you please help him getting his MapStructure layer updates committed, or even consider setting him up with fgdata commit access (if needed) so that he can commit his changes - based on the postings and questions I've seen, he's getting a really good grasp of how the system works, and he's also been in touch via PM to ask for clarification, so I think this would make a lot of sense to ensure that the system continues to receive updates.
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: Mapstructure request for help - nasal error

Postby legoboyvdlp » Sun Jun 23, 2019 2:45 pm

Thank you very much! I will try and implement this today.

Regarding navigraph I think James has identified this as a C++ error to do with missing transitions etc so that's fine.
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: Mapstructure request for help - nasal error

Postby stuart » Sun Jun 23, 2019 9:17 pm

Hi Jonathan, Josh,

Octal450 wrote in Sat Jun 15, 2019 10: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.


I'm coming to this discussion rather late, for which apologies. Too many other things going on!

I've got a lot of experience using MapStructure (from developing the FG1000). I agree that it appears overengineered and overcomplicated, and there is certainly a steep learning curve if you don't have a background in software engineering. In particular, understanding the MVC (Model, View, Controller) approach is key. However, it does provide a very good framework for what you are trying to achieve.

I would strongly encourage you to take another look, and not to under-estimate the amount of time you will have to spend re-inventing the wheel if you start from scratch. It probably won't be obvious to start with, but it's highly likely you'll end up with something that's far less maintainable.

I'm also happy to answer any questions, and make changes if there are things that are missing. It's entirely possible that any enhancements you require would also benefit the FG1000, and having another use would provide me with extra incentive to make the changes :).

Best regards,

Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Mapstructure request for help - nasal error

Postby Octal450 » Sun Jun 23, 2019 11:21 pm

Dear stuart, I am glad that it worked well for you -- however ----------------------------------------------------- as stated, we have closely evaluated the situation and found that we can achieve the same with much less lines of code, with much better system performance. Therefore we have reached our decision.

Please do not act like we are the idiots! We did not just blindly make a decision without first fully evaluating it. This is the second or third time in this thread alone that someone has said "you don't like it because you don't understand, try to, and then try mapstructure again". Hence why again my frustration -- the goal is trying to fix a problem, and here we are more promoting it...

Kind Regards,
Josh
Skillset: JSBsim Flight Dynamics, Systems, Canvas, Autoflight/Control, Instrumentation, Animations
Aircraft: A320-family, MD-11, MD-80, Contribs in a few others

Octal450's GitHub|Launcher Catalog
|Airbus Dev Discord|Octal450 Hangar Dev Discord
User avatar
Octal450
 
Posts: 5583
Joined: Tue Oct 06, 2015 1:51 pm
Location: Huntsville, AL
Callsign: WTF411
Version: next
OS: Windows 11

Re: Mapstructure request for help - nasal error

Postby stuart » Mon Jun 24, 2019 5:11 pm

Hi Josh,

My sincere apologies if my post came across as suggesting you were idiots. Certainly not my intention.

Best regards,

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Mapstructure request for help - nasal error

Postby Octal450 » Mon Jun 24, 2019 5:39 pm

Accepted. :mrgreen:

Thanks to Jonathan Redpath and James Turner, we have much fixes. So the issue should be resolved very soon! :D

KIND REGARDS,
Josh
Skillset: JSBsim Flight Dynamics, Systems, Canvas, Autoflight/Control, Instrumentation, Animations
Aircraft: A320-family, MD-11, MD-80, Contribs in a few others

Octal450's GitHub|Launcher Catalog
|Airbus Dev Discord|Octal450 Hangar Dev Discord
User avatar
Octal450
 
Posts: 5583
Joined: Tue Oct 06, 2015 1:51 pm
Location: Huntsville, AL
Callsign: WTF411
Version: next
OS: Windows 11

Re: Mapstructure request for help - nasal error

Postby legoboyvdlp » Mon Jun 24, 2019 6:12 pm

Hi Stuart,
Thanks for the response ;)
With regards to Mapstructure I do agree with you that it's a good concept, however as we are not making a framework to make a nav display but a nav display I think Josh will be able to do it a bit more simply :)

Anyway - with regards to the error here would it be fine if I send a patch via you? I hope to be able to fix it tonight although will be away for a week starting tomorrow so it will be a bit later if I don't manage it tonight.
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

PreviousNext

Return to Canvas

Who is online

Users browsing this forum: No registered users and 3 guests