Boris Koenig wrote:

So I hope to know now for example that nasal's lack of threadsafety
is unlikely to become an issue, as not nasal itself would handle things like animations but rather a specific subsystem - that nasal would only
access to provide the necessary parameters - correct ?

Hmm, well yeah. Sort off ...
I'm not quite sure why you still want code to be thread safe. I've got the feeling we're not exactly talking about the same issue.

What exactly are you trying to do, create a separate program that runs portions of FlightGear in a (sub)window, or do you want to use FlightGear (the user would indeed start fgfs then) and add a menu structure that guides the user while flying?

The first one would be really hard to implement I'm afraid. The latter doesn't require thread safety IMHO.

But to get back to that, Nasal doesn't run all the time. It gets triggered by an event, does what is required and then waits for the next trigger. A trigger could be a timer, and the code could be setting a property that triggers the animation code to change something.

All subsystems are almost self containing. Most of the time they only read the values of some properties, and sometimes they alter other properties. This is FlightGear's way of communicating between subsystems.

As I don't know -yet- how to access FlightGear's subsystems from a
language like nasal, I am currently definitely likely to indeed
-reinvent the wheel- in order to resemble the beviours and functionality that I need. I do want to prevent that as well !

Most of the time you really don't want to access the subsystems, but instead you tell the subsystems what should happen. In most cases that's setting or altering a small set of properties(*) and the particular subsystem acts upon the changed properties.

For example,

If you want to animate the gear of an aircraft you would have to write an XML based configuration file that performs an animation type on the 3d model object name, using the input of a property:

From FlightGear/data/Aircraft/c310/Models/c310-dpm.xml


Here you tell the animation subsystem to rotate the 3d object named "NoseWheel" based on the value of the property located at gear/gear[0]/position-norm

This property is currently altered by the FDM (Yasim, JSBSim or UIUC/LaRCsim), but for the AIModels it could be altered bu a Nasal script like this:

based on the animation code of the bo105 located at FlightGear/data/Aircraft/bo105/Models/bo105.nas

# gear
pos = props.globals.getNode("gear/gear[0]/position-norm", 1);
swingTime = 2.5;

target = 1;
toggleGear = func {
        val = gear.getValue();
        time = abs(val - target) * swingTime;
        interpolate(gear, target, time);
        target = !target;

You see, there are two configuration files (one for each subsystem) that work together using the property tree.

That's usually the problem if you don't have the necessary information available.

There is some information at: FlightGear source in FlightGear/docs-mini The base package in FlightGear/data/Docs The webpage in: SimGear: FlightGear:

Nasal can also read and modify properties but it can also be incorporated into the menu system.

There is a (comprehensive) example available in FlightGear/data/gui/dialogs/autopilot.xml

Would you mind letting me know, which source files are responsible
for the menu-access (like adding/removing items) ?
So that I can look up the exact usage ?

That all done using XML (look in the FlightGear/data/gui subdirectory for the complete configuration of the menu layout).

Because my current set of goals would then be to really drop the
C++/PLIB idea and try to give nasal a go:

This combination would allow one to design a menu system that:

1. pauses displays a dialog and pauses the simulator.
2. waits for the user to confirm the dialog.
3. alters one or more properties (change view for example)
4. starts the simulator again.
5. waits for a certain property to change
6. goto 1.

...for the nasal attempt to work, I would like to start by creating a simple script file which, when loaded by FlightGear, would disable
subsystems like terragen (that aren't necessary at the current
stage for FliteTutor) and continue adding custom menus to the
FlightGear menu, in connection with the necessary hooks to be called when selected.

TerraGen is actually a separate program to build the scenery data. I guess you just want to disable the out-of-the-window view. This is handled by setting "/sim/rendering/draw-otw" to false.

I think this is already most of what you are looking for.

You are probably right, but I would still need to know, what specific subsystem/properties to access (and what parameters to provide) in order for example to be able to do things such as:

- load/display an instrument at a certain screen position

This is done by creating a new panel configuration file (see FlightGear/data/Docs/README.minipanel)

    - alter that instrument's properties
    - set its properties in a way that allows animation

This is done by changing the value of the property to which the instrument is tied to. There is no fixed set of properties, just a set that is available to everybody. But if you want something special, then you could easily tie the instrument to some properties that are located in /flitetutor and alter those using Nasal.


Flightgear-devel mailing list

Reply via email to