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 Nasal script file, so that it really extends FlightGear - I did find the corresponding functions that handle loading & parsing, but not much more.
or using a socket connections (by a telnet like interface).
Yes, I have read something about that - that was pretty much the only page dealing with how to access FlightGear's internals. From what I have seen so far I also think that the standard interface to these properties would not allow all things that I might require.
But this is likely to be generally the case, regardless of the specific method that will be used for interfacing.
So, I wonder if there is for example the possibility to make requests for certain interfaces to be added to the Nasal language.
As there aren't any docs that I am aware of, this seems to be the only option ?
We would then collect all necessary functionality and derive the corresponding need for each specific Nasal interface in order to realize that feature - is there anybody on the mailing list who's got the necessary detail knowledge about FlightGear and Nasal and who's also willing to sacrifice some time to create these interfaces ?
This would for example mean:
1) We need a Nasal object that allows dealing with XML files 2) You would create the necessary connection between FlightGear's XML handling and the Nasal language
or a different example:
1) We need Nasal functionality to dynamically position & resize a vector image 2) You would create the connection between FlightGear's image handling routine and the Nasal language.
Thinking about it, most functionality that we would need to be able to access, such as file-handling, image-processing, support for layers etc. IS ALREADY part of FlightGear - it just needs to be located, probably modularized and exported as a Nasal (or other programming) interface.
PSL has been superseded by Nasal.
This would mean that the PSL functions are also available as Nasal bindings ? How about the other PLIB toolkit, i.e. the gui toolkit: is that also available via Nasal ?
Nasal can do a lot already,
Do you have any details available ? :-) If you haven't already checked out the FliteTutor-Concept pages I would like to ask you to do so now. Maybe you can tell me what exactly can be (already) done with Nasal, and what could (easily) be added - but also to tell me about those functionalities that are not suitable to be implemented by means of Nasal bindungs.
but animating is best done using XML configuration files
I am not sure about the flexibility that these provide, e.g. whether it's possible to do dynamical animations using these XML based files. Like for example doing things such as slowing down an animation based on a certain event.
(although animations can be triggered by setting/changing animation bound properties).
...I know there aren't any docs, but maybe you can tell into which sourcefiles to look in order to try to get a basic understanding about that mechanism ?
If i understand it correctly the I think this doesn't require many C++ code changes.
Well, I have to rely on your impression, I simply lack the detail knowledge, but actually I would not even have hesitated to use C++/PLIB to start the project - but using some kind of publicly API and not really making own changes to the FlightGear source tree.
If I remember correctly Nasal is also meant to be simple to C, so the syntax shouldn't be much of a problem.
Most of this can be done using XML configuration files and Nasal scripting.
Hopefully, you are right :-) But then there will be at least the need to allow for dynamic loading of these extensions into FlightGear, cause these lessons would usually not require the whole flight simulator subsystem to be running - i.e. there will be no need for Terragen to be running while a lesson about instruments is being played.
If Nasal also has support to dynamically modify the plib menu displayed in FlightGear, it should be possible by some kind of standard script to automatically load all extension scripts that are stored in a particular autorun-script folder.
In that regard it would then also be useful to be able to provide command line instructions to load a specific file and determine then, which parts of the subsystem need to be loaded.
For what it's worth, I kind of like the idea.
So, what would you suggest: how should I proceed exactly ?
My next steps would be to write down the essential requirements for a FliteTutor API in order to be able to realize basic functionality.
And I would then want to discuss the requirements here on the mailing list and hope for somebody to add the relevant modifications to FlightGear.
Actually, as long as the corresponding interface is indeed going to be added/enhanced, it shouldn't matter that much if the interface will be available via Nasal, a telnet server,a C++ library or whatever.
Also, if somebody shows me howto add the necessary Nasal interfaces I am quite confident that I could do some of that work myself. Of course I would still have to ask, where a certain function is exactly defined.
---------- Boris
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
