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 animationJust 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 the whole FlightGear source code into some CPP2UML converter and then comment each object/function.
I think such information is really essential - and it should be easily accessible. Maybe one of you guys could quickly write down which subsystems exist, what their purpose is and possibly even start to write down the properties that are accessible using the specific system.
Provided that I am given the needed information, I really wouldn't mind
creating some documentation for FlightGear during the next 3-4 weeks -
as I do have C++ experience you wouldn't need to go into too much detail, either. Also, one should really think about adding some kind
of doc-system support to the FlightGear source - I think that would
really make it easier for novices - like me - to dive into the code
(IF necessary of course).
I would just like to get the necessary information about the architecture of FlightGear itself, and of course the subsystems, in order to be able to use it for some basic FliteTutor drafts using nasal.
That is my offer :-)
Please think about it: One of the developers would need to answer (many) ;-) questions, but in exchange your would have that very information available in an extended form on www.flighteear.org - possibly even
www.developers.flightgear.org ;-)
thanks in advance
-------- Boris
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
