Re: [Flightgear-devel] ASCII interface
On Tue, Sep 13, 2005 at 09:51:52AM +0200, Erik Hofman wrote: Yes, it's the generic protocol (see Docs/README.IO and data/Protocol/README.Protocol for more information). Sounds good! Actually, I need to feed my data to FG, so it's input. Is this bidirectional in the current CVS? In 0.9.8 it's output only. Thanks, -Gerhard -- o o Gerhard Wesp| http://www.cosy.sbg.ac.at/~gwesp/ \_/ See homepage for email address! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] ASCII interface
Hi, do we already have ASCII realtime I/O for data like position, orientation, controls, configuration etc.? -Gerhard -- o o Gerhard Wesp| http://www.cosy.sbg.ac.at/~gwesp/ \_/ See homepage for email address! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Airport 3/4-letter codes data source
On Thu, Aug 04, 2005 at 09:54:59AM +0200, Torsten Dreyer wrote: here is the example of my homebase, generated from Europe/Greenland: Thanks, this seems to be the way to go (except the usual problems with crap Java applets, sigh...) Cheers -Gerhard -- o o Gerhard Wesp| http://www.cosy.sbg.ac.at/~gwesp/ \_/ See homepage for email address! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Airport 3/4-letter codes data source
Hi all, anybody knows any good source for a list of all airports and their 3-letter code (like JFK, SFO, LHR, etc.) together with its coordinates and/or 4-letter ICAO code? Thanks and kind regards -Gerhard -- o o Gerhard Wesp| http://www.cosy.sbg.ac.at/~gwesp/ \_/ See homepage for email address! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C library timing
There's ISO C's time() which only has second resolution. Then there's SUSv3's gettimeofday() which theoretically has microsecond resolution and in practice in the order of 10ms. Cheers -Gerhard -- Gerhard Wesp o o +43 (0)699 815 98 770 Bachtobelstrasse 56 | http://www.cosy.sbg.ac.at/~gwesp/ CH-8045 Zuerich \_/ See homepage for email address! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] compiling with .NET
On Wed, Apr 06, 2005 at 03:58:24PM +0200, BONNEVILLE David wrote: we don't have this : should we use a bat file to launch msdev with environment variables for each libs paths ? Another idea ? You know you can use .NET's cl from the command line and from makefiles (I mean sane ones, i.e. GNU make). Just start their ``command line tool'' and cygwin from it, then all .NET tools are available under your cygwin shell. 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] segfault in SimGear code
On Fri, Feb 11, 2005 at 04:14:15PM +0100, Ron Lange wrote: double v = vel-getDoubleValue(); = segfault Can you check vel in the debugger? Just set a breakpoint one line above and enter ``print vel'' (in gdb). 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] STL help requested
On Fri, Feb 04, 2005 at 11:37:54PM +0100, Erik Hofman wrote: You could use qsort to sort the map just prior to using it: No you cannot, neither is this necessary. std::map is always maintained in sorted order. For this it uses the comparision function std::less or the one given in the template argument. See Christian Mayer's mail for details. I recommend Nicolai Josuttis' book: The C++ standard library. A tutorial and reference. He also mentions another technique which could be used to achive the desired behaviour: Defining your own char_traits char class. But IMO this is a bit awkward. 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] STL help requested
bool operator()( const string x, const string y) const
{
return your ordering;
}
Where your ordering can be written as
std::lexicographical_compare
( x.begin() , x.end() , y.begin() , y.end() , ICAOcode_char_lt() )
where ICAOcode_char_lt implements the ``less than'' relation for the
individual characters for your ICAO codes:
struct ICAOcode_char_lt {
bool operator()( char const x , char const y ) const {
// Numbers come after letters:
if( std::isalpha( x ) std::isdigit( y ) ) { return true ; }
// Upper-case only comparison:
return std::toupper( x ) std::toupper( y ) ;
}
} ;
(hope this relation is transitive---please check!)
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
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear on IVAO
Anyone interested? :o) Yes. Is there a protocol spec available? 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Diamond TwinStar Panel
On Sat, Jan 01, 2005 at 07:04:53PM -0500, David Megginson wrote: increase the useful load by a couple of hundred pounds and make the plane fly faster, to offset that. Yes. I understand that you come close to Vne in best economy cruise :-) 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Diamond TwinStar Panel
On Sat, Jan 01, 2005 at 05:13:14PM -0500, David Megginson wrote:
Also, it would need someone to model the gearbox and FADEC for the
turbodiesel
engines (includes autopitch etc).
That, I think, would be a much easier problem.
The FADEC is easy as long as everything works normally. Things get more
complex if you want to model failures.
Moreover, one wants to model the automatic engine check sequence.
FWIW, I have a performance table derived from a chart in the Thielert OMM.
The chart (not the OMM, I think) is also available from their web site.
P_max = 99e3 // Max power [W]
M_max = 410 // Max torque [Nm]
//
// Desired RPM as a function of power lever position.
//
RPM_desired = {
{ 0.2 .75 1}
{ 2175 1750 2000 2300 }
}
//
// Mapping of power lever position (normalized) and air density [kg/m^3]
// to power output (ratio to P_max).
//
// Cf. Thielert OMM, Section 3.6 Power curve.
//
// Model valid up to 18000ft density altitude.
//
// Power output is constant below 6000ft.
//
P_out = {
{
// Power lever
{ 0 .25 .5 .65 .75 .91 }
// Rho (density altitude in feet: { 6000 8800 14300 18000 })
{ 1.0239 .9392 .7885 .6958 }
}
{
{ 0 .33 .54 .69 .74 .93 1 }
{ 0 .33 .54 .69 .74 .92 .94 }
{ 0 .34 .54 .69 .74 .92 .94 }
{ 0 .43 .52 .62 .66 .69 .7 }
}
}
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
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cross platform compiling
What compilers do we support? I hope any compliant C++ compiler! I don't have MSVC++ so I was thinking of using MinGW or Cygwin to compile with and forgetting about stuff like #if defined(_MSC_VER) because I cannot test Good luck and let us know about your results! I had success in compiling FlightGear (0.9.6) with cygwin, however the resulting executable seemed very unstable. Don't know if it's me, my Windows system, cygwin, or FlightGear. 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] const and copy constructor
Hmm...
Can you give a complete minimal example? I just tried the following
one, and this compiles without problems, as it should:
= snip ==
struct bar {} ;
struct foo {
foo( foo const rhs ) : p( rhs.p ) {}
bar* const p ;
} ;
= snip ==
Are you *using* the assignment operator for your class somewhere?
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] FreeBSD 5.3--FG 0.9.6
On Tue, Dec 07, 2004 at 01:01:16PM -0600, Curtis L. Olson wrote: CVS tree to work around some of the issues you encountered. If you are able to get a usb joystick to work under FreeBSD with FlightGear, I'd love to hear about it. Unfortunately, no. I'm using a Logitech Extreme3D Pro. An XML configuration file exists for this one, however the axes are mixed up. Second, for stick push/pull and left/right js_demo displays values which are at one extreme almost all of the time. Does anybody know how to calibrate a joystick under FreeBSD? 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] FGNetFDM etc.
Some additional comments on this: The __attribute__(( packed )) trick *no longer works* with current g++ versions. Luckily, since I'm on FreeBSD now, the structs have the same size on FreeBSD and Linux (where my FDM runs). But I don't count on it for the future... 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] FGNetFDM etc.
Hi all, I have some additional interface questions: - What's the unit of vcas? - How does timing work with an external FDM? Will FlightGear use the time it's passed in cur_time (i.e., will the sun rise and set according to it :) Guess it's in UTC? What excatly is the effect of the warp parameter? 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
[Flightgear-devel] --disable-panel and another question
Hi all, isn't --disable-panel supposed to hide the instrument panel? If I start fg with this option alone, it's still there. What's the meaning of the following error (I sometimes get this with an external FDM): Error: base = 0,-1490.92 course = 5.08137 dist = 1.27882e+07 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] gcc seg faults building 0.9.6 under FC2
On Tue, Dec 07, 2004 at 07:23:45AM +0100, Mathias Fr?hlich wrote: That is what you should do ... ... a bug report to the gcc guys! Yes, but I'm sure the gcc guys appreciate very much if you test the current version before! 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] Solaris/GPU recommendations sought!
Why your own FDM? Don't get me wrong - I think there are a lot of reasons why someone would want to write their own FDM. One reason is because it's fun (OK, I'm wierd :-) But, if your being driven to write your own because one of the others is lacking something or there is some other cause, I'd be interested to hear it, for the purpose of possibly making improvements. Well, I guess it's just that I'm weird just as well. :-) Another reason is that, of course, ours is commercial and we *need* complete control over SW development and documentation. I made the experience that the actual development of the FDM *itself* takes up just a minor part of my time, the major parts is consumed by tedious jobs like interfacing with the rest of our systems, with external systems like FlightGear, trying to figure out stupid API documentation of major OS vendors etc... Whereas the actual core of the FDM, the computation of the three force and moment coefficients, is just a couple of lines each. Note BTW that much of my stuff (which is not directly flight simulation related) goes into my cpp-lib project. This may well be of interest for FG as well. 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
[Flightgear-devel] FreeBSD 5.3--FG 0.9.6
Hi all, well, I ditched all Linux/Solaris/IRIX... variants and finally arrived at FreeBSD and now I'm happy :) Nevertheless let me shortly tell you about my experiences. Objective: Set up a PC with a Nvidia graphics card and install FlightGear-0.9.6 on it. Need source code distribution in order to hack FlightGear. Step 1. Install FreeBSD (5.3-RELEASE FreeBSD 5.3-RELEASE). Works as advertised, automagically detects almost all hardware, X11 works almost out of the box. Step 2. Configure X11 to use NVIDIA driver. FreeBSD provides a package for this. Need to know that kernel sources have to be installed, after that it's a matter of ``make install'' and voila. Small problem with libm.so.2 not being available. libm.so.3 can take its role. Step 3. FreeBSD provides pre-built packages for openal and plib. Installing these works straightforward. Step 4. Download SimGear and FlightGear sources, unzip and compile. Observations for SimGear: The configure script appears to be broken (doesn't check for openal): g++ -g -O2 -D_REENTRANT -L/usr/local/lib -L/usr/X11R6/lib -o openal_test1 openal_test1.o ../../simgear/debug/libsgdebug.a -lm gives an error because openal isn't linked. Added it in Makefile as a quick hack. C++ error at screen/extensions.cpp:116: dlerror() returns char const* and not char*. Straightforward fix: Replace by char const *error = dlerror(); FlightGear: configure script doesn't seem to check for usb libraries: Symptoms: /usr/X11R6/lib/libplibjs.a(jsBSD.o)(.text+0xb02): In function `jsJoystick::rawRead(int*, float*)': : undefined reference to `hid_get_data' ../../src/Main/libMain.a(main.o)(.text+0x124f): In function `fgMainLoop': /usr/local//include/simgear/sound/soundmgr_openal.hxx:194: undefined reference to `alListenerfv' Brief manual research reveals that this function is in libusbhid, which I add maually to the Makefile. Same thing for openal. First run of fgfs: Unable to open aircraft directory. The prototype of a not very helpful error message :-). Which directory exactly are you trying to open and why the h*ll can't you? Educated guess: ulOpenDir() (plib) tries to open() the directory in read-write mode. Running fgfs as root works around the problem. open /dev/dsp: No such file or directory Well, I could't care less :-) Glad that fgfs nevertheless continues to start up. Finally, I fly a short round in the Cessna and, on the same hardware as my XP system, fgfs is _much_ more responsive and also seems more stable. Tomorrow I'll know more! Thanks and best regards -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] FGNetFDM etc.
On Fri, Dec 03, 2004 at 09:50:38AM -0800, Andy Ross wrote: Are you sure? Starting with the 3.2.x releases, g++ is supposed to Yes, definitely sure. You can check it out yourself, the test code only included net_fdm.hxx, iostream and wrote sizeof( FGNetFDM ) to std::cout. Compiler flags... I didn't give any on the command line, perhaps there are some implicit ones which I didn't bother to look up. That said, basing a protocol on the idea of spitting raw structures onto the network is kind of a silly idea, for exactly the reasons you posit. But unfortunately an idea which is very often employed in practice. And understandably so, since the alternatives may require a good deal more of bit-fiddling. ASCII is nice, and I already used it in similar contexts without any performance hits. Not seen any arguments against XDR so far... 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] Solaris/GPU recommendations sought!
On Fri, Dec 03, 2004 at 04:21:22PM +0100, Erik Hofman wrote: Does it need to be something you have laying around, and what price is acceptable? No, nothing lying around. A couple of k$. Let's say up to $5k for host + GPU, to start with. 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
[Flightgear-devel] Solaris/GPU recommendations sought!
Hi all, sorry if this is a bit off-topic, but it's solely related to getting FG to work! I'd like to run it on some x86 UNIX variety. Primary objective is to run FlightGear rock solidly (need it as a front end/testing environment) for my own FDM). Second one is ease of install of UNIX on hardware. 3rd is graphics performance. I thought about Solaris. Seems to be absolutely straightforward to install. But I don't know anything about OpenGL and GPU support. Linux: X11 installation (especially GPU drivers) were a pain last time I checked (requires kernel compile!). Has this changed in the meantime. Other options? FreeBSD perhaps? Thanks a lot -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
[Flightgear-devel] FGNetFDM etc.
Hi all, I also played around a little with the native-fdm and native-ctrls. I made the following observations: 1. GNU C++ structure layout may _differ_ between different compiler _minor_ versions. E.g., one sizeof() was 504 bytes on Linux with g++ 3.3.3 and 520 bytes on Cygwin with g++ 3.3.1. Both on x86. 2. One can force the structs into same size by using the GNU-specific attribute __attribute__ (( packed )). 3. GNU compilers ignore #pragma pack etc. 4. There is an RFC 1014: XDR (external data representation) which basically defines big-endian integers and IEEE floating point values. Wouldn't we want to base the interface upon XDR? 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
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
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] Garmin GNS 530
So, one would really need to define a corresponding network interface. This does already exist and is specified in the ``400/500 Series Flight Sim ICD.'', a proprietary Garmin document. It describes the RS232 interface of their _hardware_ simulator units. I guess Bill Stone would give it to interested parties even if they don't buy a simulator unit. Extend the interface with knobs, buttons and light sensor, and you have an ICD for a software interface. 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] nurbs headaches
Unfortunately DEM data is *way* too noisy and has too much potential for odd artifacts to use directly. What I have done is to take a coarse Hmm... About what resolution are we talking here? What additional data do you have available for the runways? I guess you have it's position (two endpoints? center point, direction, length?) and ``elevation''? Commonly, the runway elevation at both thresholds is given in the approach plates, is this data available? How about the following KISS solution: Do a first- or second-order approximation of the elevation of the centerline (least squares). Define the runway using its width, this centerline and no sideways slope. 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] nurbs headaches
This [wc]ould cause problems in places where runways intersect and doesn't account for the surface of all the taxiways and the rest of the Ack. I missed that point. For what it's worth, I believe I have beaten the nurbs approach into submission (mostly) and I hope that the next scenery release will be an OK, congrats! 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] Plea for help: geometry/trigonometry problem
On Wed, Nov 03, 2004 at 04:02:19PM -0600, Jon S Berndt wrote: -atan2(-phi,theta) This looks *very* strange. An arc tangent of a quotient of angles?? Although it works out dimension-wise, I've never seen a quotient of angles in any formula. 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] ARINC 429 protocol
Has anybody had success using ARINC 429 protocol? Yes, I have. How can I help you? -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
Re: [Flightgear-devel] MD-11 Good News
On Tue, May 11, 2004 at 07:04:03PM -0400, Ampere K. Hardraade wrote: Weird how the X-axis runs lengthwise in FlightGear, while the Y-axis runs sideway. No, that's not weird, that's standard in aeronautical engineering! (with the z-axis pointing down, btw.) 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
Re: [Flightgear-devel] COLLISION DETECTION: possible or not?
On Sat, May 01, 2004 at 09:15:09AM +0200, Mathias Fröhlich wrote: 1. Have a callback function in FGInterface which is able to provide you a terrain level and a surface normal for a given lat/lon pair. I'd even suggest also giving linear and rotational velocities for the surface polygon(s). This will allow to model things like A/C carriers, oil platforms moving and pitching in the sea. And earthquakes, if somebody cares :-) Kind regards, -Gerhard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Arrays of doubles
On Fri, Apr 09, 2004 at 08:03:49AM -0500, Jon Berndt wrote: class. All I want right now is how do I allocate storage for a 2 dimensional array of doubles, so that I can use the standard accessor operators: myDouble = Data[n][m]; If you insist on the [][] syntax, I'd strongly recommend a std::vector std::vector double . If not, you can use one of the many C++ matrix implementations floating around, for example (shameless plug :-) cpp-lib, which is available from my homepage: http://www.cosy.sbg.ac.at/~gwesp/ Here you can access the elements by Data( n , m ) ( 1 = n = rows , 1 = m = columns ) (Similar to FORTRAN notation). Kind regards, -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
Re: [Flightgear-devel] vector.push_back() and the d'tor
On Tue, Apr 06, 2004 at 09:03:51PM -0500, Jon Berndt wrote: I'm not positive, but it seems (roughly) like a vector push_back() operation causes the d'tor to be called after the first element is stored. To me, this Yes, if capacity() changes on a resizing operation (like push_back()), the elements need to be moved to a new location, like a realloc() would do in C. This will happen every so often, but so that on average, push_back() finishes in constant time. If you know already on construction time how large your vector will be, you should always call reserve(). HTH -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
[Flightgear-devel] Propeller data
Hi, I have a table of CT/CP/Eta for a variable pitch prop, but I need some help interpreting the data: There is a table giving CT as a function of CP and J, and second one giving the blade angle depending on CP and J. But, what I need is CP and CT as a function of the blade angle and J. Is the idea to go and look up CP by ``inverting'' the second table? (should be possible, since the blade angle depends monotonically on both CP and J). Is there a reason not to directly give CP and CT as functions of blade angle and J? Kind regards, -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
[Flightgear-devel] Book recommendations sought
Hello, I'm looking for good resources on flight simulations. For the aerodynamics and flight dynamics it seems that Stevens, Aircraft Control and Simulation, is (one of) the standard references. Things which Stevens does not cover but which I need also are the modeling of: - landing gear/ground reaction - engines (jet engines in particular) - propeller - environmental effects like turbulence I'd like a book which treats these subjects (or part of them) on a thorough physical/mathematical basis! Kind regards, -Gerhard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] c172-610x
Hi, I just wanted to try out the c172-610x with the HighRes-Panel, but somehow it doesn't work for me: The FG window appears, some messages (pasted below) also, and then all of a sudden without apparent cause FG stops (at ``JSBSim startup beginning''): FlightGear: Version MSVC7-WIN32-0.9.3 Built with Microsoft Visual C++ version 1300 Scanning command line for: --fg-root= fg_root = c:/Program Files/FlightGear-0.9.3/data/ Reading global preferences Finished Reading global preferences Unable to detect the language Selecting language: C Reading localized strings from c:/Program Files/FlightGear-0.9.3/data//Translations/strings-default.xml Scanning command line for: --aircraft= aircraft = c172-610x Reading default aircraft: c172-610x from c:/Program Files/FlightGear-0.9.3/data//Aircraft/c172/c172-610x-set.xml Processing config file: c:/Program Files/FlightGear-0.9.3/data//system.fgfsrc initializing cloud layers texture = c:/Program Files/FlightGear-0.9.3/data//Textures/Sky/overcast.rgb texture = c:/Program Files/FlightGear-0.9.3/data//Textures/Sky/broken.rgba texture = c:/Program Files/FlightGear-0.9.3/data//Textures/Sky/scattered.rgba texture = c:/Program Files/FlightGear-0.9.3/data//Textures/Sky/few.rgba texture = c:/Program Files/FlightGear-0.9.3/data//Textures/Sky/cirrus.rgba Cannot open file: c:/Program Files/FlightGear-0.9.3/data//Scenery/Objects.txt Skipping bad material entry params Tile not found (Ok if initializing) [1m[4mJSBSim Flight Dynamics Model v0.9.4[24m[22m FlightGear aborting [2m[cfg file spec v1.60] [22mJSBSim startup beginning ... The contents of my system.fgfsrc is: --fg-root=C:/Program Files/FlightGear-0.9.3/data --fg-scenery=C:/Program Files/FlightGear-0.9.3/data/Scenery --control=mouse --browser-app=webrun.bat --disable-splash-screen --disable-intro-music --enable-random-objects --disable-sound --disable-hud-3d --enable-enhanced-lighting --enable-distance-attenuation --bpp=32 --time-match-local --log-level=warn This is the 0.9.3 binary installed on Windows XP. Thanks for any help! -Gerhard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] c172-610x
fgfs --aircraft=c172-610x-jsbsim Already tried this on the Windows version, didn't work too. I've now just installed the Linux Debian packages (0.9.3) by Ove Kaaven. On this platform, I get: debian ~% fgfs --aircraft=c172-610x-jsbsim FlightGear: Version unknown version Built with GNU C++ version 3.3 Scanning command line for: --fg-root= fg_root = /usr/share/games/FlightGear Reading global preferences Finished Reading global preferences Unable to detect the language Selecting language: C Reading localized strings from /usr/share/games/FlightGear/Translations/strings-default.xml Scanning command line for: --aircraft= aircraft = c172-610x-jsbsim Reading default aircraft: c172-610x-jsbsim from /usr/share/games/FlightGear/Aircraft/c172/c172-610x-jsbsim-set.xml Error reading default aircraft: Failed to open file at /usr/share/games/FlightGear/Aircraft/c172/c172r-jsbsim-base.xml Note that c172-610x-jsbsim doesn't exist in --show_aircraft! Best regards, -Gerhard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] c172-610x
And the original c172-610x is renamed to: fgfs --aircraft=c172-610x-null Which gave me the idea of trying fgfs --aircraft=c172-610x --fdm=null and this works! Looks great! But it's upside down!! How can I change this? Also, would it be possible to give a FDM explicitly on the command line for --aircraft=c172-610x? -Gerhard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WGS84 changes
I'm not big on C++ pedantry, obviously. Good code can be written in C. It should, IMHO, remain good code when it appears in a C++ Sorry, I didn't mean to critizice your code, obviously it's far more important that the computational results are right than nitpicking over language details. However, I disagree that good C code is automatically good C++ code. E.g., it's good practice to switch from stdio functions to iostream, to use templates instead of macros, to use containers instead of malloc'ed arrays, etc. After all, it's another language, and if you don't need or don't want its features, than why not stick with C in the first place. -Gerhard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WGS84 changes
http://www.plausible.org/andy/new_geodesy.tar.gz Just some minor issues: - the use of static is deprecated for module-local objects, anonymous namespaces should be used instead. - I'd prefer references over pointers. Also, don't pass doubles by value but by const instead. This leaves the compiler more freedom for optimization. -Gerhard -- | voice: +43 (0)662 642934 *** web: http://www.cosy.sbg.ac.at/~gwesp/ | | If emailing to [EMAIL PROTECTED] doesn't work, please try [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Landing Gear
Actually, in the English system the mass unit is slugs - not pounds (lbs): Thanks, I stand corrected. -Gerhard -- | voice: +43 (0)662 642934 *** web: http://www.cosy.sbg.ac.at/~gwesp/ | | If emailing to [EMAIL PROTECTED] doesn't work, please try [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Landing Gear discussion
differential equation sense). Fixing *this* by interpolating the force function over small velocities leads to a stable but non-physical solution that exhibits the drift problem that was talked about. Ah, OK. So did I get this right, here's a tradeoff between the ``physically correct'' model and fixing the stiffness? I.e., stiffness was ``fixed'' by using a physically incorrect model? -Gerhard -- | voice: +43 (0)662 642934 *** web: http://www.cosy.sbg.ac.at/~gwesp/ | | If emailing to [EMAIL PROTECTED] doesn't work, please try [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Landing Gear discussion
be skidding at any given moment. The notion of holding forces at zero makes intuitive sense, but underneath that it has very little physical meaning. On the contrary. I haven't followed this discussion too closely and I'm no physicist either, but this sounds to me exactly like static vs. gliding friction. I still think the rooted spring model has the most promise, although it too is complicated by the fact that rolling wheels will skid in only one dimension. Isn't that a bit of oversimplification? My car will skid in at least two dimensions if I try hard enough :-) And a small amount of skidding will always be present. -Gerhard -- | voice: +43 (0)662 642934 *** web: http://www.cosy.sbg.ac.at/~gwesp/ | | If emailing to [EMAIL PROTECTED] doesn't work, please try [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Landing Gear
depending on tire pressure (etc.) I'd guess that it takes somewhere between 100-200 lb of force (is that the right term?) to start a Almost :-) The actual physical unit of force is the Newton [N=kg m/s^2], which is the force needed to accelerate an object of 1kg with 1 m/s^2, i.e.: The object's velocity changes by 1 m/s if you apply 1 Newton for 1 second. In practice, humans feel the _weight_ of objects as a force which is the product of its mass (lb or kg) and gravity (~9.81 m/s^2). Because gravity is, by and large, constant on our planet, this force and the mass are proportional. Hence one often uses mass (lb) to denote forces. The force corresponding to your 100-200lb would be about 500-1000N. The exact value varies from the poles to the equator :-) -Gerhard -- | voice: +43 (0)662 642934 *** web: http://www.cosy.sbg.ac.at/~gwesp/ | | If emailing to [EMAIL PROTECTED] doesn't work, please try [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Ellipsoid math
Does anyone know how to determine the tangent to a point on a wgs84 ellipsoid? In particular I'm trying to find the geodetic center point of a wgs84 ellipsoid based on a geodetic point on the surface. Given an ellipsoid E a^2 x^2 + b^2 y^2 + c^2 z^2 = 1, the equation of the tangent plane touching E in the point (x_0,y_0,z_0) is a^2 x_0 x + b^2 y_0 y + c^2 z_0 z = 1. -Gerhard -- | voice: +43 (0)662 642934 *** web: http://www.cosy.sbg.ac.at/~gwesp/ | | If emailing to [EMAIL PROTECTED] doesn't work, please try [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
you are doing yourself a ***HUGE*** favor if you keep all the opengl calls caged in a single thread. OK, this is obvious. I obviously misinterpreted the original statement: Threading *within* *an* OpenGL context. I wanted to point out that threading goes well with OpenGL as long as all OpenGL calls come from the same thread, which is exactly what you're saying above. Apart from this, I'd go even further: Most stuff can be decoupled so that the computation can even be split between different processes, which may even run on different machines. Take again visualization (OTW) for example: It's (dynamic) input is position and orientation of the aircraft(s), output is altitude above ground. These are rather minor amounts of data which can easily go across a network. Most commercial FTDs and FNPTs (including these of the company I used to work for) do it that way. It pays to identify and separate the involved concepts using well-defined interfaces. Doing so leads to clean, extensible and efficient design. Best regards, -Gerhard -- | voice: +43 (0)662 642934 *** web: http://www.cosy.sbg.ac.at/~gwesp/ | | If emailing to [EMAIL PROTECTED] doesn't work, please try [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
I know that threading inside an OpenGL context is considered to be a no-no, Why? References? A problem I see is that threading isn't implemented in a standard compliant way on Linux (probably one of the more important platforms), but maybe one can work around that problem. -Gerhard -- | voice: +43 (0)662 642934 *** web: http://www.cosy.sbg.ac.at/~gwesp/ | | If emailing to [EMAIL PROTECTED] doesn't work, please try [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 64-Bit Question
I'm not certain if the size of data types such as ints and pointers will expand to 64-bits in the compiler. I don't find that likely since I'm pretty sure that pointers are 64 bit on most 64 bit architectures. Likewise, long int. int is normally still 32 bit. Code that assumes anything about the size of pointers as related to the size of ints is severely broken. Regards, -Gerhard -- | voice: +43 (0)662 642934 *** web: http://www.cosy.sbg.ac.at/~gwesp/ | | If emailing to [EMAIL PROTECTED] doesn't work, please try [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: Gimp and small textures
I have one more question. Is it posible and how to specify color in postscript by RGB components? Have you looked at the language specification? http://partners.adobe.com/asn/developer/pdfs/tn/PLRM.pdf In case it's not in the core language, it should be trivial to define your own command. -Gerhard -- | voice: +43 (0)676 6253725 *** web: http://www.cosy.sbg.ac.at/~gwesp/ | | Passts auf, seid's vuasichdig, und lossds eich nix gfoin! | -- Dr. Kurt Ostbahn ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] controls-bind()
strstream would do the trick, but not all compilers support it yet. Note that strstream is *deprecated* in C++, one should use stringstreams (sstream) instead. No danger of overflowing any buffers there. Cf. Josuttis, The C++ Standard Library, Section 13.11.2. AFAIK, every major platform now does have compilers which come sufficiently close to the standard to support sstream, or am I missing something? -Gerhard -- | voice: +43 (0)676 6253725 *** web: http://www.cosy.sbg.ac.at/~gwesp/ | | Passts auf, seid's vuasichdig, und lossds eich nix gfoin! | -- Dr. Kurt Ostbahn ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] controls-bind()
Note that MSVC6 does not have sstream while I think VC7 does. Correct. I guess MSVC6 is the only platform which doesn't have sstream? Is there any specific reason why FG has to support a compiler more than 5 years old? Regards, -Gerhard -- | voice: +43 (0)676 6253725 *** web: http://www.cosy.sbg.ac.at/~gwesp/ | | Passts auf, seid's vuasichdig, und lossds eich nix gfoin! | -- Dr. Kurt Ostbahn ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] major frame rate drop?
One of the jobs of the ATC manager is to spread the ATC load by only updating a maximum of one ATC station each frame, and it is assumed that the manager itself will run at full simulation fidelity. Updating only once every 2 seconds would mean a noticable lag between selecting a frequency and sound being rendered (assuming a continuous transmission frequency like ATIS here) since the ATC manager also handles frequency search. It's better that I fix the problem - although I'm quite happy for it to be disabled by default like the AI manager until it's sorted. Could the ATC manager be implemented as a low-priority thread which is woken up every so often (few seconds) to update the list of distances to the ground stations, and additionally if a frequency is changed? The realtime loop would then always have ready-to-use references to the currently selected stations. -Gerhard -- | voice: +43 (0)676 6253725 *** web: http://www.cosy.sbg.ac.at/~gwesp/ | | Passts auf, seid's vuasichdig, und lossds eich nix gfoin! | -- Dr. Kurt Ostbahn ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Compile error in latest cvs
hud.hxx:380: implicit declaration of function `int for_each(...)' Is there any specific reason why you're using gcc 2.95.4? It's *way* old and has a less-than-satisfactory implementation of the standard library. This may well be related to the problem you're seeing. for_each() is in namespace std, however IIRC this old g++ version had the habit to ignore this fact... Hmmm, is the correct header included (I thinks its in algorithm)? -Gerhard -- | voice: +43 (0)676 6253725 *** web: http://www.cosy.sbg.ac.at/~gwesp/ | | Passts auf, seid's vuasichdig, und lossds eich nix gfoin! | -- Dr. Kurt Ostbahn ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Architectural questions
Hello Dev team, Are there projects using FlightGear as the ``engine'' of a simulator with cockpit mockup, multiple projectors, head down display and and possibly a motion platform? This would imply the need for - multiple out-the-window views, most likely driven by multiple rendering machines, with freely definable cameras. - Multiple head down displays (probably TFTs) with instruments. - The possibility to create and add new instruments. - An output of the aircraft dynamics (linear and rotational accelerations) for driving the motion platform. - ... I guess it all boils down to having well-defined ``data streaming'' interfaces between the individual components of flight simulation, the FDM, HDD, Scenery renderer and Sound. For distributed simulation, these would have to bee network protocols (ideally based on some underlying realtime protocol, but in practice it would probably work with UDP or TCP). FlightGear running as an application on one PC or workstation would then simply be a special case of distributed simulation. I'm interested in how well the FlightGear architecture would be suited for such an application, has it been done, what are the developer's thoughts about it, etc. Any feedback is greatly appreciated! As an aside: How much effort does it usually take to add a FDM to FlightGear (e.g., a DC6 model)? Best regards, -Gerhard -- | voice: +43 (0)676 6253725 *** web: http://www.cosy.sbg.ac.at/~gwesp/ | | Passts auf, seid's vuasichdig, und lossds eich nix gfoin! | -- Dr. Kurt Ostbahn ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Architectural questions
http://flightgear.org/Projects/RayChair/raychair.html http://flightgear.org/Projects/ Oops. Should have looked more closely on your homepage. Thanks! We are a bit behind on this part. There is a project called OpenGC that has been working with FlightGear, but I don't know the current status. But your reply sounds as if there's interest. :-) Does jsbsim also take yaw angle into account (fuselage drag)? I.e., is it possible to perform a slip (haven't had a real chance to try yet due to lack of pedals). For yasim I take it it is possible. -Gerhard -- | voice: +43 (0)676 6253725 *** web: http://www.cosy.sbg.ac.at/~gwesp/ | | Passts auf, seid's vuasichdig, und lossds eich nix gfoin! | -- Dr. Kurt Ostbahn ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
