RE: [Flightgear-devel] fuel freeze
Curtis L. Olson writes: >> >We now have the following properties (the last two are only stubbed >in): > > /sim/freeze/master (implimented) > /sim/freeze/fuel(implimented) > /sim/freeze/position(not implimented) > /sim/freeze/time-of-day (not implimented) Cool ! >Question (to Norman?): > >If we made menu options for these it would be nice to put a check mark >in front of the items that were enabled and remove it when they are >disabled. Is this possible to do with pui? I think so, But I'll have to investigate. A slightly different alternative would be to have the menu item pop up a dialog box with a bunch of radio buttons. This would have the added benefit of keeping the menu tree 'leaner' Thanks Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Latest CVS build problem
Build dies with: l/include -I/usr/X11R6/include -g -O2 -c tileentry.cxx tileentry.cxx: In function `int fgLightsPredraw(ssgEntity *)': tileentry.cxx:876: implicit declaration of function `int glPointParameterfvEXT(...)' tileentry.cxx:877: implicit declaration of function `int glPointParameterfEXT(...)' make[2]: *** [tileentry.o] Error 1 Latest plib/Simgear/Flightgear ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Changes in SimGear
Christian Mayer writes: > Hi, > > is there a reason why SimGear/misc/zfstram.hxx was changed from > > #ifdef HAVE_ZLIB > # include > #else > # include > #endif > > to > > #include > > ? As ZLIB isn't standard (perhaps except on Linux) it's great to have > the fallback to the supplied version. And adding the additional include > directories to ZLIB and probably Metakit (dunno as my compilation > stopped that early) isn't my idea of a clean compilation. It was a slight phylisophical shift. Although zlib and metakit aren't standard on all systems, they are standard on many systems, and there were various problems trying to build them inside of the simgear make system. So, I ripped out the zlib and metakit trees from the distribution so they are never built by default as part of simgear, and instead include zlib-1.1.3.tar.gz and metakit-2.4.2-32.tar.gz as a convenience for those that do need to build these packages themselves. But, because they are configured and compiled separately, simgear builder can better follow their specific install instructions and won't have the problem with simgear inadvertantly screwing things up on some platforms. Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab 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
[Flightgear-devel] fuel freeze
I have just commited around of changes to restructure the 'freeze' aka pause functionality a bit. We now have the following properties (the last two are only stubbed in): /sim/freeze/master (implimented) /sim/freeze/fuel(implimented) /sim/freeze/position(not implimented) /sim/freeze/time-of-day (not implimented) /sim/freeze/master is bound to the 'p' key via keyboard.xml, however, /sim/freeze/fuel is not bound to anything at the moment so you must change it via the external property interface, or specify an initial value on the command line. When /sim/freeze/fuel == true, fuel is not subtracted from the tanks as the engine runs, otherwise fuel is subtracted and you can eventually run out. The default is false so that the fuel in the tanks is consumed. Question (to Norman?): If we made menu options for these it would be nice to put a check mark in front of the items that were enabled and remove it when they are disabled. Is this possible to do with pui? Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab 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] Re: Re: BUG: option --tile-radius missing
Melchior FRANZ wrote: > * Norman Vine -- Saturday 19 January 2002 17:55: > >>* Melchior FRANZ writes: >> >>>[tiles loaded too late at good visibility] >>> >>Try increasing the far_clipping plane >>This is set in src / Main / main.cxx / fgRenderFrame() >>search for ssgSetNearFar() >> > > Thanks, I'll look into that. > > Shouldn't the far_clipping plane be tied to visibility? This slows > down rendering and uses more memory, OTOH it doesn't make sense > to allow far-reaching visibility but to show white tiles on the > horizon. > > [To Charles] > I don't think that flying a 747 at high altitude and good visibility > is that much of an extreme situation. Happens several times every > day in real life. :-> > > m. > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > > True. I was not paying attention to your altitude. I gut stuck on satellite and though you were playing around where there was little or no air left for flying in. Charles ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Configurable Auto pilot
Just realized I forgot to fix the names of those parameters. They should comply with the standard naming now. Same file name: http://www.spiderbark.com/fgfs/newauto-020119.tar.gz Jim John Check <[EMAIL PROTECTED]> said: > it's 404 > > > On Saturday 19 January 2002 05:09 pm, you wrote: > > This makes the current autopilot at least configurable on the verticle > > for different aircraft. There are two configs included, one for c172 and > > the other for the c310: > > > > http://www.spiderbark.com/fgfs/newauto-020119.tar.gz > > > > There are some other features that would be nice to get working > > (pitch hold, apr/gs capture, etc), but I thought I'd suggest this now > > as a bug fix for c310 and other faster aircraft users. > > > > Best, > > > > Jim > > > > ___ > > Flightgear-devel mailing list > > [EMAIL PROTECTED] > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > -- Jim Wilson - IT Manager Kelco Industries PO Box 160 58 Main Street Milbridge, ME 04658 207-546-7989 - FAX 207-546-2791 http://www.kelcomaine.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] SubGear Peek
just a teaser image for now http://www.vso.cape.com/~nhv FWIW - good data is hard to get Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ANN: Fuel
David Megginson <[EMAIL PROTECTED]> said: > > Hmm -- maybe you could set up a Python script to refill the tanks > every few hours. Note that the FGRocket engine model used by the X-15 > was already consuming fuel -- proper fuel consumption just hadn't been > implemented for FGPiston yet. > In flight refueling for a c172? Kewl! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Configurable Auto pilot
oops. fixed! John Check <[EMAIL PROTECTED]> said: > it's 404 > > > On Saturday 19 January 2002 05:09 pm, you wrote: > > This makes the current autopilot at least configurable on the verticle > > for different aircraft. There are two configs included, one for c172 and > > the other for the c310: > > > > http://www.spiderbark.com/fgfs/newauto-020119.tar.gz > > > > There are some other features that would be nice to get working > > (pitch hold, apr/gs capture, etc), but I thought I'd suggest this now > > as a bug fix for c310 and other faster aircraft users. > > > > Best, > > > > Jim > > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: Fuel
Cameron Moore writes: > > - use lb rather than gal_us for fuel levels > > Why? When you fill up the tanks at the airfield, does the pump count in > pounds? As I understand it, larger aircraft do work in pounds. > I think a better solution would be to leave it as a volume > measurement and setup a fuel weight-per-gallon value in the FDM. > Having to set the fuel amount as a weight value seems non-intuitive > to me. You'll still be able to work in gallons at the user level, but I'm uncomfortable about using it in the property list -- people on the FDM list have pointed out that it's the weight, not the volume that matters for the engine and the fight model. In any case the volume will change at high altitude (i.e. 50 gallons at sea level isn't 50 gallons at 30,000 ft, but it's still about 330 lb). JSBSim already uses pounds for its internal calculations, so we're doing a two-way conversion right now. 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] Configurable Auto pilot
it's 404 On Saturday 19 January 2002 05:09 pm, you wrote: > This makes the current autopilot at least configurable on the verticle > for different aircraft. There are two configs included, one for c172 and > the other for the c310: > > http://www.spiderbark.com/fgfs/newauto-020119.tar.gz > > There are some other features that would be nice to get working > (pitch hold, apr/gs capture, etc), but I thought I'd suggest this now > as a bug fix for c310 and other faster aircraft users. > > Best, > > Jim > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Re: BUG: option --tile-radius missing
Melchior FRANZ writes: > Shouldn't the far_clipping plane be tied to visibility? This slows > down rendering and uses more memory, OTOH it doesn't make sense > to allow far-reaching visibility but to show white tiles on the > horizon. Perhaps it could be tied, but not directly, the far clip plan has to at least include the sky dome, sun, moon, stars, planets, clouds, etc. even when the visibility is rather low. Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab 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] ANN: Fuel
On Saturday 19 January 2002 12:41 pm, you wrote: > If you grab the latest SimGear, FlightGear, and base package from CVS, > you'll notice that fuel consumption is now working on JSBSim > piston-engine aircraft (well, the Cessna 310 doesn't have the right > number of tanks or the right fuel capacity, and the Cessna 182 has a > 172 gauge that goes only as high as 28 gal_us/tank, but I'm working on > it). No more non-stop, transpacific flights on autopilot. > > Currently, fuel is referenced in the property manager by gallons, but > I plan on changing it to pounds when I have a chance. Here is a > command-line for a short flight where you don't want to carry around > over 300lb of fuel in the C172, and thus put only 10 gal_us (about 66 > lb) in each tank: > > fgfs --aircraft=c172 \ >--prop:/consumables/fuel/tank[0]/level-gal_us=10 \ >--prop:/consumables/fuel/tank[1]/level-gal_us=10 > > You can read the fuel-flow gauge to see how many gallons your plane is > currently using per hour. When both tanks are empty, the engine will > stop (I'll add a splutter effect some day), so don't let that happen > -- 20 gal_us should still be good for over two hours' flying. > > By default, neither the C172 nor the C182 starts with a full tank. > > Coming changes: > > - use lb rather than gal_us for fuel levels > - add the ability to select feed tanks for each engine > - check whether JSBSim is actually applying the weight for the fuel > - modify JSBSim to clamp fuel levels at tank capacity, to discourage > accidental cheating > - bug someone until they make new, higher-capacity fuel gauges for the > C182 and C310 eheh.. I was thinking, maybe we should make another tree for fig files. It would make things easier because we could reuse stuff and regenerate new textures easier (so I could get better results laying out new textures). You'll note the dual EGT has no numbers. My original version had numbers based on an actual gauge but they were hundreds of degrees too high. No problem, make a copy of th .fig, remove the numbers, viola. I'd like to move to 1 face per texture on some stuff. It would be nice to have 128 and 256px versions. TTYL John ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Configurable Auto pilot
This makes the current autopilot at least configurable on the verticle for different aircraft. There are two configs included, one for c172 and the other for the c310: http://www.spiderbark.com/fgfs/newauto-020119.tar.gz There are some other features that would be nice to get working (pitch hold, apr/gs capture, etc), but I thought I'd suggest this now as a bug fix for c310 and other faster aircraft users. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: Fuel
> Why? When you fill up the tanks at the airfield, does the pump count in > pounds? I think a better solution would be to leave it as a volume > measurement and setup a fuel weight-per-gallon value in the FDM. Having > to set the fuel amount as a weight value seems non-intuitive to me. For light aircraft, the pumps measure gallons in the US. For larger aircraft and for which the fuel tanks have relatively little control of fuel temperature (and thus density), the fuel on board is measured in pounds. I don't know what the pump vehicles measure when depositing jet fuel. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: Fuel
* [EMAIL PROTECTED] (David Megginson) [2002.01.19 11:45]: > If you grab the latest SimGear, FlightGear, and base package from CVS, > you'll notice that fuel consumption is now working on JSBSim > piston-engine aircraft (well, the Cessna 310 doesn't have the right > number of tanks or the right fuel capacity, and the Cessna 182 has a > 172 gauge that goes only as high as 28 gal_us/tank, but I'm working on > it). No more non-stop, transpacific flights on autopilot. Good work. > Coming changes: > > - use lb rather than gal_us for fuel levels Why? When you fill up the tanks at the airfield, does the pump count in pounds? I think a better solution would be to leave it as a volume measurement and setup a fuel weight-per-gallon value in the FDM. Having to set the fuel amount as a weight value seems non-intuitive to me. -- Cameron Moore :wq ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Re: BUG: option --tile-radius missing
* Norman Vine -- Saturday 19 January 2002 17:55: > * Melchior FRANZ writes: > > [tiles loaded too late at good visibility] > Try increasing the far_clipping plane > This is set in src / Main / main.cxx / fgRenderFrame() > search for ssgSetNearFar() Thanks, I'll look into that. Shouldn't the far_clipping plane be tied to visibility? This slows down rendering and uses more memory, OTOH it doesn't make sense to allow far-reaching visibility but to show white tiles on the horizon. [To Charles] I don't think that flying a 747 at high altitude and good visibility is that much of an extreme situation. Happens several times every day in real life. :-> m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: BUG: option --tile-radius missing
* [EMAIL PROTECTED] (Curt Olson) [2002.01.19 14:31]: > Norman Vine writes: > > Try increasing the far_clipping plane > > This is set in src / Main / main.cxx / fgRenderFrame() > > search for ssgSetNearFar() > > > > FWIW > > I moved the far plane WAY BACK in order to simulate the satelite views > > on the 'snapshot page' :-) > > Maybe the far clip distance needs to become a property/command line > option? I would vote for this. I wanted to implement this a long time ago, but never got around to it. -- Cameron Moore [ Would a fly without wings be called a walk? ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: Fuel
From: "Norman Vine" <[EMAIL PROTECTED]> > Martin Olveyra writes: > > > >I haven't still synced everything so I haven't tested this new feature, > >but for the sake of realness, we can perform a flight around doing scales > >at airports, and then refill the tanks. If I remember correctly, some > >properties can be setted in the menu, so we can refuel the > >plane at any time. > > Yes you can but that isn't my point > > This is a SIM not a REALITY therefore we can do things differently > then reality and one of those things that should be done differently > IMHO is to have the possibility of a constant fuel supply hence weight ! I agree with both Martin and Norman. I think we should have the ability to freeze variables as Curt already says but we should also have the ability to refuel the plane, on the ground, or during flight for military aircrafts. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ANN: Fuel
Curtis L. Olson writes: > Beyond that, the flightgear framework and C172 can be used for many > other purposes. I like the idea of having things behave > realistically by default, but be able to override some of these > realism features as needed. I have no objection to adding special behaviour later, when we've hit some of the higher priorities like weather, GPS, better autopilot, object placement in scenery, better polygon clipping and triangulation in TerraGear, turbine-engine model, air-traffic control, ai-controlled planes, etc. etc.; I'd hate to have to worry about little details right now, though. 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] ANN: Fuel
Norman Vine writes: > 'known' amount of fuel would be accident reconstruction where one > knew the amount of fuel on board when a crash occured but weren't > sure of what caused it and you kept trying different manuvers testing > the planes responses. If the fuel supply wasn't capable of remaining > constant then the flight characteristics would change as the experiment > progressed. A common technique in training is to concentrate on one aspect of the task in order to master it before you put all the pieces together. >From my 'forced' piano lesson days, I'd often practice the notes for just one hand or the other. It's much easier to put it all together once you have mastered the individual components. On some aircraft, fuel amount, weight and balance is a significant thing and can be a significant distraction when trying to learn something else, so it is very useful from a purely flight simulation point of view to be able to freeze the amount of fuel in the tanks, but have everytyhing else operate normally. Beyond that, the flightgear framework and C172 can be used for many other purposes. I like the idea of having things behave realistically by default, but be able to override some of these realism features as needed. Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab 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] Re: BUG: option --tile-radius missing
Norman Vine writes: > Try increasing the far_clipping plane > This is set in src / Main / main.cxx / fgRenderFrame() > search for ssgSetNearFar() > > FWIW > I moved the far plane WAY BACK in order to simulate the satelite views > on the 'snapshot page' :-) Maybe the far clip distance needs to become a property/command line option? Also note that the sky bowl could also intersect with the ground to limit your maximum visibility. If you find this to also be a factor you will need to increase the radius of the sky bowl. Curt. -- Curtis Olson Intelligent Vehicles Lab 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] ANN: Fuel
Martin Olveyra writes:
>
>I haven't still synced everything so I haven't tested this new feature,
>but for the sake of realness, we can perform a flight around doing scales
>at airports, and then refill the tanks. If I remember correctly, some
>properties can be setted in the menu, so we can refuel the
>plane at any time.
Yes you can but that isn't my point
This is a SIM not a REALITY therefore we can do things differently
then reality and one of those things that should be done differently
IMHO is to have the possibility of a constant fuel supply hence weight !
Note Curt pointed out a few other things that are also normally capable
of 'altering reality' in commercial SIMS.
Don't take me wrong I am all for getting FGFS as REAL as possible
but this shoudn't be done at the expense of keeping the SIM a general
purpose framework that is suitable for all kinds of experiment
I don't see the problem here its just one
if ( ) { ... }
versus having to have either
1) a daemon program or
2) some form of operator interaction
One practical application where it would be useful to have a 'constant'
'known' amount of fuel would be accident reconstruction where one
knew the amount of fuel on board when a crash occured but weren't
sure of what caused it and you kept trying different manuvers testing
the planes responses. If the fuel supply wasn't capable of remaining
constant then the flight characteristics would change as the experiment
progressed.
Cheers
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: Fuel
I haven't still synced everything so I haven't tested this new feature, but for the sake of realness, we can perform a flight around doing scales at airports, and then refill the tanks. If I remember correctly, some properties can be setted in the menu, so we can refuel the plane at any time. On 2002.01.19 15:25 Norman Vine wrote: > David Megginson writes: > > > >If you grab the latest SimGear, FlightGear, and base package from CVS, > >you'll notice that fuel consumption is now working on JSBSim > >piston-engine aircraft (well, the Cessna 310 doesn't have the right > >number of tanks or the right fuel capacity, and the Cessna 182 has a > >172 gauge that goes only as high as 28 gal_us/tank, but I'm working on > >it). No more non-stop, transpacific flights on autopilot. > > COOL , Great :-) > > But we need an overide to ignore fuel consumption so we can > do non-stop around the world flights on autopilot. > > I keep thinking of an old post by Oliver where he couldn't get to > his machine because the neighborhood kids were using it to > fly FlightGear all the time. > > They loved it because it was a SIMPLE FlightSim. > ie the engines were already started >you didn't have to worry about running out of fuel >when you crashed you just used the reset menu >when a mountain got in the way you just added emergency altitude >when you wanted to go faster you hit the accelerator key >ect.. > > This was a while ago and the SIM is much more 'realistic' > now but I wonder if it would still have the same appeal as > it did to those kids a couple of years ago or if they would > consider it another of those 'adult sims' that was too complicated ? > > IMHO the realism is great but we should also keep the > KISS version around. > > BTW - Nice addition, we needed this :-) > > Cheers > > Norman > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] C172 JSBSim departure
On the other machine, using current FGFS CVS stuff, takeoff works fine. What versions of stuff were you using and having trouble with ? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ANN: Fuel
Norman Vine writes: > But we need an overide to ignore fuel consumption so we can do > non-stop around the world flights on autopilot. Hmm -- maybe you could set up a Python script to refill the tanks every few hours. Note that the FGRocket engine model used by the X-15 was already consuming fuel -- proper fuel consumption just hadn't been implemented for FGPiston yet. > I keep thinking of an old post by Oliver where he couldn't get to > his machine because the neighborhood kids were using it to fly > FlightGear all the time. > > They loved it because it was a SIMPLE FlightSim. > ie the engines were already started >you didn't have to worry about running out of fuel Practically speaking, you still don't, at least not from the kids' perspective. Even at fairly high high speed, the C172 can stay in the air for 4 hours or more without refueling. When I let kids try flight simulators on my computer, the average flight is about 45 seconds. > This was a while ago and the SIM is much more 'realistic' now but I > wonder if it would still have the same appeal as it did to those > kids a couple of years ago or if they would consider it another of > those 'adult sims' that was too complicated ? The biggest problem will be p-factor -- it's very hard to keep the nose straight now on takeoff. In my experience, though, most kids prefer to start in the air anyway. In fact, they might prefer magic-carpet/slew mode over anything else. > BTW - Nice addition, we needed this :-) Thanks. 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] ANN: Fuel
Norman Vine writes: > David Megginson writes: > > > >If you grab the latest SimGear, FlightGear, and base package from CVS, > >you'll notice that fuel consumption is now working on JSBSim > >piston-engine aircraft (well, the Cessna 310 doesn't have the right > >number of tanks or the right fuel capacity, and the Cessna 182 has a > >172 gauge that goes only as high as 28 gal_us/tank, but I'm working on > >it). No more non-stop, transpacific flights on autopilot. > > COOL , Great :-) > > But we need an overide to ignore fuel consumption so we can > do non-stop around the world flights on autopilot. What is done on the big commercial sims is to have a fuel-freeze option. With this enabled, everything else happens normally, except no fuel is subtracted from the tanks. This is useful for training as well because sometimes you want to eliminate changing weight and balance issues when you are concentrating on practicing/learning something else. I think it would be useful to have: master-freeze - the entire sim pauses fuel-freeze - tank quantities don't change position-freeze - lat/lon doesn't change (but if everything else behaves normally.) This gives you the option of practicing various maneuvers without leaving a training area ... more important if you are buying time in a real 747 sim, but still would be useful for us. time-of-day-freeze - sun/moon/stars/lighting doesn't change/progress. Anything else? Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab 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] Breaking OpenGL's hold to ease debugging
> >3. it uses a single audio buffer, instead of the commonly accepted > >dubbel buffering principle. The PLIB itself is single buffered, but that's ok because the sound driver itself on Linux and Windows (dunno about irix) is multi-buffered. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ANN: Fuel
David Megginson writes: > >If you grab the latest SimGear, FlightGear, and base package from CVS, >you'll notice that fuel consumption is now working on JSBSim >piston-engine aircraft (well, the Cessna 310 doesn't have the right >number of tanks or the right fuel capacity, and the Cessna 182 has a >172 gauge that goes only as high as 28 gal_us/tank, but I'm working on >it). No more non-stop, transpacific flights on autopilot. COOL , Great :-) But we need an overide to ignore fuel consumption so we can do non-stop around the world flights on autopilot. I keep thinking of an old post by Oliver where he couldn't get to his machine because the neighborhood kids were using it to fly FlightGear all the time. They loved it because it was a SIMPLE FlightSim. ie the engines were already started you didn't have to worry about running out of fuel when you crashed you just used the reset menu when a mountain got in the way you just added emergency altitude when you wanted to go faster you hit the accelerator key ect.. This was a while ago and the SIM is much more 'realistic' now but I wonder if it would still have the same appeal as it did to those kids a couple of years ago or if they would consider it another of those 'adult sims' that was too complicated ? IMHO the realism is great but we should also keep the KISS version around. BTW - Nice addition, we needed this :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ANN: Fuel
Jon S. Berndt writes: > > - check whether JSBSim is actually applying the weight for the fuel > > Yes, we are. Look at FGMassBalance.cpp: That's good news. Once you start applying pointmass as well, I can tie it into the property manager and we can set up loads in the plane properly. Yesterday, I tried the FLY! C172R with a full left-wing fuel tank, an empty right-wing fuel tank, and one passenger sitting directly behind the pilot on the left side of the plane. It was an interesting experiment -- I almost lost rudder authority during the initial climb. 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] ANN: Fuel
> - check whether JSBSim is actually applying the weight for the fuel
Yes, we are. Look at FGMassBalance.cpp:
bool FGMassBalance::Run(void)
{
if (!FGModel::Run()) {
Weight = EmptyWeight + Propulsion->GetTanksWeight() +
GetPointMassWeight();
Mass = Weight / Inertial->gravity();
// Calculate new CG here.
vXYZcg = (Propulsion->GetTanksCG() + EmptyWeight*vbaseXYZcg
+ GetPointMassCG() ) / Weight;
// Calculate new moments of inertia here
Ixx = baseIxx + Propulsion->GetTanksIxx(vXYZcg) + GetPMIxx();
Iyy = baseIyy + Propulsion->GetTanksIyy(vXYZcg) + GetPMIyy();
Izz = baseIzz + Propulsion->GetTanksIzz(vXYZcg) + GetPMIzz();
Ixy = baseIxy + Propulsion->GetTanksIxy(vXYZcg) + GetPMIxy();
Ixz = baseIxz + Propulsion->GetTanksIxz(vXYZcg) + GetPMIxz();
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ANN: Fuel
> - check whether JSBSim is actually applying the weight for the fuel I believe we are. I'd be surprised if we are not. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] ANN: Fuel
If you grab the latest SimGear, FlightGear, and base package from CVS, you'll notice that fuel consumption is now working on JSBSim piston-engine aircraft (well, the Cessna 310 doesn't have the right number of tanks or the right fuel capacity, and the Cessna 182 has a 172 gauge that goes only as high as 28 gal_us/tank, but I'm working on it). No more non-stop, transpacific flights on autopilot. Currently, fuel is referenced in the property manager by gallons, but I plan on changing it to pounds when I have a chance. Here is a command-line for a short flight where you don't want to carry around over 300lb of fuel in the C172, and thus put only 10 gal_us (about 66 lb) in each tank: fgfs --aircraft=c172 \ --prop:/consumables/fuel/tank[0]/level-gal_us=10 \ --prop:/consumables/fuel/tank[1]/level-gal_us=10 You can read the fuel-flow gauge to see how many gallons your plane is currently using per hour. When both tanks are empty, the engine will stop (I'll add a splutter effect some day), so don't let that happen -- 20 gal_us should still be good for over two hours' flying. By default, neither the C172 nor the C182 starts with a full tank. Coming changes: - use lb rather than gal_us for fuel levels - add the ability to select feed tanks for each engine - check whether JSBSim is actually applying the weight for the fuel - modify JSBSim to clamp fuel levels at tank capacity, to discourage accidental cheating - bug someone until they make new, higher-capacity fuel gauges for the C182 and C310 - fix the EGT values reported by JSBSim's FGPiston class (they're too high) 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] Re: BUG: option --tile-radius missing
Melchior FRANZ writes: > >* Curtis L. Olson -- Saturday 19 January 2002 14:25: >> * Melchior FRANZ writes: > >> > I asked for --tile-radius, because I don't get enough tiles if I >> > fly at good visibility (--fog-disable or hitting 'Z' a few times). >> > And then it would be nice to see more than just one square when >> > I take 'satellite images', i.e. when I look down from the carpet >> > at high altitude. ;-) >> >> Just specify a large enough --visibility= option to satisfy your >> needs, or while flying push out the visibility. > >Huh? Increasing the --visibility is what makes the problem worse and >more obvious. > > > >> Right now flightGear >> only schedules tiles for loading when you cross a tile boundary (so if >> you increase visibility while the sim is running, then press F2 to >> manually rescedule any new tiles that are needed.) > >That doesn't help. There are still too few tiles shown when flying at >high altitudes with good visibility. Lots of white areas that are >updated too late. But it seems that I am the only one with this >problem, so forget it. :-) Try increasing the far_clipping plane This is set in src / Main / main.cxx / fgRenderFrame() search for ssgSetNearFar() FWIW I moved the far plane WAY BACK in order to simulate the satelite views on the 'snapshot page' :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] msvc6 - 0.7.9 release
Curtis L. Olson writes:
>
>One thing I've noticed (from the magic carpet mode) is that if you
>call geo_direct_wgs_84() with zero distance and zero direction
>(i.e. zero velocity) you don't get *exactly* the starting lat/lon back
>because of numerical precision issues. This is not a big deal at
>higher velocities, but is a problem at very slow velocities.
Good Point
lets see 1.0e-6 degrees should be close enough for 'government work'
a minute is 2000 meters and there are 60 minutes in a degree so
1.0*e-6 degrees is around 10 cm
so I guess one could always check
somthing like
my_geo_direct( &new_lat, &new_lon, lat, lon. dir, dist )
static double old_lat = 1000;
static double old_lon = 1000;
#define CLOSE_ENOUGH 1.0e-6
if( fabs(old_lat-lat) < CLOSE_ENOUGH &&
fabs(old_lon-lon) < CLOSE_ENOUGH ) {
geo_direct_wgs_84(new_lat, new_lon lat, lon)
} else {
new_lat = lat;
new_lon = lon;
}
old_lat = new_lat;
old_lon = new_lon;
}
FWIW for those who want REAL ACCURATE placement at small
scale I ALWAYS reccommend doing everything in XYZ on a local
plane then converting your positions into 'spherical space'.
This will work for distances of up to 'several' miles with no noticeable
loss in accuracy due to differences between chord and arc distance
Now how small is epsilon ?
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: BUG: option --tile-radius missing
I am not one of the developers but I would like to say that you are testing an extreme situation. It is important to test these extremes because that is where bugs tend to show there faces. The question then becomes is this a face of a bug that really exists in the normal range or is it a bug that only exists out beyond the normal range. I guess this is a my geeky way of saying thanks everyone that works both make FlightGear and everyone tests it to make it better I really like this program, THANKS. Charles Puffer PS: Thanks to those people that helped me get the CVS download and build working. > -Original Message- > From: Melchior FRANZ [mailto:[EMAIL PROTECTED]] > Sent: Saturday, January 19, 2002 11:13 AM > To: [EMAIL PROTECTED] > Subject: [Flightgear-devel] Re: BUG: option --tile-radius missing > > > * Curtis L. Olson -- Saturday 19 January 2002 14:25: > > * Melchior FRANZ writes: > > > I asked for --tile-radius, because I don't get enough tiles if I > > > fly at good visibility (--fog-disable or hitting 'Z' a few times). > > > And then it would be nice to see more than just one square when > > > I take 'satellite images', i.e. when I look down from the carpet > > > at high altitude. ;-) > > > > Just specify a large enough --visibility= option to satisfy your > > needs, or while flying push out the visibility. > > Huh? Increasing the --visibility is what makes the problem worse and > more obvious. > > > > > Right now flightGear > > only schedules tiles for loading when you cross a tile > boundary (so if > > you increase visibility while the sim is running, then press F2 to > > manually rescedule any new tiles that are needed.) > > That doesn't help. There are still too few tiles shown when flying at > high altitudes with good visibility. Lots of white areas that are > updated too late. But it seems that I am the only one with this > problem, so forget it. :-) > > m. > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6 - 0.7.9 release
"Curtis L. Olson" wrote: > > Norman Vine writes: > > Christian Mayer writes: > > > > > >Norman Vine wrote: > > >> > > >> Christian Mayer writes: > > >> > > > >> >Norman Vine wrote: > > >> >> > > >> >> Well if you just wanted to drift with the wind and be 'cheesy' > > >> >> you could use the simgear direct geodetic solver to get a new lat lon > > >> >> based on current position speed and course > > >> > > >> int geo_direct_wgs_84 ( double alt, double lat1, double > > >> > > >> Need anything else ?? > > > > > >Thnks, that should do the job. > > > > The 'Brakes' could work as a simulated 'tethering device' < anchor > > > while on the ground :-) > > One thing I've noticed (from the magic carpet mode) is that if you > call geo_direct_wgs_84() with zero distance and zero direction > (i.e. zero velocity) you don't get *exactly* the starting lat/lon back > because of numerical precision issues. This is not a big deal at > higher velocities, but is a problem at very slow velocities. Thanks, I'll take care of that (although they are used to race balloons aren't that fast...) 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
[Flightgear-devel] Re: BUG: option --tile-radius missing
* Curtis L. Olson -- Saturday 19 January 2002 14:25: > * Melchior FRANZ writes: > > I asked for --tile-radius, because I don't get enough tiles if I > > fly at good visibility (--fog-disable or hitting 'Z' a few times). > > And then it would be nice to see more than just one square when > > I take 'satellite images', i.e. when I look down from the carpet > > at high altitude. ;-) > > Just specify a large enough --visibility= option to satisfy your > needs, or while flying push out the visibility. Huh? Increasing the --visibility is what makes the problem worse and more obvious. > Right now flightGear > only schedules tiles for loading when you cross a tile boundary (so if > you increase visibility while the sim is running, then press F2 to > manually rescedule any new tiles that are needed.) That doesn't help. There are still too few tiles shown when flying at high altitudes with good visibility. Lots of white areas that are updated too late. But it seems that I am the only one with this problem, so forget it. :-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] msvc6 - 0.7.9 release
Norman Vine writes: > Christian Mayer writes: > > > >Norman Vine wrote: > >> > >> Christian Mayer writes: > >> > > >> >Norman Vine wrote: > >> >> > >> >> Well if you just wanted to drift with the wind and be 'cheesy' > >> >> you could use the simgear direct geodetic solver to get a new lat lon > >> >> based on current position speed and course > >> > >> int geo_direct_wgs_84 ( double alt, double lat1, double > >> > >> Need anything else ?? > > > >Thnks, that should do the job. > > The 'Brakes' could work as a simulated 'tethering device' < anchor > > while on the ground :-) One thing I've noticed (from the magic carpet mode) is that if you call geo_direct_wgs_84() with zero distance and zero direction (i.e. zero velocity) you don't get *exactly* the starting lat/lon back because of numerical precision issues. This is not a big deal at higher velocities, but is a problem at very slow velocities. Curt. -- Curtis Olson Intelligent Vehicles Lab 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] Changes in SimGear
Christian Mayer wrote: > > Hi, > > is there a reason why SimGear/misc/zfstram.hxx was changed from > > #ifdef HAVE_ZLIB > # include > #else > # include > #endif > > to > > #include Apart from fixing all occurances of the single #include FGFS complied staight away under MSVC!! (If I'd have a Champange bottle I'd open it). But there are still the old runtime problems :( (JSBsim #NAN and LaRCsim won't let me start the engine) 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
[Flightgear-devel] Floating Point Exceptions
I've been trying to reproduce the reported problem in FGInitialCondition and would like to have floating point exceptions enabled to do that. The trouble is that I can't seem to get it to work like I expect. On linux, if I either the method in src/Main/main.cxx: fpu_control_t fpe_flags; _FPU_GETCW(fpe_flags); fpe_flags &= ~_FPU_MASK_IM; // invalid operation fpe_flags &= ~_FPU_MASK_DM; // denormalized operand fpe_flags &= ~_FPU_MASK_ZM; // zero-divide fpe_flags &= ~_FPU_MASK_OM; // overflow fpe_flags &= ~_FPU_MASK_UM; // underflow fpe_flags &= ~_FPU_MASK_PM; // precision (inexact result) _FPU_SETCW(fpe_flags); or that defined in fenv.h: feenableexcepts(FE_ALL_EXCEPT) I'll get an exception for float a= 3/0 but *not* for float a=3/0.0 even though both div by zero and overflow are enabled, AFAICT. Does anyone understand what's happening here? -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Changes in SimGear
Hi, is there a reason why SimGear/misc/zfstram.hxx was changed from #ifdef HAVE_ZLIB # include #else # include #endif to #include ? As ZLIB isn't standard (perhaps except on Linux) it's great to have the fallback to the supplied version. And adding the additional include directories to ZLIB and probably Metakit (dunno as my compilation stopped that early) isn't my idea of a clean compilation. 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] msvc6 - 0.7.9 release
Christian Mayer writes: > >Norman Vine wrote: >> >> Christian Mayer writes: >> > >> >Norman Vine wrote: >> >> >> >> Well if you just wanted to drift with the wind and be 'cheesy' >> >> you could use the simgear direct geodetic solver to get a new lat lon >> >> based on current position speed and course >> >> int geo_direct_wgs_84 ( double alt, double lat1, double >> >> Need anything else ?? > >Thnks, that should do the job. The 'Brakes' could work as a simulated 'tethering device' < anchor > while on the ground :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6 - 0.7.9 release
Norman Vine wrote: > > Christian Mayer writes: > > > >Norman Vine wrote: > >> > >> Well if you just wanted to drift with the wind and be 'cheesy' > >> you could use the simgear direct geodetic solver to get a new lat lon > >> based on current position speed and course > > > >The drifting is moddeled correctly and returnes me a "displacement" in > >meters in the north-south and east-west axis (so it'S easy to convert > >that to a direction and a distance). So all I need is a function that > >takes the current position in WGS84 and my displacement and > >returns me a new WGS84 position. > > Exactly > * @param alt (in) meters -- current altitude above sea-level > * @param lat1 (in) degrees - current latitude > * @param lon1 (in) degrees - current longitude > * @param az1 (in) degrees - course in degrees > * @param s (in) distance in meters - distance in degrees > * @param lat2 (out) degrees - new latitude > * @param lon2 (out) degrees - new longitude > * @param az2 (out) return course in degrees - course back to starting > location > */ > int geo_direct_wgs_84 ( double alt, double lat1, double lon1, double az1, > double s, double *lat2, double *lon2, double *az2 ); > > Need anything else ?? Thnks, that should do the job. 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] Re: Re: BUG: option --tile-radius missing
Melchior FRANZ writes: > I asked for --tile-radius, because I don't get enough tiles if I > fly at good visibility (--fog-disable or hitting 'Z' a few times). > And then it would be nice to see more than just one square when > I take 'satellite images', i.e. when I look down from the carpet > at high altitude. ;-) Just specify a large enough --visibility= option to satisfy your needs, or while flying push out the visibility. Right now flightGear only schedules tiles for loading when you cross a tile boundary (so if you increase visibility while the sim is running, then press F2 to manually rescedule any new tiles that are needed.) Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab 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] Breaking OpenGL's hold to ease debugging
Erik Hofman writes: > >Well, since plib is claiming Irix compatibility but obviously, but >doesn't apply my patch I drew my own conclusions. >I concider including my patch just as a way to have more time >to work on >SDL because the audio part of plib breakes about every rule of >computer controlled sound processing. I knpw Steve used to check PLib on Irix at work but it could be that he doeb't anymore. >1. it doesn't handle endianess correct (if the sound files from >FlightGear were 16-bit I can't even use them!) >2. it doesn't handle singed/unsigned data correct (in fact the data is >converted to the right format just prior to storing it in the buffer >instead of at load time). >3. it uses a single audio buffer, instead of the commonly accepted >dubbel buffering principle. > >Changing all this requires a complete rewrite of the audio >stuff, while there are better alternatives. (saves a lot of time you know). Use your time as you best see fit :-) My guess is that we could write a wrapper class that used either of SDL, OpenAL or PLib quite easily. As I said earlier this is a rather low priority for me as I can't even hear any of this on any of my nachines and would probably just mute it if I could :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Re: BUG: option --tile-radius missing
I asked for --tile-radius, because I don't get enough tiles if I fly at good visibility (--fog-disable or hitting 'Z' a few times). And then it would be nice to see more than just one square when I take 'satellite images', i.e. when I look down from the carpet at high altitude. ;-) m. PS: diff -u -3 -p -r1.1 fgfs.1.in --- fgfs.1.in 15 Jan 2002 21:33:24 - 1.1 +++ fgfs.1.in 19 Jan 2002 09:44:43 - @@ -298,9 +298,6 @@ Specify a starting date/time with respec .BI "--start-date-sys=" ":mm:dd:hh:mm:ss" Specify a starting date/time with respect to your local system time. .TP -.BI "--tile-radius=" "n" -Specify tile radius. Valid values are 1 - 4. -.TP .B "--time-match-local" Synchronize time with local real-world time. .TP ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Breaking OpenGL's hold to ease debugging
Norman Vine wrote: > Erik Hofman writes; > >>I've twice committed a patch wich gets audio (sort of) working >>for Irix >>(audio realy is crap in plib anyway) but it didn't get >>included, without >>a reason, without any notice. >> > > Erik > > Apologies for not checking up on your patch > > I just assumed that it got included by one of team that > uses the sound library. FYI none of my machines even > have a sound card so I generally just ignore the SL discussions. > > If you resubmit your patch against the current PLib CVS tree > but with the original PLib names rather then with case changes > I will make sure that it, or its functional equivalant, gets included > in Plib before the next relaease. I don't get this part. You mean the fact that I changed from alSetChannels to ALsetchannels ? This has something to do with an API change from SGI. The latter is an earlier API for sound stuff in Irix, but the I can't even get it to work with the first (the later API) because of some obscurities. Okay, I'll sent you a patch which will get sound (sort of) working. Sort of because the only way to get sound working on Irix is throw away half of the buffer data every time ... > FWIW - If I were to say the heck with projects that didn't accept > my patches I would gave left FlightGear a LONG time ago. > ie. I sent Curt my imageServer patch back in August and never > heard anymore about it until yesterday :-)) Well, since plib is claiming Irix compatibility but obviously, but doesn't apply my patch I drew my own conclusions. I concider including my patch just as a way to have more time to work on SDL because the audio part of plib breakes about every rule of computer controlled sound processing. 1. it doesn't handle endianess correct (if the sound files from FlightGear were 16-bit I can't even use them!) 2. it doesn't handle singed/unsigned data correct (in fact the data is converted to the right format just prior to storing it in the buffer instead of at load time). 3. it uses a single audio buffer, instead of the commonly accepted dubbel buffering principle. Changing all this requires a complete rewrite of the audio stuff, while there are better alternatives. (saves a lot of time you know). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
