Howto talk:Development of the CDU: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 88: Line 88:


--[[User:Hcc23|Hcc23]] 21:03, 3 December 2010 (UTC)
--[[User:Hcc23|Hcc23]] 21:03, 3 December 2010 (UTC)
Most XML files (certainly the PropertyList files) in FlightGear will at some point be read into the property tree, where XML tags become properties. Depending on the subsystem, there is support for "live" properties, so that setting or overwriting a value in the property tree also affects the underlying system. Other properties are polled at framerate in the C++ code, so that modifying them also causes updates.
Increasingly, properties are bound to listeners in the C++ code - so that systems can be updated like this, just by setting a property. You can see this in various parts: README.osgtext, for example, mentions support for properties in the form of "text-value" and "number-value" types, where the the value is not literal/hard coded in the XML file, but instead dynamically read from a property in the global property tree. This in itself, would make it possible to define a screen area and then use Nasal and the property tree to change the contents of the "LCD screen". So if you want to update some text on the "screen", this only means setting a property in the property tree by using Nasal (setprop). This way it would for example be possible to define a screen region with 14 lines by using 14 different INPUT properties. You could use a Nasal helper routine to ensure that there are not more than 24 characters written to each property (line), so that you simulate 14 lines X 24 columns. Due to the property tree and Nasal, there are lots of cases in FlightGear where Nasal sort of implicitly follows the MVC pattern already. So the representation and implementation of the screen logics could very well be separated like this. This would also mean that the XML file implementing the screen region, would not need to know about the high level stuff (i.e. CDU implementation), it would just be a "text area" that is populated with text from 14 different properties.
Obviously, not everything can currently be implemented directly in Nasal space. But there are usually feasible workarounds available.
For example, as far as I know, there is currently no support for also changing other font settings (font, font size, color, reverse) dynamically. But these would be fairly simple C++ modifications. The GUI system implements many of these features already.
The general idea really is that the property tree is the mechanism to share data and communicate with other parts of FlightGear. If you really wanted to, you could even dynamically add 3D models by using Nasal.
--[[User:Hooray|Hooray]] 22:29, 3 December 2010 (UTC)


= XML conditions remark =
= XML conditions remark =

Revision as of 22:29, 3 December 2010

Nasal in XML files (command bindings)

Note that Nasal scripts embedded in XML should be wrapped in <![CDATA[ ... ]]> markup:

 <![CDATA[ print("Foo");  ]]>

--Hooray 21:42, 2 December 2010 (UTC)

Thanks for that advice. But shouldn't there be a > somewhere? Could you please correct this example (in a new version below)?

<animation> 
	<type>pick</type>
	<object-name>Btn.zero</object-name>
	<action>
		<button>0</button>
		<repeatable>false</repeatable>  
		<binding>
			<command>nasal</command>
			<script><![CDATA[
                         setprop("/instrumentation/cdu/input",getprop("/instrumentation/cdu/input")~'0');
                       ]]></script>
		</binding>
	</action>
</animation>

--Hcc23 22:16, 2 December 2010 (UTC)

Loading external Nasal files from XML files

There is code to do this in $FG_ROOT/Nasal/io.nas - namely the function "load_nasal(filename, namespace)". io.nas contains some comments. Basically, this allows you to reference/load and run separate Nasal modules, without having to embed all of the code directly in the XML markup. So it's a good practice and makes things easier:

 <binding>
 <command>nasal<command>
 <script><![CDATA[
    io.load_nasal("lsk.nas","lsk");
 ]]></script>
 </binding>

--Hooray 22:31, 2 December 2010 (UTC)

Implementing LSK logics

"The most cumbersome buttons are the line select keys. As their function depends on the current state of the CDU, 
 the corresponding XML requires some conditional checks."

I think, we actually talked about this previously on the forums. Instead of using lots of nested XML logics to model a CDU (or any complex instrument), it is actually better to just use the property tree for communicating "events" (e.g. button presses). This would then make it possible for a Nasal script to handle ALL logics (using a registered listener), so that a FSM (finite state machine) can be implemented in Nasal space, this is more flexible than a purely XML-based approach, and could also be more easily reused by other aircraft and developers. My personal suggestion would be to refrain from modeling advanced logics in XML space, while it is certainly possible to do so to a certain degree, the corresponding building blocks are relicts from an era where Nasal scripting was not yet available.--Hooray 22:31, 2 December 2010 (UTC)

Implementing a finite state machine in Nasal

I think, the right thing to do would be creating a new "fsm.nas" module, so that it can be used by aircraft developers to create their own state machines based on a generic fsm module. This would make it possible to implement all sorts of advanced instruments without using the bloated XML syntax for this.

