Board index FlightGear Development Tutorials and missions

A simple Extension Framework

Interactive in-sim tutorials and missions

A simple Extension Framework

Postby Hooray » Fri Apr 25, 2014 9:06 pm

Objective: allow new elements (=tags like models, presets, set, step etc) to be registered with the system directly from XML, without requiring tutorial.nas to be edited (see below)

Code: Select all
<!-- register a new element/type with the tutorial engine, purely from XML -->
<register-type>
 <name>timer</name>
 <require-arg>delay-sec</require-arg>
 <require-arg>nasal</require-arg>
 <handler>
 # this should probably use maketimer() instead
 settimer( getMyArg("delay-sec"), compile_call(getMyArg("nasal") ) );
 </handler>
</register-type>


To make this work, we only need to process all "register-type" children and register each type as a new element using its name, and mapping the value of the require-arg lookup to a corresponding getMyArg() callback and then compile/bind/call() the resulting callback: http://plausible.org/nasal/lib.html

The same thing could be done for listeners:


Code: Select all
<!-- register a new element/type with the tutorial engine, purely from XML -->
<register-type>
 <name>listener</name>
 <require-arg>property</require-arg>
 <require-arg>nasal</require-arg>
 <handler>
 setlistener( getMyArg("property"), compile_call(getMyArg("nasal") ) );
 </handler>
</register-type>


This would all be part of the "prologue" of a tutorial, i.e. during initialization - and it would make new "elements" available to the system, without the Nasal code having to be edited.
Once these elements are registered, they can be used elsewhere, e.g. in the form of:

Code: Select all
<timer>
 <name>demo</demo>
 <delay-sec>1.5</delay-sec>
 <nasal> print("Hello World from an XML-based timer!"); </nasal>
</timer>


<listener>
 <name>demo2</demo>
 <!-- we could also support multiple properties per nasal block here -->
 <property>/autopilot/locks/altitude</property>
 <nasal> print("Please dont use the autopilot or route manager!!"); </nasal>
</listener>


As can be seen, just supporting custom handlers to be registered would allow all sorts of interesting extensions, without leaving XML space necessarily, which is good, because it allows us to reuse tutorial building blocks via include/params.

Using the same mechanism, we could easily provide elements for creating AI traffic, but also showing GUI dialogs (NPC interaction or mission briefings) or running fgcommands directly.
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: A simple Extension Framework

Postby Hooray » Sat Apr 26, 2014 4:53 pm

Okay,I have a basic version of this working now here, it's all based on the code that you have provided so far. I can basically extend the missions system via XML by adding a handful of tags that allow new tags and event handlers to be registered, where the implementation always requires an embedded Nasal section, and custom arguments are mapped to a hash lookup that is bound to the lexical scope of the callback that is executed.

This allows a fairly simple form of "coding", while I do not like XML-based programming, I think this is one of those cases where we may actually benefit from having an expressive XML environment, because we basically want to come up with generic building blocks for the most common needs, to reduce the amount of specialized Nasal code, but also to enable others to easily reuse stuff. The main advantage here is that existing building blocks can be reused using include/params. And once recursion is fully supported, people could basically add a handful of building blocks like listeners, timers and fgcommands and then use those in a nested fashion.

I am hoping that we can identify commonly required building blocks, e.g. by looking at the precision landing mission, and re-implement those huge Nasal sections using a handful of XML primitives.

I think this is a worthwhile thing to aim for, because once we have sufficient building blocks available in XML, we could even add a simple Canvas-based mission editor on top of this, because everything would be structured XML, which is easier to deal with than supporting some "free-form" programming language like Nasal.

The promising thing here is that even just supporting a treeview GUI widget in Canvas would allow us to use that to visually design missions with branching, here's -for reference- the FSX mission editor that is also built on top of XML building blocks for pretty much the same reasons:

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


Return to Tutorials and missions

Who is online

Users browsing this forum: No registered users and 2 guests