Glider instrumentation

[F-JYL]

Should be next step I need to finish with the fuel panels,I also started ti write unit tests ..

[Hooray]

sure no hurry, but it's a good to keep in mind that we'll want to reuse this once it's generalized - i.e. for PFDs, NDs, CDUs or other EICAS/EFIS stuff.
One important step would be to move things out of the aircraft folder to $FG_ROOT/Nasal/canvas - so that people don't need to use copy & paste to reuse things.
you can use galvedro's io.include() code to load the code then.

[galvedro]

I have documented the library in the wiki, you can find the article here:
http://wiki.flightgear.org/Soaring_instrumentation_SDK

I will add small reference documentation for every object in the library later on, but the article should have enough information by now to get you started. Let me know if there's anything unclear (or wrong!).

[Hooray]

Should be next step I need to finish with the fuel panels,I also started ti write unit tests ..

Updated the wiki accordingly, as per our PM discussion: http://wiki.flightgear.org/CanvasMFD

[Hooray]

Unfortunately, I think the big problem with multiple instances is the property references in model files – one would have to be made for each instrument, which I can see no way to change .

Perhaps model files should be treated as "templates" instead, leaving to the instancing code in the core the responsibility of binding object property hooks to their final locations in the property tree. The final location could be controlled by aircraft authors in the cockpit definition files.

I am just thinking aloud. I have only really been exposed to the instruments I tweaked when integrating the soaring toolkit, so I have not much experience on how the binding actually work.

For the sake of completeness: One thing that is done in other places in FG to solve this problem, is exposing the PropertyList-encoded data as a SGPropertNode* to an embedded Nasal script so that it can "self-modify" its tree, e.g. see the GUI XML files.

[Philosopher]

actually, Gijs also recently pointed to a wiki article about using "parameters" when modeling, basically aliased nodes pointing outside of an included file into its includer. I had not known that this existed, but it actually would solve the problem I mentioned above. Pretty neat. The problem is that it isn't used often.

[Hooray]

That's probably David Megginson's orginal "params" code, it was originally common in the 2D panel days, and didn't quite make it -adoption-wise- into many 3D panels, even though it should still work - after all, these are all "just" PropertyList files. I think part of the problem is that this is documented in a weird, non-standard, place - such as the cockpit/panel/modeling howto - IIRC, some HTML file that hasn't been updated in a decade documents this useful feature - along with some other stuff that is only known to people familiar with the SGPropertyNode class ... which is why I started moving things over to the wiki a few months ago. Not sure if params is anywhere else documented meanwhile ...

Found it: https://gitorious.org/fg/fgdata/source/ ... .html#L357
The other problem is its weird syntax (i.e. requiring relative paths), as discussed at: https://www.mail-archive.com/flightgear ... 11307.html
And even in the wiki: http://wiki.flightgear.org/Recommended_ ... _XML_Files

[Philosopher]

well found! I would like to point out that "params" (AFAICT) is just a name - it can probably be anything that doesn't conflict with relevant tags, given that its just PropertyNode path references. But OTOH it might be integrated into the C++ code that it should be ignored or something...

[Hooray]

Well, to be perfectly honest, I only found it so quickly because I knew what to look for, as I actually prototyped a canvas-based 2D instrument parser (see the wiki) based on Zakalawe's idea to re-implement the existing 2D panel code using the canvas, texture maps (analogous to our caching scheme) and Nasal for animations, to get rid of the old/unmaintained C++ code and unify our 2D rendering code:

http://sourceforge.net/p/flightgear/mai ... /29584988/

I'm even more convinced now that we should move the 2D panel and HUD rendering over to this approach, since that would get rid of all the legacy OpenGL code besides the GUI.

and that's when I noticed that some features were supported by the code that I hadn't heard of in quite a while, so had to go through all the Docs (using grep).

[oly2b]

Help with British glider gauges - has a former full size glider pilot (9 experience, silver C) I can't get my head around using Metric ASI, altimeter and varios.
I have found that the ASW20 is the only glider with British gauges. I been experimenting transplanting these into one of the many excellent gliders in FG.
Struggling to find a good 80mm size altimeter in feet. Vintage powered aircraft tend to be larger.
Back in the day I did several panels for aircraft I had access to too for FS98 and would like to try.

[D-ECHO]

Hi there!
Please try the ASK21: When selecting a british livery, you should also get british instruments