--Hooray 22:53, 2 December 2010 (UTC)

Generality of the CDU

CDUs differ from aircraft type to aircraft type. Gijs started the CDU for a Boeing 747-400 based upon the documentation he had for that airplane. I personally have access to a B777 FMS PILOT'S GUIDE which I will use to guide me in my decisions.... Hopefully people can live with a "mixed up" CDU for the moment (as compared to no CDU) and interested parties can separate the internal workings later...

--Hcc23 22:32, 2 December 2010 (UTC)

LCD screen abstraction

My suggestion would be to introduce a new Nasal module here, where people can use a wrapper to create a new alphanumerical screen area and map it to the corresponding osgText animations:

var myLCD = lcd.new(lines:14,columns:24);

Next, one could add methods to easily add text to specific lines or columns of this virtual LCD screen, too:

myLCD.add(line:1, text: "INIT/REF INDEX");
myLCD.add(line:2, text: "< IDENT");
myLCD.add(line:3, text: "< POS");
myLCD.add(line:4, text: "< PERF");
myLCD.add(line:5, text: "< TAKEOFF");
myLCD.add(line:6, text: "< APPROACH");

As a third (and optional) argument, one could add support for formatting/styling attributes to change font, font size, font color etc. Once we have such an LCD wrapper, providing a CDU specific wrapper on top of this that handles the LCD transparently would be easy.

The CDU wrapper would then work in terms of "CDU pages" and use the LCD backend internally which addresses the virtual LCD by setting properties, which converts everything to the required osgText animations, so you end up with three wrappers:

  • osgText (lowest)
  • LCD screen
  • CDU (high level)

--Hooray 23:17, 2 December 2010 (UTC)


Using Nasal is exactly what I planned. However, I haven't yet figured out how to use Nasal to achieve the same effects as with XML. THe README.osgtext is very helpfull, but isn't this stuff that lives in the XML scope? How would I achieve a similar effect using nasal? Any hints for sourcecode where nasal is used to update some text on a screen (I guess in some instrument), based on a property from the property tree? (e.g. like a nasal enabled digital altimeter)?

Any hints are very welcome...

--Hcc23 21:03, 3 December 2010 (UTC)

Most XML files (certainly the PropertyList files) in FlightGear will at some point be read into the property tree, where XML tags become properties. Depending on the subsystem, there is support for "live" properties, so that setting or overwriting a value in the property tree also affects the underlying system. Other properties are polled at framerate in the C++ code, so that modifying them also causes updates. Increasingly, properties are bound to listeners in the C++ code - so that systems can be updated like this, just by setting a property. You can see this in various parts: README.osgtext, for example, mentions support for properties in the form of "text-value" and "number-value" types, where the the value is not literal/hard coded in the XML file, but instead dynamically read from a property in the global property tree. This in itself, would make it possible to define a screen area and then use Nasal and the property tree to change the contents of the "LCD screen". So if you want to update some text on the "screen", this only means setting a property in the property tree by using Nasal (setprop). This way it would for example be possible to define a screen region with 14 lines by using 14 different INPUT properties. You could use a Nasal helper routine to ensure that there are not more than 24 characters written to each property (line), so that you simulate 14 lines X 24 columns. Due to the property tree and Nasal, there are lots of cases in FlightGear where Nasal sort of implicitly follows the MVC pattern already. So the representation and implementation of the screen logics could very well be separated like this. This would also mean that the XML file implementing the screen region, would not need to know about the high level stuff (i.e. CDU implementation), it would just be a "text area" that is populated with text from 14 different properties. Obviously, not everything can currently be implemented directly in Nasal space. But there are usually feasible workarounds available. For example, as far as I know, there is currently no support for also changing other font settings (font, font size, color, reverse) dynamically. But these would be fairly simple C++ modifications. The GUI system implements many of these features already. The general idea really is that the property tree is the mechanism to share data and communicate with other parts of FlightGear. If you really wanted to, you could even dynamically add 3D models by using Nasal.

--Hooray 22:29, 3 December 2010 (UTC)

XML conditions remark

(Hcc23 wonders if the condition on the page could be put somewhere else in order to keep things
slightly more organized (by pages that is, and not by buttons...)) CDU Pages 

If you really want to pursue this XML-based approach (instead of modeling a FSM in Nasal space), you should know that all PropertyList XML Files support "include" directives that can be specified for each tag in the form an attribute (include="filename.xml"), to include another PropertyList-encoded XML file.

--Hooray 18:00, 3 December 2010 (UTC)