Re: [Flightgear-devel] engine sounds with UIUC models
"Jim Wilson" <[EMAIL PROTECTED]> wrote: > Heh don't laugh. At LWCE Borland was giving away Kylix which is basically > delphi ported to linux...and if i'm not mistaken that uses something like > turbo pascal as its "language". It's what they call a RAD tool. Or is it a > RAG (rapid atrocity generation) tool? Well Jim, Delphi programmers not only consume more coffee, they have bigger dicks too. ;-) Seriously - there is _no_ other tool on Windows that provide a better or faster RAD tool for client server and 3-tier development. No, maybe it is not suited for something like a flight simulator, but it kicks C++ and VB butt when it comes to the corporate application world. You add stuff like Corba and Oracle to the mix and Delphi is really pretty awesome. -- Billy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] engine sounds with UIUC models
> On Behalf Of Jim Wilson > Sent: Friday, March 15, 2002 7:38 PM > Oh yes, in fact I'm interested in the same promised release. We used formerly > watcom's powerbuilder where I work for some billing and accounting stuff and > it is great. We've got one power user/self taught programmer that does all > kinds of report and utility programs with it. It is great for that kind of > thing and the applications are solid if planned well. But some of the worst > overbudget/neverflew horror stories of the 90's were associated with > powerbuilder...like any RAD (or language for that matter) it can be done right > and wrong. Hence my acronym RAG...being rapid you can create a huge mess > really fast :-). Yeah, that's true. You can do so much with a good, sharp-bladed circular saw, but if you don't know what you are doing, you can cut off your fingers or take out a load-bearing support. :-o > Anyway, if the c++/kylix tool looks good we'll probably look > at rewriting our powerbuilder front ends in it. It's funny that this came up when it did, as the latest issue of C/C++ User's Journal (the subscription issue, anyhow) came with a demo of C++Builder 6.0 Enterprise. Good marketing idea. I'll be trying it out, but I'd be buying the Professional version. Some things I like about it are the editor and the class browser, so I use it with non-VCL projects sometimes, too. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
Jon S Berndt <[EMAIL PROTECTED]> said: > Don't laugh, yourself! ;-) I've used C++Builder since > v1.0 and it's an awesome tool. It is waaay RAD. I'm > excited that they ported Delphi to Linux, and the C++ > version is due soon. In a former job we used it for > developing a *major* gas measurement and accounting > application that was (and still is) used by the big > natural gas companies. We could interface wiht Oracle > tables live (during design), etc. > > Jon > Oh yes, in fact I'm interested in the same promised release. We used formerly watcom's powerbuilder where I work for some billing and accounting stuff and it is great. We've got one power user/self taught programmer that does all kinds of report and utility programs with it. It is great for that kind of thing and the applications are solid if planned well. But some of the worst overbudget/neverflew horror stories of the 90's were associated with powerbuilder...like any RAD (or language for that matter) it can be done right and wrong. Hence my acronym RAG...being rapid you can create a huge mess really fast :-). Anyway, if the c++/kylix tool looks good we'll probably look at rewriting our powerbuilder front ends in it. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Re: [Flightgear-devel] engine sounds with UIUC models
>On Fri, 15 Mar 2002 14:20:49 -0500 > >>Michael Selig writes: > >> > If we do add the myriad properties for many aircraft configuration >> > types to LaRCsim.cxx it means adding lots of code I think. >> >> > [3] The properties structure is pretty general. It seems like it >> > would be pretty easy to trample over someone else's property >> > definitions and/or make poor/improper usage of them? Is there a >> > standard list of reserved properties? > >David M. replied: > >>Nothing's been finalized, but I haven't heard any screaming >>objections. When you want to put information into one of the existing >>subtrees like /surface-positions or /engines, it would probably be a >>good idea to post a short message to see if the other FDM maintainers >>are willing to go along. > >Jon replies: > >The best solution would be for the UIUC guys to bite the >bullet and port their work to use JSBSim. :-) :-) :-) > >Jon > Support :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
On Fri, 15 Mar 2002 23:01:59 - "Jim Wilson" <[EMAIL PROTECTED]> wrote: >Heh don't laugh. At LWCE Borland was giving away Kylix >which is basically >delphi ported to linux...and if i'm not mistaken that >uses something like >turbo pascal as its "language". It's what they call a >RAD tool. Or is it a >RAG (rapid atrocity generation) tool? Don't laugh, yourself! ;-) I've used C++Builder since v1.0 and it's an awesome tool. It is waaay RAD. I'm excited that they ported Delphi to Linux, and the C++ version is due soon. In a former job we used it for developing a *major* gas measurement and accounting application that was (and still is) used by the big natural gas companies. We could interface wiht Oracle tables live (during design), etc. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] engine sounds with UIUC models
Gene Buckle writes: >> >If you're going to insist on cross-platform portability, then it should >obviously be Python. Shhh... a Python FGFS is probably closer to being unleashed then most have any inkling of, so let's not scare it away :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
Jim Wilson wrote: > Heh don't laugh. At LWCE Borland was giving away Kylix which is > basically delphi ported to linux...and if i'm not mistaken that uses > something like turbo pascal as its "language". It's what they call a > RAD tool. Or is it a RAG (rapid atrocity generation) tool? That's about the size of it. Actually, to be fair, I've heard a lot of very reasonable people say some very nice things about Pascal/Delphi/Kylix. It's not just a language, but a whole library environment including GUI framework. For my taste, frankly, it's awful. Even ignoring the Pascal roots, it's a proprietary language developable only with proprietary tools and runable only under a proprietary runtime. Yikes. But the corporate/IS world tends not to care about such things. There, Kylix competes with VB and Java (and soon C#) and probably does quite well. If it comes down to a vote. I'm going with David and FlighTeX. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
David Megginson <[EMAIL PROTECTED]> said: > Curtis L. Olson writes: > > > I'm just about to commit a massive series of changes that converts all > > the .xml files to more standard .ini files. Oh, shoot, I meant to > > save that announcement for 4/1/2002. :-) > > We have to coordinate better -- I'm just finishing switching them all > to TeX. FlightTeX will be a new executable that both flies a plane > and generates beautiful documentation simultaneously, but it will > require us all to learn Pascal. > Heh don't laugh. At LWCE Borland was giving away Kylix which is basically delphi ported to linux...and if i'm not mistaken that uses something like turbo pascal as its "language". It's what they call a RAD tool. Or is it a RAG (rapid atrocity generation) tool? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
> > > > > I'm just about to commit a massive series of changes that converts all > > > the .xml files to more standard .ini files. Oh, shoot, I meant to > > > save that announcement for 4/1/2002. :-) > > > > We have to coordinate better -- I'm just finishing switching them all > > to TeX. FlightTeX will be a new executable that both flies a plane > > and generates beautiful documentation simultaneously, but it will > > require us all to learn Pascal. > > Why? Didn't you know that TeX come with its own programming language? > Better yet, Intercal! g. -- "I'm not crazy, I'm plausibly off-nominal!" http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
David Megginson wrote: > > Curtis L. Olson writes: > > > I'm just about to commit a massive series of changes that converts all > > the .xml files to more standard .ini files. Oh, shoot, I meant to > > save that announcement for 4/1/2002. :-) > > We have to coordinate better -- I'm just finishing switching them all > to TeX. FlightTeX will be a new executable that both flies a plane > and generates beautiful documentation simultaneously, but it will > require us all to learn Pascal. Why? Didn't you know that TeX come with its own programming language? 256 variables should be enough (or was it even 8*256?) - we can use the harddisk if we need more. Or we could use Omikron, the 16 bit TeX version. Oh, and using TeX extensively will help us to find a bug and get lots of cash from Donald E. Knuth :) CU, Christian, who's working on an autopilot in ADA PS: Anyone who wantÄs to do the user interface in EMACS LISP? -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
> On Friday 15 March 2002 05:15 pm, you wrote: > > > > > The best solution would be for the UIUC guys to bite the > > > > > bullet and port their work to use JSBSim. :-) :-) :-) > > > > > > > > Hmm -- today seems to be a big day for trolls. I wonder if any of > > > > Jon's NASA contacts are still waiting for him to bite the bullet and > > > > port JSBSim to FORTRAN. > > > > > > Why? Hand optimized assembler is much faster! > > > > > > Oh, if possible: try to write microcode, that's the only way to get the > > > *real* performance out of those expensive CPUs! > > > > Man, you guys are WAY off base. It's gotta be Visual Basic if you want > > any _real__ performance. Dump that silly OpenGL while you're at it and > > make it work with WinG. > > > > g. > > > > VB?!? C'mon we gotta be cross platform. It's Perl or nothing! > If you're going to insist on cross-platform portability, then it should obviously be Python. g. -- "I'm not crazy, I'm plausibly off-nominal!" http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
> > > The best solution would be for the UIUC guys to bite the > > > bullet and port their work to use JSBSim. :-) :-) :-) > > > > Hmm -- today seems to be a big day for trolls. I wonder if any of > > Jon's NASA contacts are still waiting for him to bite the bullet and > > port JSBSim to FORTRAN. > > Why? Hand optimized assembler is much faster! > > Oh, if possible: try to write microcode, that's the only way to get the > *real* performance out of those expensive CPUs! > Man, you guys are WAY off base. It's gotta be Visual Basic if you want any _real__ performance. Dump that silly OpenGL while you're at it and make it work with WinG. g. -- "I'm not crazy, I'm plausibly off-nominal!" http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
On Friday 15 March 2002 02:20 pm, you wrote: > Michael Selig writes: > > Thanks for all the input on this. It helped get us going. The > > properties structure is pretty neat! > > Thanks. > > > If few questions (probably too many): > > > > [1] Does it sense to define and set our properties inside LaRCsim.cxx > > and not further down in the uiuc_ code? Does it matter? I can > > certainly envision cases where we will want to set properties inside our > > uiuc_ code. > > > > If we do add the myriad properties for many aircraft configuration > > types to LaRCsim.cxx it means adding lots of code I think. > > UIUC is an unusual case, since it is an FDM within an FDM. I'm not > sure how you should work out sharing properties between UIUC and > LaRCsim proper, but I think that your top-level UIUC code is probably > a good place for most of this. > > > [2] Where should we put the sound files. Right now the files are in > > ~fbfsbase/Sounds. But different aircraft will have different > > sounds. Should these sound files go in the respective > > ~fgfsbase/Aircraft directories? > > That's a question for John Check, who is working hard to impose more > order on the sometimes chaotic base package. > > [3] The properties structure is pretty general. It seems like it > > would be pretty easy to trample over someone else's property > > definitions and/or make poor/improper usage of them? Is there a > > standard list of reserved properties? > > So far, we've been managing everything ad-hoc (as with our code -- we > have no style guide or naming conventions there either, and have had > many collisions, especially with macros). We've been considering > making a subtree for each FDM where it can stick whatever it internal > information wants, i.e. > > /fdm/yasim > /fdm/larcsim > /fdm/jsbsim > /fdm/uiuc > Curt had asked me a little while back what I thought about moving the FDM tree under Aircraft. Either scheme works for me. I think moving the FDM config is a good idea and fits nicely with the overall FGFS philosophy. TTYL John > JSBSim might put its coefficients there, for example, and YASim might > put the forces acting on each lifting surface. > > Nothing's been finalized, but I haven't heard any screaming > objections. When you want to put information into one of the existing > subtrees like /surface-positions or /engines, it would probably be a > good idea to post a short message to see if the other FDM maintainers > are willing to go along. > > > All the best, > > > David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
Curtis L. Olson writes: > I'm just about to commit a massive series of changes that converts all > the .xml files to more standard .ini files. Oh, shoot, I meant to > save that announcement for 4/1/2002. :-) We have to coordinate better -- I'm just finishing switching them all to TeX. FlightTeX will be a new executable that both flies a plane and generates beautiful documentation simultaneously, but it will require us all to learn Pascal. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
David Megginson wrote: > > Jon S Berndt writes: > > > The best solution would be for the UIUC guys to bite the > > bullet and port their work to use JSBSim. :-) :-) :-) > > Hmm -- today seems to be a big day for trolls. I wonder if any of > Jon's NASA contacts are still waiting for him to bite the bullet and > port JSBSim to FORTRAN. Why? Hand optimized assembler is much faster! Oh, if possible: try to write microcode, that's the only way to get the *real* performance out of those expensive CPUs! CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
David Megginson writes: > Jon S Berndt writes: > > > The best solution would be for the UIUC guys to bite the > > bullet and port their work to use JSBSim. :-) :-) :-) > > Hmm -- today seems to be a big day for trolls. I wonder if any of > Jon's NASA contacts are still waiting for him to bite the bullet and > port JSBSim to FORTRAN. I'm just about to commit a massive series of changes that converts all the .xml files to more standard .ini files. Oh, shoot, I meant to save that announcement for 4/1/2002. :-) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
Jon S Berndt writes: > The best solution would be for the UIUC guys to bite the > bullet and port their work to use JSBSim. :-) :-) :-) Hmm -- today seems to be a big day for trolls. I wonder if any of Jon's NASA contacts are still waiting for him to bite the bullet and port JSBSim to FORTRAN. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
On Friday 15 March 2002 01:57 pm, you wrote: > At 3/15/02, you wrote: > > [2] Where should we put the sound files. Right now the files are in > ~fbfsbase/Sounds. But different aircraft will have different > sounds. Should these sound files go in the respective ~fgfsbase/Aircraft > directories? ~fgfsbase/Aircraft/$aircraft/Sounds/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
At 3/15/02, you wrote: >David Megginson wrote: >>Erik Hofman writes: >> > To get it working the UIUC code should populate the property tree >> with > at least the following properties (for a piston engine driven >> aeroplane): >> > > > starting/stoping the sounds: >> > --- >> > /engines/engine/cranking >> > /engines/engine/running >> > /gear/gear[]/wow >> > /surface-positions/flap-pos-norm >> > /sim/aero/alarms/stall-warning >>Since UIUC doesn't have any engine start-up code or stall-detection >>code, it's probably good enough just to set /engines/engine[0]/running >>to true (repeat for additional engines), and to copy the value of the >>flap control directly to /surface/positions/flap-pos-norm. > >Or create a sepperate config file which does use the correct properties >for UIUC (without modifications to the code). Thanks for all the input on this. It helped get us going. The properties structure is pretty neat! If few questions (probably too many): [1] Does it sense to define and set our properties inside LaRCsim.cxx and not further down in the uiuc_ code? Does it matter? I can certainly envision cases where we will want to set properties inside our uiuc_ code. If we do add the myriad properties for many aircraft configuration types to LaRCsim.cxx it means adding lots of code I think. [2] Where should we put the sound files. Right now the files are in ~fbfsbase/Sounds. But different aircraft will have different sounds. Should these sound files go in the respective ~fgfsbase/Aircraft directories? [3] The properties structure is pretty general. It seems like it would be pretty easy to trample over someone else's property definitions and/or make poor/improper usage of them? Is there a standard list of reserved properties? Regards, Michael ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:[EMAIL PROTECTED] http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
David Megginson wrote: > Erik Hofman writes: > > > To get it working the UIUC code should populate the property tree with > > at least the following properties (for a piston engine driven aeroplane): > > > > > > starting/stoping the sounds: > > --- > > /engines/engine/cranking > > /engines/engine/running > > /gear/gear[]/wow > > /surface-positions/flap-pos-norm > > /sim/aero/alarms/stall-warning > > Since UIUC doesn't have any engine start-up code or stall-detection > code, it's probably good enough just to set /engines/engine[0]/running > to true (repeat for additional engines), and to copy the value of the > flap control directly to /surface/positions/flap-pos-norm. Or create a sepperate config file which does use the correct properties for UIUC (without modifications to the code). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
Erik Hofman writes: > To get it working the UIUC code should populate the property tree with > at least the following properties (for a piston engine driven aeroplane): > > > starting/stoping the sounds: > --- > /engines/engine/cranking > /engines/engine/running > /gear/gear[]/wow > /surface-positions/flap-pos-norm > /sim/aero/alarms/stall-warning Since UIUC doesn't have any engine start-up code or stall-detection code, it's probably good enough just to set /engines/engine[0]/running to true (repeat for additional engines), and to copy the value of the flap control directly to /surface/positions/flap-pos-norm. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
Tony Peden writes: > You need to write the data to the appropriate properties. You might > take a look at JSBSim.[ch]xx and what we're doing with the > /surface-positions/elevator-pos-norm > /surface-positions/rudder-pos-norm > etc. For LaRCSim, I just added code to copy the control inputs directly to these properties. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
Michael Selig wrote: > At 3/14/02, you wrote: > >> Just a quick note and question. I've been able to get engine sound >> for the different models except the UIUC models. Specifically I've >> been running the different versions of the Cessna 172. JSB and >> Larcsim both produce engine sound but UIUC doesn't. I've looked at >> the xml files and larcsim and UIUC both include the same sound files. >> I'm wondering if I need to add something into the UIUC code for the >> engine sound to work. > > > Expanding on this question, we also don't know how to get control > surface deflections pushed up the code (out of uiuc code and into Main > or wherever) so that the deflections can be seen on the 3D models. I > have a feeling that the engine sound problem is similar ... that we are > not pushing up the data through some .h file or something. > > In a nutshell, sounds worked for us w/ 0.7.8, but now not w/ 0.7.9 (10pre1). I've rewritten the sound code to use XML configurable sound sets on a per aircraft basis (look in FlightGear/Aircraft/c172/c172-sound.xml for an example). This will allow different effects for pistone engine driven and for turbine driven aeroplanes. To get it working the UIUC code should populate the property tree with at least the following properties (for a piston engine driven aeroplane): starting/stoping the sounds: --- /engines/engine/cranking /engines/engine/running /gear/gear[]/wow /surface-positions/flap-pos-norm /sim/aero/alarms/stall-warning getting the correct behaviour: - /engines/engine/mp-osi /engines/engine/rpm /velocities/airspeed-kt /velocities/speed-down-fps /velocities/vertical-speed-fps /position/altitude-ft Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
At 3/14/02, you wrote: Just a quick note and question. I've been able to get engine sound for the different models except the UIUC models. Specifically I've been running the different versions of the Cessna 172. JSB and Larcsim both produce engine sound but UIUC doesn't. I've looked at the xml files and larcsim and UIUC both include the same sound files. I'm wondering if I need to add something into the UIUC code for the engine sound to work. Expanding on this question, we also don't know how to get control surface deflections pushed up the code (out of uiuc code and into Main or wherever) so that the deflections can be seen on the 3D models. I have a feeling that the engine sound problem is similar ... that we are not pushing up the data through some .h file or something. In a nutshell, sounds worked for us w/ 0.7.8, but now not w/ 0.7.9 (10pre1). Wondering in Illinois. Regards, Michael Rob ** Robert Deters Graduate Student Department of Aeronautical and Astronautical Engineering University of Illinois at Urbana-Champaign [EMAIL PROTECTED] ** ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:[EMAIL PROTECTED] http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) **
[Flightgear-devel] engine sounds with UIUC models
Just a quick note and question. I've been able to get engine sound for the different models except the UIUC models. Specifically I've been running the different versions of the Cessna 172. JSB and Larcsim both produce engine sound but UIUC doesn't. I've looked at the xml files and larcsim and UIUC both include the same sound files. I'm wondering if I need to add something into the UIUC code for the engine sound to work. Rob **Robert DetersGraduate StudentDepartment of Aeronautical and Astronautical EngineeringUniversity of Illinois at Urbana-Champaign[EMAIL PROTECTED]**