Howto talk:Development of the CDU

From FlightGear wiki
Revision as of 18:00, 3 December 2010 by Hooray (talk | contribs) (XML conditions - including other XML files)
Jump to navigation Jump to search

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)

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)