Re: [Flightgear-devel] FliteTutor = A FlightGear based interactive Training Concept
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 Is present. -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 ... 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. Caution has been taken to make each property self explanatory (including what values to expect).
Re: [Flightgear-devel] FliteTutor = A FlightGear based interactive Training Concept
Ampere K. Hardraade wrote: Would you mind posting the link to your site and forum again? http://flitetutor.sourceforge.net Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FliteTutor = A FlightGear based interactive Training Concept
Erik Hofman wrote: Boris Koenig wrote: If anybody of you doesn't yet know what this is all about, please check: http://flitetutor.sourceforge.net (please leave feedback using the poll) Boris, Erik, ;-) First of all, the documentation for Nasal can be found here: http://www.plausible.org/nasal/flightgear.html ya, thanks for that - but this doesn't seem to be complete - even though it's better than having nothing ;-) I could now start to collect and write down all questions that I still have regarding nasal interfacing with FlightGear, but I think that wouldn't lead to anywhere, so please take a look at the offer I made at the end of this mail. Secondly, I really think you are making things too complex. To clarify that I will need to explain the basics of FlightGear some more. FlightGear way of doing things is breaking it up into small pieces. There is (for example) animation code that reacts on property changes. There is also a Flight Dynamics model (FDM) that (amongst other things) updates properties. There is a menu system that can display and alter properties. Then we have sound code that plays sound based on ... properties. Maybe you see a pattern evolve by now. Yes, thanks for that Erik, and you are probably right in saying that I am making things too complex. But this is because of my lack of familiarity with FlightGear and its subsystems. That's exactly why I am asking all these questions - and answers like the ones that you've given so far are really tremendously helpful. 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 ? 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 ! That's usually the problem if you don't have the necessary information available. So, I do appreciate you taking the time to clarify things a bit more for me. Nasal can also read and modify properties but it can also be incorporated into the menu system. 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 ? 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. I would then like something like that to become the basis for my FliteTutor coding attempts in nasal. 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 - alter that instrument's properties - set its properties in a way that allows animation Just to name a few things, I guess you know what I mean. Available for your needs without any code touched. thanks, that's exactly why I am asking all that stuff What might be necessary is to code some hooks into FlightGear to (for instance) disable out of the window view when a certain property is set to false. yes, that's what I meant by adding certain interfacing possibilities - I think I will get back to you, as soon as the basic functionality for FliteTutor has been put on the webpage, in order to see what might need to be added. I hope you start to see the potential possibilities already present in FlightGear *now*. Yes, thank you for that - but: Regarding the FlightGear subsystems, is there any documentation available OR would any of the developers mind to give me some insight ? (this might also be done privately, I really don't want to disturb this mailing list) In exchange I'd love to present the provided information in a graphical way, possibly using UML or any other means to create relational diagrams. We could even feed
Re: [Flightgear-devel] FliteTutor = A FlightGear based interactive Training Concept
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
animation
typerotate/type
object-nameNoseWheel/object-name
property/gear/gear[0]/position-norm/property
factor120/factor
offset-deg-120/offset-deg
min-deg-90/min-deg
max-deg0/max-deg
center
x-m-2.28/x-m
y-m0.0/y-m
z-m0.035/z-m
/center
axis
x0/x
y1/y
z0/z
/axis
/animation
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:http://simgear.org/doxygen/
FlightGear: http://flightgear.org/docs.html
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
Re: [Flightgear-devel] FliteTutor = A FlightGear based interactive Training Concept
...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
Re: [Flightgear-devel] FliteTutor = A FlightGear based interactive Training Concept
On Tuesday 13 July 2004 00:25, Boris Koenig wrote: 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 would like to have it integrated into FlightGear, so that the user can start the lessons from FlightGear in the Sim/Game menu. The lessons could then be picked up in a separate list menu or a menu where the lessons are organized by the required skill level or training tour (basic flying, VFR flight, instrument flight etc.). 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 :-) A webpage with example screenshot drawings with these step by step explanations would be nice. :) Well, I hope it's now easier to understand what I would like to achieve with FlightGear. Yes. BTW, i like the idea very much. ;) 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
Re: [Flightgear-devel] FliteTutor = A FlightGear based interactive Training Concept
On July 12, 2004 08:44 pm, Oliver C. wrote: For example a voice of a pilot instructor could be played that explains what to do next, like turning to heading 230. May be we can also have dynamic responses during a lesson, where the instructor can tell you things like too fast, too slow, too high, too low, etc. It will be a good idea if we can find a text-to-speech engine to do the voice instead of using recordings. Not only will this save us a lot of space, but it will also be more flexible. And for showing how to fly a special flight maneuver we could use transparent squares with visible borders that are placed in the air and describe the flight path that should be flown. For that, an invisible near-flat-cylinder will be more appropiate. For the border, we can have a bunch of trianglar prisms pointing toward the center of the cylinder. This will allow the border to resize independently from the target so that the user can see it no matter how far he is. Of course, if the user is too far from the target, the target itself will need to be bigger as well; otherwise the triangles will get cluttered together. Regards, Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FliteTutor = A FlightGear based interactive Training Concept
good morning ! Oliver C. wrote: On Tuesday 13 July 2004 00:25, Boris Koenig wrote: It wouldn't matter if FlightGear needs to be running directly or if only subsystems get called. I would like to have it integrated into FlightGear, so that the user can start the lessons from FlightGear in the Sim/Game menu. yes, that's also something I'd like to see ultimately, and I didn't mean to imply that FliteTutor should be run externally - just the way the actual interfacing takes place wouldn't be that important to me. But as I said already: IF Nasal can be used/extended for my purposes, I would love to use it. Using Nasal would really simplify many things- e.g. you wouldn't even need to compile yet another package to get FliteTutor to work - also, and even more important: I wouldn't have to mess around with the FlightGear code ;-) The lessons could then be picked up in a separate list menu or a menu where the lessons are organized by the required skill level or training tour (basic flying, VFR flight, instrument flight etc.). yes, it's good that you mention this here - you are the 4th user so far requesting some kind of categorization for FliteTutor units to take place. And we've made already some drafts for potential categories, some of which comprise: The two global categories: GROUNDSCHOOL or FLIGHT TRAINING (the difference MAINLY being the variying demands for subsystems to be loaded/running) Both gobal categories would then contain categories named VFR and IFR to separate lesson units. We could then add general categories such as Instrument Interpretation to the relevant sub-menus. This would be where the final learning units get stored - probably using a title and a short description to be displayed in some kind of quick-browser to get an impression of the outline of a specific unit. But regarding this categorization thing there were really plenty of ideas, some of which even suggesting a user rating for each unit, so that users can provide direct feedback to an author of a FliteTutor lesson-I really can't complain that there are too few ideas for FliteTutor ;-) It seems to be mainly a matter of getting the thing rollin'... Unfortunately, people keep contacting me privately be email in order to make such suggestions instead of directly using the forum or at least this mailing list ;-) - hence, it's likely that many suggestions are repeatedly being made, but so far I've written everything down that I received. But I would like to ask you to post your ideas and suggestions in the forum - that way we have them in a central place and everybody could see what's been suggested so far-there's no need to register in order to post anything in the forum. Also, as I mentioned already on the webpages, I am going to add those features most frequently requested to the features section on the webpage. if you want me to, I can go into even further detail :-) A webpage with example screenshot drawings with these step by step explanations would be nice. :) Well, what do you expect: the FliteTutor webpages are not even 4 days old... Actually, I meanwhile have indeed been contacted by some users who would be willing to help FliteTutor become a bit more than just a vague idea-a lot earlier than I had anticipated. So, we are currently about to collect all feature requests and connect them to our own ideas imaginations - and try to get a working draft for a concept. But this may still take some time. I am also going to send a notification to this list as soon as the first detailed draft for a concept has been finished and when we've put it on the webpage. Particularly, in order to get some feedback about the overall feasibility of all this. But due to the various feature requests that I've received so far, we will have to concentrate mainly on those features that are realistic to be implemented easily into a first coding attempt - which does not mean that anybody should stop sending in utopic suggestions :-) (But please try to use the forum, it makes things easier) Anyway, I do intend to offer some graphical representation of the goals behind FliteTutor - actually, also in order to make the whole thing easier to grasp and to attract those people to keep on reading who don't like to read ;-) Well, I hope it's now easier to understand what I would like to achieve with FlightGear. Yes. Glad to see, but now tell me HONESTLY: how thorougly did you *really* _read_ the webpages ? :-) BTW, i like the idea very much. ;) yes, thanks - strange thing being though: people keep telling me how much they like the idea but fail to leave a vote on the webpage- well at least during the first 2 days, now the situation has already somewhat improved ;-) It would be also very nice, if FliteTutor could be used for in flight lessons. You are again requesting something that has already been requested, and I do wholeheartedly agree with you, but personally I consider it unlikely to be added to a todo list that soon, cause I think
Re: [Flightgear-devel] FliteTutor = A FlightGear based interactive Training Concept
Ampere K. Hardraade wrote: On July 12, 2004 08:44 pm, Oliver C. wrote: For example a voice of a pilot instructor could be played that explains what to do next, like turning to heading 230. May be we can also have dynamic responses during a lesson, where the instructor can tell you things like too fast, too slow, too high, too low, etc. This is -again- a request that has also been made by other users, I would really like to ask you to *use* the forum - that way everybody would be able to see what's been requested so far and we could even introduce polls in order to see what's important to the community. It will be a good idea if we can find a text-to-speech engine to do the voice instead of using recordings. Not only will this save us a lot of space, but it will also be more flexible. lol, that's weird: I just wrote exactly that 2 minuts ago :-) There are various speech-synthesis tools for unix, the mentioned festival being the most prominent one - though I am not sure if any of these could be easily used under windows, but it shouldn't be that much of a problem, because the Microsoft Speech SDK is fairly simple to use - and one could easily write an abstraction layer that could take care of the subtleties for each TTS-system - but also operating system. If I remember correctly the FreeTTS can also be used under windows- gonna have to check it out, though. Just checked google - looks pretty good: http://linux-sound.org/speech.html and festival can be found at: http://www.cstr.ed.ac.uk/projects/festival/download.html regards - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FliteTutor = A FlightGear based interactive Training Concept
Would you mind posting the link to your site and forum again? Thanks in advance, Ampere On July 12, 2004 11:06 pm, Boris Koenig wrote: I would really like to ask you to *use* the forum ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FliteTutor = A FlightGear based interactive Training Concept
If anybody of you doesn't yet know what this is all about, please check: http://flitetutor.sourceforge.net (please leave feedback using the poll) First: apologies for the broken mail - I guess mozilla tried to send it as HTML :-/ Erik Hofman wrote: Boris Koenig wrote: I am currently mainly looking for answers to some of the following questions: - is there demand for an application like this ? I think there is. The responses so far seem to confirm that, by now there are 3 people who have directly contacted me and who would be interested in supporting this project actively - though only one of them having experience with C++ development . This could particularly be useful for the first couple of lessons for a PC-ATD. That's exactly true, I've also thought about similar applications, and I was also contacted by a CFI who suggested many interesting features relevant to PCATD purposes - amongst them: - realtime flight monitoring (possibly on a 2nd station) - flight recording and - evaluation - dynamically setting situations (weather, comms, etc.) Just to mention a few features, now I do realize that some of these things would actually be beyond the scope of FliteTutor itself, as they are rather reasonable suggestions for FlightGear itself. So, is there any bug tracker- or feature request tool maintained for FlightGear ? The todo list on flightgear.org doesn't seem to contain any user suggestions either? It also reminds people that flying isn't easy (which in turn might make it more fun for some of us ...) Yes, but regardless of that, an enhancement like FliteTutor would bring an entirely new level of seriousness to FlightGear. Also it would definitely broaden FlightGear's potential areas of application - and set it once more aparat from other games. I think FlightGear (most than any other simulator) is perfectly capable for this stuff. That's actually what I hoped to read ... but somehow the lack of documentation really seems to cause new problems - while the potential of FlightGear is certainly enormous, the probability that this very potential is also fully exploited is currently limited by that no docs-problem. The only problem might be that it requires more work to get it done (if new code needs to be added). I said already, I don't have any experience developing with/for FlightGear, that's why I was looking for some good pointers here, unfortunately the only way to go seems to be to read the source - that's a bit discouraging, to be honest. But the end result will be precisely what you are aiming for, since everything is open and accessible. I see, you are also indirectly suggesting to dive into the code ? I was originally hoping to find at least some kind of API to be used within FlightGear, the sources for such an API would have also been okay, writing all this stuff from scratch is an entirely different topic if you aren't familiar with the architecture. Anyway - so far, I have spent about 2 hrs reading the source to get a clearer understanding - now I know that I need to read the SimGear sources as well ;-) - is there anything like a general API in order to interface with FlightGear (either externally or as a plugin) ? There are multiple ways to interface with FlightGear. You mentioned only two of these multiple ways: are there any others that you know of ? I don't have any particular prefernce, I would use any method if it isn't too tiresome. Using scripts (Nasal code) The Nasal stuff sounds rather promising, and I've also checked out the /Scripting/ sub-folder in the sources for the particular implementation of the Nasal engine. Hoewever, I do have some concern regarding Nasal - Don't get me wrong: I am very much in favour of using a standardized scripting interface for my purposes, I think that's a lot safer than having someone foreign to the code -like me- poke around in the original source during the attempt to add features. But I wonder how feasible it would really be to use an interpreted script language for potentially time-critical things such as parallel processing of animations. Also, in the same regard I've checked out the available Nalsa docs and read that Nalsa wouldn't be threadsafe, this might be problematic when it really comes to have a Nalsa script process simultaneous tasks. But of course I don't know anything about the details of its implementation within FlightGear. Is there any example code available ? I looked at the files in the base package, some of these seem to make use of Nasal - unfortunately it is not really self-explanatory what's going on behind the scenes. So if anybody has any pointers on Nasal-it would be appreciated. Maybe there are folks here who have more in depth experience with Nasal an who can provide a basic outline of its current abilities and pitfalls. Then there's also the problem that I couldn't find a way to directly execute a
Re: [Flightgear-devel] FliteTutor = A FlightGear based interactive Training Concept
Boris Koenig wrote: If anybody of you doesn't yet know what this is all about, please check: http://flitetutor.sourceforge.net (please leave feedback using the poll) Boris, First of all, the documentation for Nasal can be found here: http://www.plausible.org/nasal/flightgear.html Secondly, I really think you are making things too complex. To clarify that I will need to explain the basics of FlightGear some more. FlightGear way of doing things is breaking it up into small pieces. There is (for example) animation code that reacts on property changes. There is also a Flight Dynamics model (FDM) that (amongst other things) updates properties. There is a menu system that can display and alter properties. Then we have sound code that plays sound based on ... properties. Maybe you see a pattern evolve by now. 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. Nasal can also read and modify properties but it can also be incorporated into the menu system. 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. I think this is already most of what you are looking for. Available for your needs without any code touched. What might be necessary is to code some hooks into FlightGear to (for instance) disable out of the window view when a certain property is set to false. I hope you start to see the potential possibilities already present in FlightGear *now*. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
