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! Since the field-of-view control gives me a virtual telescope, can we have field-of listen zooming, to simulate directional parabolic ears? 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
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 ... 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! > > > Since the field-of-view control gives me a virtual telescope, can we have > field-of listen zooming, to simulate directional parabolic ears? > > > 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. Andy, It seems like a reasonable turboprop engine model would be a useful thing for YAsim in the long run anyway. I would probably volunteer myself to do a beech 99 yasim config if you added support for turboprop engines. 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
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
Re: [Flightgear-devel] Positional sounds
David Megginson wrote: > 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, still a very good reason use the 'correct' approach right from the beginning :-)) 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] 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] Beech 99
On Thu, 29 Apr 2004 14:18:22 -0400 David Megginson <[EMAIL PROTECTED]> wrote: 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. As of yesterday, Dave Luff had sent me his new implementation of FGPiston (JSBSim), that includes support for turbo/supercharging. I've got a few tweaks to add to the files (almost all for documentation purposes), and then I'll commit it to JSBSim CVS. Additionally, we are very near getting a version of Digital DATCOM that produces output in JSBSim config file format (for the AERODYNAMICS section), thanks to Bill Galbraith (www.holycows.net ... .com ??). So, this could be an aircraft we might want to try modeling, too. Dave Culp has been looking at pairing a turbine and a prop, IIRC, so we can finally test this capability of JSBSim. There's lots more, too. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim fuel problem
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 block at the top of a -set.xml file (next to, not inside, the block). Something like this: # Whatever Nasal code you like ... 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 ___ 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 block at the top of a -set.xml file (next > to, not inside, the block). Something like this: > > > > > # Whatever Nasal code you like ... > > > > > 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... and the scripts then need to be explicitly invoked. Presumably, omitting the '' 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 '' 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 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: