RE: [Flightgear-devel] Getting data out of FlightGear
As promised, I've attached the files that I modified to make FlightGear work with my client software. These modifications allow my client software to receive the correct values out of FlightGear using the native-fdm network setting. I started with the FlightGear v0.9.6 release files to make the changes, so any changes made to these files in CVS since this release have not been incorporated. Also, these modifications were developed and tested on a Windows (WinXP) machine only. However, I was able to build FlightGear with both Cygwin and VC++ v6.0 using these modifications and found no difference in the performance. Thanks again to all of those who responded to my plea for help! I hope that I can repay the help that you have provided me. I'm a newbie as far as FlightGear is concerned, but based on my work and my experience with FlightGear, I hope to try and get more involved with using and developing/adding on to the software. chuck net_fdm.hxx Description: Binary data native_fdm.cxx Description: Binary data ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting data out of FlightGear
On Tue, Nov 30, 2004 at 09:21:23AM -0500, Chuck Cole wrote: As promised, I've attached the files that I modified to make FlightGear work with my client software. These modifications allow my client software to Hi Chuck, this is already a lot better than the old solution. (Specifically, the bools were a problem!) I'd still recommend to replace time_t by double, since time_t ``is more likely to vary in size between platforms'' than double. Perhaps even replace all long's by floats. Same argument: float is 4 bytes on all architectures I know of while this is _not_ true for long. Now when will there be the next FG binary distribution with these incorporated! :-) Cheers -Gerhard -- Gerhard Wesp o o Tel.: +41 (0) 43 5347636 Bachtobelstrasse 56 | http://www.cosy.sbg.ac.at/~gwesp/ CH-8045 Zuerich \_/ See homepage for email address! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting data out of FlightGear
... and _do_ bump the version number!! Cheers -Gerhard -- Gerhard Wesp o o Tel.: +41 (0) 43 5347636 Bachtobelstrasse 56 | http://www.cosy.sbg.ac.at/~gwesp/ CH-8045 Zuerich \_/ See homepage for email address! net_fdm.hxx Description: Binary data ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Getting data out of FlightGear
First of all, thanks to all for your responses and help with this. I have made some progress with this and just wanted to report back for those interested. I went through the net_fdm.hxx and native_fdm.cxx files and set all variables to either long or double, as appropriate. I also made sure that there was no casting involved in setting those values (at least no casting within the native_fdm.cxx code). In doing so, I was able to receive more appropriate values out of FlightGear; however, it did appear that some of the values got shifted. For example, the left and right aileron positions were being reported in the right aileron and rudder variables (but at least they were the correct values) -- the rudder variable comes immediately after the right aileron in the variable declaration sequence. Also, I uncommented out a line in the code in the process() method to print out the size of the buffer that is being sent. According to this statement, the size of the buffer (or the class structure in this case) is 640 bytes. However, when I do the same thing on my side to print out the size of the structure I should be receiving, I get 632 bytes. If I manually calculate what the size should be, giving 4 bytes for longs, 8 bytes for doubles, I get 632. I don't know where the extra 8 bytes come from. Anyway, I'm real interested in getting this to work. As you may have noticed by my e-mail address, I work at NASA Langley. I'm working on a project that will allow pilots and researchers to fly and evaluate scale model planes (in particular, a 757). The plane will obviously be flown remotely. We will eventually be using a Matlab (Simulink) model as the flight model, but until the model is complete, FlightGear is a very nice substitute -- and we need something to help build other software components. But in addition to having a flight model (whether it's Simulink or FlightGear), we also need various displays to show the health and control responses of the model. I'm currently trying to build the displays to show the control responses, and to support this, I need the data out of FlightGear. BTW - I am compiling the code using Cygwin. My code is built using VC++ 6.0. chuck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting data out of FlightGear
Chuck Cole wrote: First of all, thanks to all for your responses and help with this. I have made some progress with this and just wanted to report back for those interested. I went through the net_fdm.hxx and native_fdm.cxx files and set snip Anyway, I'm real interested in getting this to work. As you may have noticed by my e-mail address, I work at NASA Langley. I'm working on a project that will allow pilots and researchers to fly and evaluate scale model planes (in particular, a 757). The plane will obviously be flown remotely. We will eventually be using a Matlab (Simulink) model as the flight model, but until the model is complete, FlightGear is a very nice substitute -- and we need something to help build other software components. But in addition to having a flight model (whether it's Simulink or FlightGear), we also need various displays to show the health and control responses of the model. I'm currently trying to build the displays to show the control responses, and to support this, I need the data out of FlightGear. Hi Chuck, that looks very interesting to this student ;-). Is there any documentation on the 'net about your project? In particuliar how you create the flight model (flight tests with the model, or throwing some clustered pc's at it to calculate the forces etc.?). I wish I had time to do this kind of stuff :-). Greets, Steven ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Getting data out of FlightGear
Quoting Chuck Cole : Also, I uncommented out a line in the code in the process() method to print out the size of the buffer that is being sent. According to this statement, the size of the buffer (or the class structure in this case) is 640 bytes. However, when I do the same thing on my side to print out the size of the structure I should be receiving, I get 632 bytes. If I manually calculate what the size should be, giving 4 bytes for longs, 8 bytes for doubles, I get 632. I don't know where the extra 8 bytes come from. Padding. Usually, structure fields are put at multiple of there size. If there is a multiple of 4 bytes that is not a multiple of 8 before your double, it is shifted. But it is architecture and compiler dependant. You can used #pragma pack with a performance loss or rearrange the fields in your structure. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Getting data out of FlightGear
This was exactly what was happening. I used the #pragma pack(4) directive and this fixed the problem. I'm now able to receive all of the data correctly. I was also able to receive the correct data by moving the variable declarations around as well, but this didn't allow for common variables to be grouped. I understand that there may be a performance hit with the use of the pragma pack statement, but I don't know if it will make any difference in my case. I will post the affected files once I get them cleaned up for those interested. Thanks to all that helped. chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Erik Hofman Sent: Monday, November 29, 2004 1:41 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Getting data out of FlightGear Chuck Cole wrote: Also, I uncommented out a line in the code in the process() method to print out the size of the buffer that is being sent. According to this statement, the size of the buffer (or the class structure in this case) is 640 bytes. However, when I do the same thing on my side to print out the size of the structure I should be receiving, I get 632 bytes. If I manually calculate what the size should be, giving 4 bytes for longs, 8 bytes for doubles, I get 632. I don't know where the extra 8 bytes come from. 632 bytes us called a packed structure. Unpacked structures are aligned to the platform (64-bit or 32-bit aligned, often leaving holes in the structure to align them properly. Erik -- We have offshored my rockband Void, and we are highly popular in India. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting data out of FlightGear
Martin Spott wrote: Just my personal view, Please forgive me all those typos, it's a bit early in the morning, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting data out of FlightGear
On Mon, Nov 22, 2004 at 02:55:15PM -0600, Curtis L. Olson wrote: What's wrong with network byte order? Nothing, I guess. Doesn't define floating point representation, though. What's wrong with ASCII? Cheers -Gerhard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting data out of FlightGear
Gerhard Wesp wrote: On Mon, Nov 22, 2004 at 02:55:15PM -0600, Curtis L. Olson wrote: What's wrong with network byte order? Nothing, I guess. Doesn't define floating point representation, though. Ah, this gives me a hint. There are functions called htond() and htonf() in the following files (these functions really need to be moved to one place in SimGear): native_fdm.cxx native_ctrls.cxx native_gui.cxx I don't think these functions are ever tested within FlightGear. This would be the first thing I would check. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting data out of FlightGear
Chuck Cole wrote: Has anyone tried to use the output of FlightGear (v.0.9.6)? Ive seen in the archives where people have tried to drive the flight model (i.e., as input), but I havent been able to find any posts regarding getting data from the model. Specifically, Im trying to get the surface position output (e.g., flap positions, elevator positions, etc.). I have set up the native-fdm output setting, but when I look at the values that are sent, they are typically very large numbers. I have a feeling that there may be a type mismatch problem in that the values are set as float in the net_fdm.hxx, but the values are retrieved as double. I havent been able to build all of the projects using either Visual C++ 6.0 or using cygwin, so Im unable to see if this is actually the problem or investigate other problems. Any help would be greatly appreciated. If someone could give me some instructions on building the projects myself, I should be able to debug myself, but again, Ive been unable to do so (Ive already gone through the Getting Started documents on the website, but nothing has worked). Currently there is a problem where different platforms, different OS's or even different compilers can get different output due to the fact that structs are used to send data across the network. This can create endian-problems as well as packed/unpacked struct problems. So to be safe you will need to use the same OS, and same compiler for both ends of the connection. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting data out of FlightGear
Erik Hofman wrote: Chuck Cole wrote: [...] Any help would be greatly appreciated. If someone could give me some instructions on building the projects myself, I should be able to debug myself, but again, Ive been unable to do so (Ive already gone through the Getting Started documents on the website, but nothing has worked). Currently there is a problem where different platforms, different OS's or even different compilers can get different output due to the fact that structs are used to send data across the network. This can create endian-problems as well as packed/unpacked struct problems. So to be safe you will need to use the same OS, and same compiler for both ends of the connection. This holds also true for most other structure-based interfaces: Depending on what data you need, it is safer to use the Property Tree interface (telnetd/httpd) to exchange data instead - which might require modifying the sources to actually export the required data in the first place. Unfortunately, using the current telnet interface wouldn't be all that efficient when it comes to permanently polling elements in order to check their values - this would create a traffic and processing workload: Because of that I made about 6-8 weeks ago some changes to my local version that allow registering event handlers via the telnet interface, which would be supposed to essentially allow you to use specific instances of telnet connections to register an event so that (network) traffic is only caused based on certain conditions. I haven't yet finalized everything,but it works to some extent - particularly the SGPropertyNodeListener thing wasn't all that obvious to do for me, that's why I am currently using a workaround. All this was mainly meant to be used for a private project, and it would certainly need some reviewing ... But if you think that something like that would be helpful for you, I wouldn't mind to send you my changes as diff patches. It might certainly come in handy for those people who don't want to fool around with the sources too much, but who would still like to use more advanced use of the Property Tree system via the supported interfaces. -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting data out of FlightGear
Chuck Cole wrote: Has anyone tried to use the output of FlightGear (v.0.9.6)? Ive seen in the archives where people have tried to drive the flight model (i.e., as input), but I havent been able to find any posts regarding getting data from the model. Specifically, Im trying to get the surface position output (e.g., flap positions, elevator positions, etc.). I have set up the native-fdm output setting, but when I look at the values that are sent, they are typically very large numbers. I have a feeling that there may be a type mismatch problem in that the values are set as float in the net_fdm.hxx, but the values are retrieved as double. I havent been able to build all of the projects using either Visual C++ 6.0 or using cygwin, so Im unable to see if this is actually the problem or investigate other problems. Any help would be greatly appreciated. If someone could give me some instructions on building the projects myself, I should be able to debug myself, but again, Ive been unable to do so (Ive already gone through the Getting Started documents on the website, but nothing has worked). Hi Chuck, There should be no reason why you couldn't send the native-fdm structure out of FlightGear to any other application. The control surface values in the native-fdm should be normalized in the range of -1 to 1 (or 0 to 1) depending on the control surface (i.e. ailerons, elevator, rudder, etc.) are -1 to 1, flaps, spoilers, etc. are in the range of 0 - 1. If you aren't seeing values in that range, then you probably aren't reading/interpreting the structure correctly on the remote end. The structure itself is defined in src/Network/net_fdm.hxx, but the wrapper code to send it out or read it in is located in src/Network/native_fdm.[ch]xx. You might notice that the native_fdm code can optionally convert the data to network byte order (which is a standard platform independent byte ordering scheme.) The only issue is that you need to convert from network byte order back to your platform's native order on the receiving end before you try to read the data. You can look in the native_fdm.cxx file to see exactly how this is done ... it's very straightforward. You might also notice that the license terms on the net_fdm.hxx structure is public domain, so you can include this file in your remote application ... that way you can refer directly to the structure elements and it should all work out as it's supposed to. (That's not an option I suppose if your remote end isn't C/C++, in that case you are on your own.) Typically floats are 4 bytes and doubles are 8 bytes so you do need to be careful with that or you will get garbage. It should all be very doable, it's just a matter of getting all the connections mapped correctly. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting data out of FlightGear
Martin Spott wrote: Erik Hofman wrote: Currently there is a problem where different platforms, different OS's or even different compilers can get different output due to the fact that structs are used to send data across the network. This can create endian-problems as well as packed/unpacked struct problems. Oh, this paragraph is an excellent template for my plead for a platform-independent FDM I/O-protocol ;-) What's wrong with network byte order? Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Getting data out of FlightGear
Thanks. I suppose since the other software that I'm using is built with VC++ 6.0, then I'll need to learn how to build FlightGear with that. If there is someone reading this that can help me with that, I'd appreciate it. I would note that other values seem to come out fine, such as those defined as float and int. chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Erik Hofman Sent: Monday, November 22, 2004 3:11 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Getting data out of FlightGear Chuck Cole wrote: Has anyone tried to use the output of FlightGear (v.0.9.6)? I've seen in the archives where people have tried to drive the flight model (i.e., as input), but I haven't been able to find any posts regarding getting data from the model. Specifically, I'm trying to get the surface position output (e.g., flap positions, elevator positions, etc.). I have set up the native-fdm output setting, but when I look at the values that are sent, they are typically very large numbers. I have a feeling that there may be a type mismatch problem in that the values are set as float in the net_fdm.hxx, but the values are retrieved as double. I haven't been able to build all of the projects using either Visual C++ 6.0 or using cygwin, so I'm unable to see if this is actually the problem or investigate other problems. Any help would be greatly appreciated. If someone could give me some instructions on building the projects myself, I should be able to debug myself, but again, I've been unable to do so (I've already gone through the Getting Started documents on the website, but nothing has worked). Currently there is a problem where different platforms, different OS's or even different compilers can get different output due to the fact that structs are used to send data across the network. This can create endian-problems as well as packed/unpacked struct problems. So to be safe you will need to use the same OS, and same compiler for both ends of the connection. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Getting data out of FlightGear
Thanks. I will look at the code again in those files. I noted in my earlier response though that other values seem to be read correctly. But those values are not casted like the surface position variables are in the native_fdm.cxx file (variables are declared as float but values retrieved are double). That's what leads me to believe that it might be a data type issue. However, I will investigate the issues that you and others have suggested. Thanks again. chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curtis L. Olson Sent: Monday, November 22, 2004 3:49 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Getting data out of FlightGear Chuck Cole wrote: Has anyone tried to use the output of FlightGear (v.0.9.6)? I've seen in the archives where people have tried to drive the flight model (i.e., as input), but I haven't been able to find any posts regarding getting data from the model. Specifically, I'm trying to get the surface position output (e.g., flap positions, elevator positions, etc.). I have set up the native-fdm output setting, but when I look at the values that are sent, they are typically very large numbers. I have a feeling that there may be a type mismatch problem in that the values are set as float in the net_fdm.hxx, but the values are retrieved as double. I haven't been able to build all of the projects using either Visual C++ 6.0 or using cygwin, so I'm unable to see if this is actually the problem or investigate other problems. Any help would be greatly appreciated. If someone could give me some instructions on building the projects myself, I should be able to debug myself, but again, I've been unable to do so (I've already gone through the Getting Started documents on the website, but nothing has worked). Hi Chuck, There should be no reason why you couldn't send the native-fdm structure out of FlightGear to any other application. The control surface values in the native-fdm should be normalized in the range of -1 to 1 (or 0 to 1) depending on the control surface (i.e. ailerons, elevator, rudder, etc.) are -1 to 1, flaps, spoilers, etc. are in the range of 0 - 1. If you aren't seeing values in that range, then you probably aren't reading/interpreting the structure correctly on the remote end. The structure itself is defined in src/Network/net_fdm.hxx, but the wrapper code to send it out or read it in is located in src/Network/native_fdm.[ch]xx. You might notice that the native_fdm code can optionally convert the data to network byte order (which is a standard platform independent byte ordering scheme.) The only issue is that you need to convert from network byte order back to your platform's native order on the receiving end before you try to read the data. You can look in the native_fdm.cxx file to see exactly how this is done ... it's very straightforward. You might also notice that the license terms on the net_fdm.hxx structure is public domain, so you can include this file in your remote application ... that way you can refer directly to the structure elements and it should all work out as it's supposed to. (That's not an option I suppose if your remote end isn't C/C++, in that case you are on your own.) Typically floats are 4 bytes and doubles are 8 bytes so you do need to be careful with that or you will get garbage. It should all be very doable, it's just a matter of getting all the connections mapped correctly. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting data out of FlightGear
Curtis L. Olson wrote: What's wrong with network byte order? I wouldn't know. I was never able to test it because I have one x86 machine and one MIPS machine. The difference in handling of the structs prevented me from testing the network byte order issue. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting data out of FlightGear
On Mon, 22 Nov 2004 22:46:55 +0100 Erik Hofman wrote: I wouldn't know. I was never able to test it because I have one x86 machine and one MIPS machine. The difference in handling of the structs prevented me from testing the network byte order issue. Actually, I've seen it work with a FDM running on a SGI machine (Octane) sending values to FG on a (x86) PC. You have to be careful about byte-order (convert to network byte-order), and if you're using C instead of C++, remove any enum in the struct, because they're not actually in the data structure of each element. You can check the size of the struct at each end if you want to be sure the network data packets have the same format everywhere. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting data out of FlightGear
Curtis L. Olson wrote: Martin Spott wrote: Erik Hofman wrote: Currently there is a problem where different platforms, different OS's or even different compilers can get different output due to the fact that structs are used to send data across the network. This can create endian-problems as well as packed/unpacked struct problems. Oh, this paragraph is an excellent template for my plead for a platform-independent FDM I/O-protocol ;-) What's wrong with network byte order? Oh, it's not just the byte order. Let me try to explain my personal attitude on this topic. In the world of I/O-protocols I have been living for you typically had some strange box the you'd want to get your data from plus a sheet explaining a byte or bit mask that tells you how to interpret the data (or how to create a adta stream to make the box understand your intention). You didn't have to deal with the architecture of this box, you simply had this sheet and you knew this sheet was valid most of the time. You had to deal with ongoing development (like in FlightGear) as well, which means someone probably made a soft-/firmware update on this box and didn't know he'd have to give you the appropriate sheet that applies to the new firmware, but there still was a well defined abstraction layer on the I/O channel. When I first came to have a look at the FlightGear project my intention was to use it as an image generator for my own project (which is already on hold now ) and I started looking for the correct method to interface with FlightGear. I definitely was a bit deterred by getting an answer in the range of it depends and I am convinced that others might react similarly. Look at the AeroSim page for example: http://www.u-dynamics.com/aerosim/ They still recommend FlightGear-0.9.2 because they simply fear newer versions could break the interface to their simulation library. It would probably be good for advertizing FlightGear if FG had a well defined FDM I/O interface. This doesn't have to be as sophisticated as the Coein CIGI but at least is should be stable and platform independent. Just my personal view, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
