Boris Koenig wrote:
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.
I think (after reading the whole message) that FlightGear just needs a few modifications. Two come to mind:
1. load a new panel at runtime (refreshing the panel is already possible) 2. add XML I/O support to Nasal.
The way I see it, a panel object could be used as a "sheet" containing the necessary information (animated instruments, text and static graphics). This would require FlightGear to load another "sheet" (panel) when requested to continue. I don't think that's too tough of a problem.
Adding XML I/O to Nasal might be a bit harder to do. I guess the only thing that actually could be done by loading an XML document in Nasal would be to load a new set of pre-defined properties. While this is useful, it might be easier done using C++ instead.
What could not be done using Nasal (and probably never will, although I really would like to see this added for the Radar object) is to load and manipulate 3d objects using Nasal *directly*. Andy (the author of Nasal) has clearly stated that this is probably really hard to do.
Further more, I really think you shouldn't consider "not loading subsystems" because that's impossible right now. Instead it would be easier to disable subsystems after they have been loaded. As far as I can tell, all subsystems that allow disabled don't consume any CPU/GPU time.
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.
There are some hints at the bottom of the document I mentioned earlier, but it's not very comprehensive.
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 unit
This can all be done in the panel configuration file.
So, each unit/lesson would then consist of different "pages" -
(read panels here)
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.
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
That can be done now.
- register (nasal based) callbacks/handlers for controls such as buttons,textboxes etc.
That is already present, but it might work a bit different than what you are hoping for.
- register callbacks to act on certain mouse events within FlightGear
This is done using the instrument configuration file.
- load(enable)/unload(disable) individual FlightGear subsystems
Enable/disable is present for most subsystems.
- use subsystems (video,network,sound ...) to do certain things - e.g.:
-> draw images/animations within FlightGear's client area
Except movies, animations and images can be displayed and positioned already.
-> play a certain sound
- do file handling stuff (probably using FlightGear's XML-routines)
This might need some attention.
(I might have forgotten 2-3 things, though)
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 ?
Hmm, I'm not sure about that ATM ...
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.
Caution has been taken to make each property self explanatory (including what values to expect). This might not count for every single property though.
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) ?
I think it's possible, I'm just not sure if this is possible only for 3d cockpit layouts.
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 ?
The configuration files tell a subsystem to which property it should react. So if you define an animation configuration file to use that property, and tell Nasal to alter that property, everything would be working just fine.
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel