Re: [Flightgear-devel] Slightly OT: Vector math question(s)!
Arnt Karlsen wrote: ..be adviced the guys here torched me for suggesting redoing FG in C, so I guess you by C really meant C++, no? ;-) No I really did mean C :-) I'm not suggesting redoing anything, just writing an app which may be useful to real pilots and FG pilots too. AFAIK (and I don't know much!) the free palm development tools for linux are all C-based. All the best, Matt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Positional sounds
On Thursday 29 Apr 2004 6:40 am, Martin Spott wrote: I _strongly_ support Arnt's idea of 3D coordinates for the sound/noise sources. To complete the picture I'd suggest binding the listener's ear positions to the view direction (implemented somewhere in the viewer mechanics in order to make it work in _every_ view that might be invented in the future). In the long run people will want to hear the left engine of a C310 from the _front_ when they turn the cockpit view to the left, they will want to have a realistic noise location on a walkaround or any other view that moves relative to the aircraft. You could also add noise to any stationary object on the ground - not that I'd want to make FlightGear as noisy as the real world Seconded - this is very important for first-person games [0], but it would be good to have, for instance surround wind noise, engine noise from the engine directions and ATIS speaking from the speakers. Oh, hold on. In a real plane, I've got headphones, haven't I... Their purpose is to deaden ambient noise, and remove stereo cues from sound communications! joke Since the field-of-view control gives me a virtual telescope, can we have field-of listen zooming, to simulate directional parabolic ears? /joke Regards Jonathan [0] By which I mean, it has been done already for a number of OpenAL applications. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Positional sounds
Jonathan Richards wrote: Seconded - this is very important for first-person games [0], but it would be good to have, for instance surround wind noise, engine noise from the engine directions and ATIS speaking from the speakers. Oh, hold on. In a real plane, I've got headphones, haven't I... Their purpose is to deaden ambient noise, and remove stereo cues from sound communications! Yep, but when you're sitting in your favourite light single and you turn your head over to your co (or passengers) you'll still hear most of the engine noise on your left ear - even with headset applied. If something hits the aircraft during flight I assume you'll still notice where the crash happened (I hope it will _never_ happen !!) by the direction the noise comes from, 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
[Flightgear-devel] [OT] CygWierdness
Does anyone know why this might be happening: $ ls -al *.exe ls: invalid option -- Try `ls --help' for more information. I've already checked alias - I don't have anything for ls. ls --version gives: $ ls --version ls (fileutils) 4.1 Written by Richard Stallman and David MacKenzie. Copyright (C) 2001 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Slightly OT: Vector math question(s)!
Matthew Law wrote: Arnt Karlsen wrote: ..be adviced the guys here torched me for suggesting redoing FG in C, so I guess you by C really meant C++, no? ;-) No I really did mean C :-) I'm not suggesting redoing anything, just writing an app which may be useful to real pilots and FG pilots too. AFAIK (and I don't know much!) the free palm development tools for linux are all C-based. All the best, Matt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Just use C++ and avoid all the ++ extensions it should compile ok. :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] CygWierdness
Jon Berndt wrote: Does anyone know why this might be happening: $ ls -al *.exe ls: invalid option -- Try `ls --help' for more information. I've already checked alias - I don't have anything for ls. ls --version gives: $ ls --version ls (fileutils) 4.1 Jon, The only thing that comes to mind is to check if you have a .exe filename that starts with a -. This will confuse ls's command line parser. There are a few ways around that, such as ls -al ./*.exe 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
Re: [Flightgear-devel] [OT] CygWierdness
Jon Berndt wrote: Does anyone know why this might be happening: $ ls -al *.exe ls: invalid option -- Try `ls --help' for more information. I've already checked alias - I don't have anything for ls. ls --version gives: $ ls --version ls (fileutils) 4.1 Written by Richard Stallman and David MacKenzie. Copyright (C) 2001 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel It might be that Win/Dos expands * before it hands the command line to the program. so if there is a file in the directory called --getstuffed.txt then the ls command would get a command line of ls -al --getstuffed.txt If you run under it in a bash shell this should not happen I will test this on my laptop when I get a chance. A co worker had this happen at work yesterday cd v4.0.7 not valid directory was only happening on his laptop and nobody else I tried running cmd instead of command.com and the cd v4.0.7 worked . Sometimes the choice of shell matters. Charles Puffer ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Positional sounds
Martin Spott wrote: Yep, but when you're sitting in your favourite light single and you turn your head over to your co (or passengers) you'll still hear most of the engine noise on your left ear - even with headset applied. If something hits the aircraft during flight I assume you'll still notice where the crash happened (I hope it will _never_ happen !!) by the direction the noise comes from, Personally, I've never noticed any sense of directional hearing while flying -- the engine and wind noise seeps into the aircraft all over the place, through vents, cracks in loose-fitting doors, etc. etc., and in such a small cabin, everything is going to echo and come from all sides anyway. Turning my head does not seem to make a difference. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [OT] CygWierdness
Curt wrote: The only thing that comes to mind is to check if you have a .exe filename that starts with a -. This will confuse ls's command line parser. There are a few ways around that, such as ls -al ./*.exe Heh. You're good. I had a file named -o parseDatcom.exe. Removing that fixed it. Thanks. [I wonder how that file got there ...] Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Positional sounds
joke AFAIK that isn't possible because the earpoint would change whether you were looking at the ground in front or the air 10 miles away. What shouldn't be hard is to take an audio feed from a different location from the viewpoint, but not much might happen if the audio hasn't been initialised because you aren't there yet ... /joke Giles -Original Message- From: Jonathan Richards [mailto:[EMAIL PROTECTED] Sent: 29 April 2004 08:44 To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Positional sounds On Thursday 29 Apr 2004 6:40 am, Martin Spott wrote: I _strongly_ support Arnt's idea of 3D coordinates for the sound/noise sources. To complete the picture I'd suggest binding the listener's ear positions to the view direction (implemented somewhere in the viewer mechanics in order to make it work in _every_ view that might be invented in the future). In the long run people will want to hear the left engine of a C310 from the _front_ when they turn the cockpit view to the left, they will want to have a realistic noise location on a walkaround or any other view that moves relative to the aircraft. You could also add noise to any stationary object on the ground - not that I'd want to make FlightGear as noisy as the real world Seconded - this is very important for first-person games [0], but it would be good to have, for instance surround wind noise, engine noise from the engine directions and ATIS speaking from the speakers. Oh, hold on. In a real plane, I've got headphones, haven't I... Their purpose is to deaden ambient noise, and remove stereo cues from sound communications! joke Since the field-of-view control gives me a virtual telescope, can we have field-of listen zooming, to simulate directional parabolic ears? /joke Regards Jonathan [0] By which I mean, it has been done already for a number of OpenAL applications. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Positional sounds
David Megginson said: Martin Spott wrote: Yep, but when you're sitting in your favourite light single and you turn your head over to your co (or passengers) you'll still hear most of the engine noise on your left ear - even with headset applied. If something hits the aircraft during flight I assume you'll still notice where the crash happened (I hope it will _never_ happen !!) by the direction the noise comes from, Personally, I've never noticed any sense of directional hearing while flying -- the engine and wind noise seeps into the aircraft all over the place, through vents, cracks in loose-fitting doors, etc. etc., and in such a small cabin, everything is going to echo and come from all sides anyway. Turning my head does not seem to make a difference. Lower frequencies especially would be hard to detect direction anyway even without the hard surfaces. This reminds me of the engine out protocol on light twins, which seems to assume that you won't hear which engine is silent. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] mingw, sdl, openal (Andy goes to windows)
I actually got interested in all this windows stuff yesterday (no, I can't explain why), and played around with getting it built. Here's the proof: http://plausible.org/andy/fgfs-mingw.zip [2.3 MB] It's a MinGW* build, using SDL and OpenAL. It works, with sound and video mode switching. The truly interesting thing to me is that it was built entirely on a Linux box using a cross compiler. [* I actually didn't use the MinGW-distributed source code for the tools, because it didn't build cleanly on linux. I used the standard GNU distributions of binutils and gcc with --target=mingw32 instead. I honestly don't know what the differences are; presumably the MinGW version is more recent.] For libraries where I had only a DLL to link against, I hand-built a libXXX.a import library using dlltool, which worked really well. I ended up using the openal32.dll and alut.dll from the NVidia SDK (which comes in a linux-accessible .zip, not an .exe), although at my WinXP installation had the Creative runtime installed (it has a nice installer). The installer doesn't include alut.dll, though, so I include that in the package above; creative ships it as a static library, while NVidia ships a DLL. Note that I didn't actually build SDL or OpenAL using the cross compiler. I used the binaries and headers available on the web. The build process wasn't terribly clean, but no huge changes were required either. Notable notes: + There is no Win32 implementation of the simgear/threads stuff, so MinGW (and MSVC) builds cannot use threads. Cygwin can of course use the POSIX thread API. There were a few configuration bugs here (#define ENABLE_THREADS 0 ... followed by ... #ifdef ENABLE_THREADS) that I had to hack around to turn it off. We should probably write a win32 threading API, since the MSVC folks will want this too and it's the only (!) thing tying us to cygwin.dll right now. + The GNU libstdc++ and MinGW Win32 headers don't interact nicely in some cases. I found a case where a min() macro caused errors when windows.h was included between two C++ headers, but not when it came first or last. There was some similar madness in getting snprintf() and isnan() to be detected properly. + Interestingly, the infamous _snprintf and _isnan win32 names are a non-issue with current mingw32 runtimes, both versions appear in the libraries. The macro tricks I found in simgear/compiler.h (#define isnan _isnan, etc...) actually did more harm than good by confusing the C++ headers. + I didn't try to get glut working, so some auxilliary stuff didn't compile. I hacked around some configure issues and at the resulting Makefiles to plug some gaps, too. I'll try to repeat the deed today, and check in the source code changes where needed. Likewise, I'll package up SDK versions of the OpenAL and SDL libraries and/or write instructions so the windows folks can build against them. If I'm feeling lucky, I might try to fix up the configure scripts to handle this stuff better. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] mingw, sdl, openal (Andy goes to windows)
Andy Ross writes: I actually got interested in all this windows stuff yesterday (no, I can't explain why), and played around with getting it built. Here's the proof: http://plausible.org/andy/fgfs-mingw.zip [2.3 MB] Cool + There is no Win32 implementation of the simgear/threads stuff, so MinGW (and MSVC) builds cannot use threads. see Open Source POSIX Threads for Win32 http://sources.redhat.com/pthreads-win32/ This works fine with MingW or MSVC and FlightGear Note: There is a potential problem if SDL ever spawns a thread, but we shouldn't need to ever do that. This is a being worked on Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Positional sounds
Jim Wilson wrote: Lower frequencies especially would be hard to detect direction anyway even without the hard surfaces. This reminds me of the engine out protocol on light twins, which seems to assume that you won't hear which engine is silent. That's an excellent point -- there are several procedures for identifying which engine is out, and none of them has to do with directional sound. Essentially, the engine noise is transmitted through the entire airframe, and you're doing the equivalent of sitting inside a loudspeaker. I think that the directional sound will be very interesting for external views, and might also be useful for near midair collisions, but in general, I don't think it's much use inside the cockpit. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] YASIM question (for Andy Ross)
Hi Andy, First of all, thanks for your help with the config file. Now I have another question: I would like to ask you if it is possible to start from Yasim in order to obtain a ground vehicle dynamic model. My idea is to develop a truck simulation inside FlightGear and I have thought to start from Yasim because it uses the rigidbody dynamics; moreover in this way I inherit the interface to FlightGear. But there is a little problem: the collision detection, which is not implemented. Moreover the airplanes on the gorund don't follow the slope of the terrain in a realistic manner: they go down parallel to ground if there is a heavy slope: is this behavior due to the fact that the only point of reference is the cg of the aircraft and not the position of the wheels? I would appreciate your opinion about!! Thank you in advance!! Marco ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] YASIM question (for Andy Ross)
Hi Andy, First of all, thanks for your help with the config file. Now I have another question: I would like to ask you if it is possible to start from Yasim in order to obtain a ground vehicle dynamic model. My idea is to develop a truck simulation inside FlightGear and I have thought to start from Yasim because it uses the rigidbody dynamics; moreover in this way I inherit the interface to FlightGear. But there is a little problem: the collision detection, which is not implemented. Moreover the airplanes on the gorund don't follow the slope of the terrain in a realistic manner: they go down parallel to ground if there is a heavy slope: is this behavior due to the fact that the only point of reference is the cg of the aircraft and not the position of the wheels? I would appreciate your opinion about!! Thank you in advance!! Marco ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM question (for Andy Ross)
Marco Gugel wrote: My idea is to develop a truck simulation inside FlightGear and I have thought to start from Yasim because it uses the rigidbody dynamics; Right. That's the RigidBody/Integrator/BodyEnvironment implementation. You set masses on the body, calculate forces inside the environment, and let the integrator figure out the result. But there is a little problem: the collision detection, which is not implemented. Moreover the airplanes on the gorund don't follow the slope of the terrain in a realistic manner: [...] is this behavior due to the fact that the only point of reference is the cg of the aircraft and not the position of the wheels? This is a different problem, and not the only one you are going to discover. Indeed, the collision detection is a hack right now, which presumes a horizontal ground plane under the aircraft. This works just fine for airfields, but not so well for hills (or ships/carriers, for that matter). It's not related to c.g. or positioning issues at all; in fact the application of force at the position of the wheels *is* modelled correctly in YASim, and the c.g. is computed dynamically from the mass distribution; it isn't a user visible parameter... All (heh) that is required to fix this bug is for the gear model to calculate a proper intersection with the terrain polygons instead of using a ground plane defined for the whole aircraft. A more serious problem, though, is that the current YASim gear force model works rather poorly for ground vehicles. It slips against side forces instead of holding position. See recent posts about the gear model for more notes. A few ideas have been kicked around, but all of them are kinda scary to implement. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Beech 99
Iain Dawson has sent me a very nice 2D instrument panel for the Beech 99 which I have committed to CVS. Now that the panel is so nice, it's a shame that the 3d model is so simplistic and unanimated. Anyone want to take a crack at this? Also, the FDM is UIUC based which means the gear/engine modeling is not as nice as we could get out of YASim/JSBsim. Anyone want to take a crack at a new FDM model for the Beech 99 as well? You could probably start with the data for the UIUC model and go from there. 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
Re: [Flightgear-devel] Beech 99
Curtis L. Olson wrote: Anyone want to take a crack at a new FDM model for the Beech 99 as well? You could probably start with the data for the UIUC model and go from there. The Beech 99 is a turboprop, which means that YASim is going to need new code to support it. I'd be happy to write it if someone decides they want to go that way. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Beech 99
Andy Ross wrote: The Beech 99 is a turboprop, which means that YASim is going to need new code to support it. I'd be happy to write it if someone decides they want to go that way. Doing so would open the way to a whole bunch of other interesting turboprops, including the Beech KingAir (from which the Beech 99 evolved, I think), the DeHavilland Twin Otter and Dash-8, the Lockheed C-130 Hercules, and even the single-engine Piper Meridian. Aren't nearly all helicopters turbine-driven as well? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Positional sounds
That would argue for a variable for each viewpoint changing the directionality of the sound (i.e the size of the magnitude of difference between the speakers). Howe easy would this be to implement? Giles -Original Message- From: David Megginson [mailto:[EMAIL PROTECTED] Sent: 29 April 2004 15:34 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Positional sounds Jim Wilson wrote: Lower frequencies especially would be hard to detect direction anyway even without the hard surfaces. This reminds me of the engine out protocol on light twins, which seems to assume that you won't hear which engine is silent. That's an excellent point -- there are several procedures for identifying which engine is out, and none of them has to do with directional sound. Essentially, the engine noise is transmitted through the entire airframe, and you're doing the equivalent of sitting inside a loudspeaker. I think that the directional sound will be very interesting for external views, and might also be useful for near midair collisions, but in general, I don't think it's much use inside the cockpit. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] YASim fuel problem
I just tried an endurance flight in the B-52F, after having tweaked the fdm a bit, but the engines shut down while I still had 64% fuel remaining. The B-52F currently has five fuel tanks: 2 x internal wing tanks - 7lbs, 1 x internal fuselage tank - 73318 lbs 2 x external wing tanks - 18000lbs. This is a simplified layout - the distribution is roughly right, afaik - but it was spread over more tanks. It looks like the fuel was being taken from each tank at the same rate instead of proportionally, depending upon their capacity, with the result that the external wing tanks were emptied while the other tanks still held plenty of fuel, and this caused the engine shutdown. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Positional sounds
Giles Robertson wrote: That would argue for a variable for each viewpoint changing the directionality of the sound (i.e the size of the magnitude of difference between the speakers). No - at least not as long as I don't misunderstand your point ;-) From an engineers point of view (I _am_ an engineer but not a software architect, so peopülemight disagree) it would be sufficient to give each source of noise a 3D location and bind the listeners ears directly to the viewpoint and -direction. The rest would be pretty simple calculöaions of angle and distance, 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
Re: [Flightgear-devel] YASim fuel problem
Lee Elliott wrote: It looks like the fuel was being taken from each tank at the same rate instead of proportionally, depending upon their capacity, with the result that the external wing tanks were emptied while the other tanks still held plenty of fuel, and this caused the engine shutdown. Indeed. The proportionality feature (a hack to handle the fact that you couldn't do tank selection in the original code) was removed with the move to the Nasal fuel code. Now, trying to draw fuel from an empty tank causes an engine failure. In real planes (with exceptions, obviously), you have to select tanks correctly. The proper pilot operation in this case would have been to deselect (set the selected property to false) the wing tanks before they were empty. Obviously some aircraft will be able to draw fuel at different rates from different tanks, but in general this capability will be more complicated than simple proportionality. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d audio and doppler shift
It's even better. You can hook up your 5.1 amplifier and speaker set using ALSA: http://floam.ascorbic.com/how-to/alsa5.1 Finally a fitting moment has come to test my 5.1 digital set up... unfortunately I won't get time until the weekend... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim fuel problem
On Thursday 29 April 2004 19:59, Andy Ross wrote: Lee Elliott wrote: It looks like the fuel was being taken from each tank at the same rate instead of proportionally, depending upon their capacity, with the result that the external wing tanks were emptied while the other tanks still held plenty of fuel, and this caused the engine shutdown. Indeed. The proportionality feature (a hack to handle the fact that you couldn't do tank selection in the original code) was removed with the move to the Nasal fuel code. Now, trying to draw fuel from an empty tank causes an engine failure. In real planes (with exceptions, obviously), you have to select tanks correctly. The proper pilot operation in this case would have been to deselect (set the selected property to false) the wing tanks before they were empty. Obviously some aircraft will be able to draw fuel at different rates from different tanks, but in general this capability will be more complicated than simple proportionality. Andy Fair enough - it's more realistic. Is there a way of starting a Nasal script automatically at start-up? (this would help with zeroing the A-10 external tanks for the clean configuration) I could do a script that monitors the tank levels and de-selects them when they're empty but I don't know how to best invoke it. Perhaps an auto fuel management instrument might be the best answer - when it's clicked, or set to engaged, the fuel management script is invoked. It could then be switched off as well. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] mingw, sdl, openal (Andy goes to windows)
Norman Vine wrote: Andy Ross writes: + There is no Win32 implementation of the simgear/threads stuff, so MinGW (and MSVC) builds cannot use threads. see Open Source POSIX Threads for Win32 http://sources.redhat.com/pthreads-win32/ This works fine with MingW or MSVC and FlightGear The binary package for Windows available on the FG site is build with pthreads enabled. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim fuel problem
On Thursday 29 April 2004 20:50, Andy Ross wrote: Lee Elliott wrote: Is there a way of starting a Nasal script automatically at start-up? (this would help with zeroing the A-10 external tanks for the clean configuration) Sure, you can put a nasal block at the top of a -set.xml file (next to, not inside, the sim block). Something like this: nasal a10 !-- Module name. The aircraft name is a good choice -- script # Whatever Nasal code you like ... /script a10 /nasal The bo105 uses slightly different syntax to load an external .nas file, and you can inspect http://www.plausible.org/nasal/flightgear.html for more detail. I could do a script that monitors the tank levels and de-selects them when they're empty but I don't know how to best invoke it. Actually, it wouldn't be hard to make this the default. We could set a kill engines if empty flag on the tank for aircraft where we wanted stricter behavior. Andy Thanks - a faint light is beginning to illuminate:) So far I've been using this structure (which I copied from another a/c - don't remember which one though) in the set files... nasal B52F script![CDATA[ # Nasal script(s) . . ]]/script /B52F /nasal and the scripts then need to be explicitly invoked. Presumably, omitting the '![CDATA[' and ']]' bits will then result in the scripts being executed at start-up. I'll have a look at how the bo105 does it and see about moving all the scripts I've put in the set file out to external .nas files and use the set file scripts just for start-up stuff. Having a default where the tanks are automatically de-selected when empty would probably be a good thing for beginners. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] OpenAL
David Luff helped some more -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Luff Sent: 28 April 2004 21:18 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] OpenAL Vivian Meazza writes: Result - failure, I downloaded openal.gz (not openal.tgz) and extracted the archive - no problems as far as I can see. Are you *sure* that your browser isn't mangling the file extension - it was a .tgz on Norman's web page when I checked 30 seconds ago. One of my browsers appends .gz to make it openal.tgz.gz, which is of course wrong. I renamed the file openal.tar.gz and extracted the files - seemed like it made no difference. I've downloaded the latest Simgear - compiles OK, no warnings. I've downloaded the latest FlightGear, made the changes. Configure reports with: Checking for library containing alGenBuffers ... No I also get this - don't worry about it! It's because the correct (Norman's) openal libs for cygwin aren't getting set in the configure script yet, so configure's tests can't possibly find them. Obviously this is something that will have to be fixed shortly. I thought that was likely. Then fails with Config.status: creating \ .infig.status: error:cannot find input file. It's possible that you haven't modified your src/Main/Makefile.am properly. All lines of fgfs_LDADD should have a \ at the end of them EXCEPT for the last line. Have you added a \ at the end of the last fgfs_LDADD line? Or removed one of the preceding ones. The space before each entry *must* be a tab I believe, not spaces. If *is* the src/Main Makefile.am you've modified yes, not the top-level one? If all else fails then remove the modified Makefile.am, recheck-out the original, make sure configure completes, and *then* modify it, and then you'll know its your mods that are the culprit if it fails again. I downloaded the most recent CVS version, with the modifications already made, and I still get Config.status: creating \ .infig.status: error:cannot find input file. I went back to the downloaded source code for 0.9.4 - that compiles OK. Any more ideas? A file locked up somewhere? Thanks for you help so far. Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim fuel problem
Lee Elliott wrote:
and the scripts then need to be explicitly invoked.
Presumably, omitting the '![CDATA[' and ']]' bits will then result in the
scripts being executed at start-up.
No, the CDATA stuff is just escaping to prevent the XML parser from
being confused by literal , or characters inside the
script.
Maybe the confusion is the difference between a function definition
and its execution? The stuff between the script tags is exactly one
script, and it is always executed at startup. But if all it does is
something like:
myFunction = func { ... }
then nothing will happen, because all it did is assign the value of
the myFunction *variable* to a function definition. If you want to
invoke the thing you can then do a myFunction(). If you never want
to invoke it again, then they're no need for the func {} stuff at all.
This is a perfectly legal script, for example:
nasal
B52F
script![CDATA[
myFunction = func { print(Executing myFunction()!); }
print(Hello World!\n);
]]/script
/B52F
/nasal
When you start up, it will print Hello World! on the console. It
will *not* print Executing myFunction()!. But later on some other
piece of Nasal code could do:
B52F.myFunction();
Which would then print Executing myFunction()!.
Is that clearer?
I'll have a look at how the bo105 does it and see about moving all
the scripts I've put in the set file out to external .nas files and
use the set file scripts just for start-up stuff.
There is no different in execution between code placed in an external
file and code placed in the script tag. The choice is solely one of
convenience. Small and simple stuff should go inline, more
complicated code ought to have its own file.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] OpenAL
Vivian Meazza writes: I downloaded the most recent CVS version, with the modifications already made, and I still get Config.status: creating \ .infig.status: error:cannot find input file. Hi Vivian, Was this a fresh CVS checkout or did you just refresh your existing files ? If the latter please do the following from your top level FlightGear source directory the one with the files from CVS % rm config*.* % cvs -z3 up -Pd % ./autogen.sh % ./configure % make If this doesn't work please ask again Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Positional sounds
Giles Robertson wrote: That would argue for a variable for each viewpoint changing the directionality of the sound (i.e the size of the magnitude of difference between the speakers). No - at least not as long as I don't misunderstand your point ;-) I'll give an example. In a fictional world, you are facing north, and can't turn, or anything. On your left, you have a one sound (A), and on the right, another (B). Should there be no reflection at all (and diffraction round to your ear will be minimal), you will get nearly all A sound through the left ear, and all B sound through the right ear. Now imagine that you are sitting in a (vastly simplified) cockpit. Because it distributes sound, you can't hear where either A or B are coming from. So we have at least two scenarios - one where all sounds are *only* heard from where they originate, and one where there's no directional sound (sounds are heard equally for all places). Obviously, this is in fact a sliding scale from one to the other. And in some scenarios (tower view) we are pretty close to one end of the scale, and in others (cockpit) we are pretty close to the other end. So we put in a parameter that affects how directional the sound is, with different values for different viewpoints (tower, chase, cockpit). What I don't know is how to implement this, because I've never used OpenAL. Giles Robertson -Original Message- From: Martin Spott [mailto:[EMAIL PROTECTED] Sent: 29 April 2004 18:49 To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Positional sounds From an engineers point of view (I _am_ an engineer but not a software architect, so peopülemight disagree) it would be sufficient to give each source of noise a 3D location and bind the listeners ears directly to the viewpoint and -direction. The rest would be pretty simple calculöaions of angle and distance, 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
[Flightgear-devel] MinGW/cross-compiler writeup
OK, I think I've got the kinks worked out of the MinGW work, and have written up a little README (attached) describing how the process works. Thanks to Norman and Frederic for the pointer to the pthread library. The required changes are in CVS now, and the process has been tested at least on my Fedora box. Hopefully this will be helpful to the windows users who have been left a little behind by the recent SDL and OpenAL changes, or maybe to someone who wants to set up an automated build system for windows binaries. Andy Cross compiling a MinGW FlightGear from Cygwin or Linux [Initial meta-note: these are instructions for how to compile FlightGear to the mingw32 (win32 APIs only, no cygwin.dll, etc...) target, *not* how to compile it using the MSYS command line environment. I presume the user already has either a working linux box or cygwin installation.] First you need to build the MinGW cross compiler tools. (Cygwin users can skip this section and simply install the MinGW environment from the setup tool) I used the source distributions available from the GNU project instead of the MinGW trees, because the MinGW ones failed to build in linux. Either should work under Cygwin. I am assuming that your cross compiler tools are going to live in a directory named /mingw Change this as appropriate. Remember to put /mingw/bin on your path. Some of the configure scripts notice the --prefix setting and pick the right binaries up by default, but others do not, and end up defaulting to the native compiler (trust me, you don't want to spend 20 minutes compiling plib just to discover that you've built a Linux library): export PATH=/mingw/bin:$PATH Get the source to GNU binutils (I used version 2.15) and build it: ./configure --target=mingw32 --prefix=/mingw make make install Now you need the MinGW C runtime and Win32 libraries and headers, because the compiler cannot build without them (this sounds like a bug to me...) Download them from the mingw.org site and unpack them into the /mingw/mingw32 directory. cd /mingw/mingw32 tar xfz /wherever/mingw-runtime-3.2.tar.gz tar xfz /wherever/w32api-2.5.tar.gz Now it is time to build gcc (3.3.3 in my case). This works just like the binutils step: ./configure --target=mingw32 --prefix=/mingw make make install Pick a destination path for your FlightGear installation; I am using /fg here for brevity. You will need to specify this with a --prefix=/fg argument to all configure scripts. Don't forget. For native builds many people use the /usr/local default, but for cross compilation you *must* place the resulting must in a tree by themselves. Before compiling anything, you will need to install the dependent binary libraries (skip to the end of the section if you are happy with downloading packages I put together and don't want to read the long explanation). You will want to install SDK headers and libraries for OpenAL, SDL, pthread, and zlib. The goal here is to get header files, lib*.a static libraries, and (if needed) runtime DLLs for them installed to the appropriate place: the *.a libraries go in /fg/lib, DLLs in /fg/bin, and headers under /fg/include. Unfortunately, because the cross compilation environment is more complicated and because MSVC has traditionally been the standard build environment, none of these packages are as simple to install as configure; make; make install on a linux host, nor are they installable by default with cygwin. The zlib library (source is packaged with SimGear) has a rather primitive non-standard configure script that simply doesn't work for building with a cross compiler or outside a Unix-like environment. I built it (just three files: libz.a, zlib.h, zconf.h) by hand. It *may* be possible to use the zlib implementation that ships with cygwin with a MinGW build; whether it works or not depends on whether the different underlying C libraries are sufficiently compatible. SDL has a nicely packaged mingw32 development tarball on their website (www.libsdl.org). You can simply unpack this under /fg if you like. My version eliminates some of the unnecessary files and is somewhat smaller, but is otherwise unchanged. The Win32 pthread library (http://sources.redhat.com/pthreads-win32) also distributes pre-compiled libraries. Unfortunately, you will have to rename them before using them. They also ship a broken header (no joke) which fails when compiled in an autoconf environment where HAVE_CONFIG_H is defined. My version fixes these problems, but is otherwise the same library. OpenAL is the hardest to get working. First, you really want to install the binary package via the Creative installer (follow link from www.openal.org) in order to take advantage of binary-only vendor
