...if you need pen-pals subscribe to a mailing list ;-)
Erik Hofman wrote:
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.
Probably you are right, I was just referring to this as an example because when I first read about nasal a couple of days ago I was under the impression that you would directly use nasal to *animate* an instrument.So, doing something like that in parallel with other actions, like processing a message loop to wait for user events might have been a problem.
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?
Actually, neither the former, nor the latter:
What I want to do is actually be able to use FlightGear -and its subsystems- as a backend for a basic presentation system for (aviation related) - CBT / learning purposes. Hence, I would need to have pretty much full access to most of the subsystems - either using an API or the integrated scripting language nasal.
It wouldn't matter if FlightGear needs to be running directly or if only subsystems get called.
I want to be able to make use of a subsystem - either by calling it directly or using means like those that are provided via nasal.
As the FliteTutor webpages don't seem to be precise enough on that yet, I am going to give a more in depth example, I would definitely appreciate getting your views about that.
Basically, the following would be an example scenario for a beta - FliteTutor learning unit using nasal:
1) Run FlightGear - optionally providing a nasal script file as
parameter - OR load that script file from within fgfs as soon
as FlightGear has booted and is running. ==> This nasal file should then perform the following
actions: a) disable (or not even load during startup) all
those FlightGear sub-systems that aren't required
by that specific FliteTutor module - i.e. the
rendering of the outside view, and disable the
things like the panel view.
What we would then basically have is an "empty"
FlightGear window (so, not even a panel !) b) draw some basic GUI components such as
"previous/back"-buttons in the empty client area at
certain coordinates - these controls would serve the
purpose to allow basic CBT-like navigation within
FlightGear. Also it might be - depending on the lesson-
necessary to draw other GUI elements such as checkboxes
or dropdown menus at certain coordinates.
(Originally, I had hoped to be able to use the PLIB GUI
functions for that purpose, but if these possibilites
also exist through nasal bindings, all the better !)
c) register specific events for these controls to be triggered for certain actions (like "button [next] got clicked" => "do: next page")
d) load a specified gauge/instrument from the FlightGear base directory (e.g. a standard VOR) e) display that gauge/instrument at a a certain position on the screen, optionally also set custom dimensions (as it would be useful to have a really large view of an instrument in order to illustrate its workings)
f) display certain text (explanations) at a certain
position - probably either close to the instrument, in
a specific "textbody" (GUI-element) or even rendered as
a separate layer above the displayed instrument in order
to explain the instrument itself. g) register a message handler loop, that waits for
specific events to be triggered - e.g. to allow
monitoring if a user follows the CBT instruction to
set the VOR OBS to radial 290 or not - based upon
this validation the script could give a warning or
even hint. => At this point we would be able to dynamically
illustrate the workings of a VOR indicator by
either automatically animating the instrument
and displaying explanations OR by displaying
instructions for the user to use/interpret the
instrument and actually have a readout of user
actions. h) depending on the triggered events, it should be
possible to go to the next section of a "lesson"
or replay a certain animation etc.if you want me to, I can go into even further detail :-)
Maybe it is now easier for you to tell me, IF the desired functionality could be (easily) achieved using primarily nasal scripting and some smaller FlightGear source code modifications or whether it would be more feasible for me to really start writing directly into the FlightGear source. Even though I am more and more about to like the Nasal way, which seems to be pretty elegant by the way.
But as I mentioned previously: if I am shown HOW TO add Nasal bindings to FlightGear I wouldn't mind firing up my IDE and do some C++ stuff myself.
To go add some more detail: what I ultimately would like to be able to do with FliteTutor is to make FliteTutor a module for FlightGear that can create and play learning units within FlightGear.
So, not FliteTutor itself is supposed to contain the actual contents for FlightGear, but rather dynamically loaded learning units will serve that purpose.
So, these units could either be created based on a set of nasal-macros that are approriately adapted for each new unit - OR (more likely right now) it could rely on an individual (xml-based) file format that describes things like:
[GENERAL]
- position and alignment of GUI elements for
navigational purposes
- title of unit
- introductory description (outline)
- pages that exist for that unitSo, each unit/lesson would then consist of different "pages" - whereas each page represents an empty FlightGear client area that is dynamically populated with those elements that are necessary for that particular unit - e.g.: the CBT navigation controls. The remainder of the screen could then be used for illustrative purposes.
That way it should be possible to enormously customize FlightGear to very specific needs.
So, a page would also be described via XML syntax, it could for example store information such as:
[PAGE SPECIFIC]
- flightgear instrument to be loaded & displayed
- coordinates for this instrument
- actions to be taken as reaction to certain events-such as
"display/change component"
These "unit-files" would then describe each unit page by page - and FliteTutor would interpret the XML files in order to make FlightGear switch into a certain mode - depending on what subsystems are going to be used by a learning unit, actually this is also why I asked in one of my eMails if there is XML support integrated within nasal to use FlightGear's xml-parsing routines - since that would be really convenient.
I would then not need to store lessons as macro-based nasal script
files, but could rather write only FliteTutor itself in nasal, which then offers the possibility to dynamically load learning units within
FlightGear, parse the units (each individual page) and run them.
FliteTutor would then take care of processing the unit files and setting FlightGear's properties in a way to allow the playing of each individual page - until the unit is either completed or cancelled.
Hence, I would nasal need to be able to do mainly the following stuff:
- draw abitrary (plib based) GUI elements within
FlightGear's client area - register (nasal based) callbacks/handlers for controls
such as buttons,textboxes etc. - register callbacks to act on certain mouse events
within FlightGear - load(enable)/unload(disable) individual FlightGear
subsystems - use subsystems (video,network,sound ...) to do certain
things - e.g.: -> draw images/animations within FlightGear's
client area
-> play a certain sound
- do file handling stuff (probably using FlightGear's
XML-routines)
(I might have forgotten 2-3 things, though)The first one would be really hard to implement I'm afraid. The latter doesn't require thread safety IMHO.
Well, I hope it's now easier to understand what I would like to achieve with FlightGear.
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.
As long as there is a way to react to user events (GUI, certain properties to be changed, etc.) this would not be a problem. But it might be also necessary to not only register actions but also specific events with Nasal.
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.
That would be perfectly okay, as long as the corresponding subsystems export the necessary properties to be changed, I think this would also be more elegant and "safe" anyway. On the other hand I don't know how static the XML-based solutions are- and if they can be easily used for dynamic modifications using Nasal.
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: http://simgear.org/doxygen/ FlightGear: http://flightgear.org/docs.html
Thanks for these pointers, but you can bet that I read _a lot_ - if not most - of the FlightGear docs :-)
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
okay, I will check this out within the next couple of days - thanks !
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).
okay, thanks again - but is it then also possible to *dynamically* alter the menu, I mean not using XML definitions files ?
...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.
Sorry, you are right - I was actually referring to "TerraGear" or something that's called similar to that name.
I guess you just want to disable the out-of-the-window view. This is handled by setting "/sim/rendering/draw-otw" to false.
yes, you are right - but in that specific case I would not only want to stop/hide a specific view but really DISABLE background processing of the visual data. Simply because it isn't needed - If that's also done by "stopping" the "view", then that's okay.
<OFFTOPIC> In that regard it would be really useful to add another item to describe each property in the property-tree - that way you could even display a specific description for properties within the integrated property-browser and one would immediatley see, what's the purpose of a certain property and how it affects FlightGear.
One could even go a step further and define, which values are possible for certain properties - that way, these could be offered via a dropdown menu.
For example, if an acceptable property value isof boolean type you would then simply have a "TRUE/FALSE" combo box.
Properties that require filenames/paths could offer a way to browse for these values. </OFFTOPIC>
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)
thanks, I will check it out - is it possible to create more than one panel (on one screen) ?
Cause I would then e.g. display one "panel" with an instrument of the same dimensions in the middle of the screen and might use another panel for a different instrument-still talking here about illustrative purposes and NOT an unusual kind of aircraft :-)
These panels would not need to be inter-connected. If that's not possible - directly using the subsystem with nasal would probably be the way to go ?
- 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.
well, back to good old C++
I'm looking for a way to dynamically do:
cHSIgauge * hsi = new cHSIgauge(); hsi->setDimensions(400,400); hsi->setOBS(290); hsi->setHdg(300); hsi->show(TRUE);
//This isn't slowed down - it's just a quick example
for (int hdg=300;hdg<=360;hdg++) {
hsi->setHdg(hdg);
hsi->show(TRUE);
// display explanations on screen during this "animation"
} This of course then by using Nasal and reacting either to mouse events or playing a predefined set of instructions.
So, I know so far, that all this stuff should be quite possible to be done using Nasal - in combination with XML config files.
But the question is, how to interactively display custom resources such as text/images during such an animation in order to illustrate what's going on to the end-user.
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.
...but I would need these properties then to be used by the underlying subsystem - which -I think- cannot be achieved by merely using Nasal ?
regards
--------- Boris
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
