Scrolling EICAS

[techguy227]

Is there a way to configure a 2D instrument panel (in this case, on a CitationX) such that CAS notifications "scroll" down when a new one pops up? For example, if anindication is currently being displayed, I'd like the text to move down to make room for the next notification when it appears. I'd like to be able to display multiple notifications (dependent on Boolean values in the property tree) without having to dedicate a spot on the display to each individual notification.

Thanks in advance!

[Thorsten]

I'm not sure of the specific case - generally glass cockpit stuff is best done in canvas these days, which means that there's some Nasal code underneath what you see, which means by changing that code, you can create any behavior you like.

Older implementation based on OSGText and moving 3d elements are considerably more unwieldy.

Having said that, the code underneath a complex display is not for the faint of heart (there's some 10.000 lines of code driving the Shuttle avionics for example) and finding the place where you need to insert your changes can take a while, so it's not something that's in any way straightforward.

[techguy227]

Thanks for the reply!

In the case of the CitationX, the EICAS appears to be XML only, and uses conditional <animation>s to replicate the glass cockpit functionality, so there's no Nasal code that appears to be relevant to this. From my understanding there might be some way to use Nasal to change the xyz offsets conditionally, which would replicate scrolling notifications. However, I'm not really sure where to start given my limited understanding of how Nasal interfaces to FG and specifically the aircraft model/cockpit interface.

[Thorsten]

It'd work more or less as you describe - you could use Nasal to set a property (that's how it'd interface in this case) and use that property as the offset in the animation. As usual, the devil is in the details - someone who is familiar with everything could probably wrap his head around it in a day and get it done. For someone starting from scratch, it's probably a hard problem.

If you want to have a go, I recomment reading up the FG wiki on the property tree and setprop/ getprop inside the Nasal section - that'd give you some of the background.

(Having said that, the display should probably be ported to canvas anyway, so the 'correct' approach would be to learn canvas and do the avionics using that kit, because it's much more flexible and better behaved with the renderer...)

[techguy227]

Thanks again for your help! I'm able to set a property with Nasal, but when I try to use that property as part of an animation, the text on the display does not move down as the property changes. Is there something additional that needs to be set up beyond this animation?

Code: Select all

      <animation>
         <type>textranslate</type>
         <object-name>LEngineFail</object-name>
         <property>controls/eicas/msg2-zoffset</property>
         <bias>0.0001</bias>
         <factor>50</factor>
         <step>.1</step>
         <axis>
             <x>0</x>
             <y>0</y>
             <z>1</z>
         </axis>
    </animation>

[Thorsten]

For some reason, animations never work on the first try for me because I always manage to get a small thing wrong - a typo, a screwup of the axes,... whatever). Either find a working one and work from there, change it bit by bit to what you need, or check everything carefully, from the spelling of the element to be animated to the location of the property in the tree, to the question whether you change the same property that controls the animation.

These things do work, but they offer plenty of room for mistakes.

[tdammers]

For some reason, animations never work on the first try for me because I always manage to get a small thing wrong - a typo, a screwup of the axes,... whatever).

This is normal, and generally the case with any kind of development work, whether you're making a flightgear aircraft, a customer management system, or high-frequency stock trading algorithm. The thing that makes this particularly troublesome in this case is that feedback cycles are so long - when I develop CSS for a website, I tend to have an automated feedback loop running that recompiles, runs all tests, and restarts everything after every file change, so I get my feedback within seconds; but with flightgear aircraft, you often have to restart flightgear entirely, and often even manipulate yourself into the situation you want to test, which can easily take several minutes. (BTW., if anyone has any tips on this front, that would be very welcome)

[Thorsten]

but with flightgear aircraft, you often have to restart flightgear entirely, and often even manipulate yourself into the situation you want to test, which can easily take several minutes

Animations/code I tend to develop added to the ufo (which starts up essentially 'immediately' when initialized on an island and only when they're ready attach them to the actual use case.

For situation testing, I've added the save/resume functionality to the Shuttle, so after it starts, I'm essentially in the situation I want to test immediately. This is some effort to code, but well worth it...

[Hooray]

Having said that, the display should probably be ported to canvas anyway, so the 'correct' approach would be to learn canvas and do the avionics using that kit, because it's much more flexible and better behaved with the renderer...

There are currently -again- plans being discussed to port the legacy HUD/2D panels code to use the Canvas system -that's the kind of work that would probably benefit from a similar set of building blocks (think animation routines to encapsulate timer/listener handling): https://sourceforge.net/p/flightgear/ma ... /36401971/

If/when this is tackled, a new set of Canvas frameworks/APIs or dedicated Canvas "elements" may emerge over time, that would also facilitate implementing similar features, without necessarily having to go through tons of custom Nasal stuff.

Conceptually, all that is needed is the equivalent of svg.nas (i.e. a Nasal space XML parser) that maps XML tags to certain Canvas elements and the corresponding Nasal callbacks.
Of course, it's not going to be as complicated as svg.nas, because all the parser has to do is understand PropertyList/XML files - as per io.nas