> > Finally, is now a good time to mention the operating system specific
> > pilot 3D model, with the passenger seats (to the extent available)
> > filled with the 3D models of our other supported operating systems ?
> > All it needs is for the model to have hooks indicating seat positions,
> > an
> > How far should this go? For variable-pitch props, we could something
> > like
> > /engines/engine[n]/prop-pitch-norm
> > and you could see where the governor is keeping the blades and whether
> > they're feathered. That wouldn't be hard to do from JSBSim (which
> > actually knows the pitch
> Is anyone still using this ancient file format? Does anyone have any
> objections to ending support in flightgear for it?
Given we have a converter, and can maintain the converter externally
to FGFS, is there any reason why you cannot do a pipeopen popen()
to use an external that will stream b
> In other world, How can FlightGear
> make the simulation time the same as the real clock time?
> I am a newer. Thank you for your patience.
It asks your computer what the time is, and also asks it what timezone
your computer is located in. It then looks at where your simulated aircraft
is in t
> One idea for the future I had considered was the 'skymap': An
> alpha-chnneled 3D 'overlay' for the terrain showing TMA,
> airways, restricted airspace etc.
Yup. It would be valuable for teaching the Class B areas in the USA too.
> Just a thought, anyway. Maybe in the far future...
I mention
> True, if one actually uses slugs. In practice, one doesn't. What's
> the unit for empty weight? Fuel amounts? Payload? All pounds. Find
> me a reference that gives air density in slugs per cubic foot, or
> pressure in pounds per square foot. If you don't use the consistent
> units consist
> - Capital letters are yellow on black.
> - Lowercase letters are black on yellow
> - '<' and '>' get mapped into arrows.
> - We don't have a symbol for arrows pointing in other directions.
How about '/' and '\' for diagonal exits, '-' for the '<>' doublehead ?
And, now I think about it,
> You have to. How else are you going to support flaperons, as on the
> F-16 and F/A-18, or tailplane control of roll as on the F-15? Not all
> aileron-style surfaces always deflect symmetrically. Another use case
> is spoiler control for roll, as on the Mitsubishi MU-2. Spoilers
> don't even
> > Will we need to do this with flaps, slats, spoilers,
> > elevons, etc.? A left and right component for each one?
> Doesn't that make sense, considering that there are left & right
> components on the real thing?
And, don't you want to be able to try flying the aircraft with the left
flap un
> > I agree in general. I'd suggest the use of -fraction or somesuch
> > instead of -pct if the range is 0:1, as it is for most of these
> > properties currently.
> An earlier suggestion was -n for "normalized", which is probably the
> most accurate (and has the advantage of brevity). Is ther
> Jon Stockill writes:
> > Now, feet, inches, miles, furlongs, etc are another matter :-)
> Why don't we give this thread a rest, then resume it in a fortnight?
> I have half a stone of paperwork to get through first.
0.5 stone = 7 lb = 3.178 kgabout 635 sheets.
Standard
> To be fair, SI isn't the only system that has this property. There is
> another metric system that goes by "cgs" (for centimeter/gram/second
> -- the basic units) with the same property. Those folks talk about
> force in "dynes" and energy in "ergs".
And, before people go off and create C++ c
> Alex Perry writes:
> Hmm, I suppose I really ought to take some consideration of this
> into the CHT model. Are these a manually operated thing?
It depends, of course. On the C172RG, it is a vertical moving lever
just to the right of the elevator trim, with no automation. Newer
> I considered a console warning as well, but then I wondered how many
> people actually pay attention to it? (especially if they are not
> debugging something they know writes to the console)
Oh, they'll pay attention to it. On linux, the flickering is annoying.
On Windows, the users will want
> So my question is: where do I submit a patch? Here on the list, or do I
> mail it directly to one of the FlightGear elders?
If it is a small patch (<200 lines), stick it on the list for the rest of us.
You also need to send the whole file(s) to Curt so he can inspect, bless and
apply to the mas
> > What about cowl flaps?
> All of my experience is with jets, what exactly are cowl flaps?
For aircooled engines, the flaps either constrain the airflow into
the engine compartment, or constraint it coming out of the compartment.
The C172RG has them underneath behind the gear.
Flaps are open a
> Well, leaving them as they are certainly won't be a problem for the
> current developers -- the units for those have been percent for as long
> as I can remember. And percent are non-dimensional, so no units
> indicator is probably just as correct as -pct or -nd or whatever.
How about having a
> There's a CH Products pedal set that a lot of people like. I got to
> try them once, but didn't like them much either. Too close together,
> and the pedals are independantly sprung (not linked into a single
> physical axis), which feels wrong.
You must be thinking of something else. The CH p
Very nice. Please make sure it scales nicely, just by replacing the
panel graphics and hotbutton list, for one axis and three axis modes.
Third axis is autothrottle. Some notes, and additional functions.
> ButtonName - Description of function
RATE - Turn rate, range of +/- 1 standard rate, doe
> I've been wondering for a while - suppose I take a non-force
> feedback yoke, and attach a wheel that actually moved the neutral
> position by moving the end points of both springs backwards or
> forwards, and use this instead of the software trim, would this be a
> reasonably realistic appr
> Alex Perry writes:
> > The position of the elevator is a force balance, consisting of the
> > aero force on the elevator, the aero force on the tab and the muscle
> > force on the yoke.
> I'm still not entirely certain that I understand. I know that you
>
> Curtis L. Olson writes:
> > David, I'm starting to get nit-picky here :-) but one more thing
> > ... the elevator doesn't seem to be responding to elevator trim. In a
> > real life C172 the elevator trim is a little tab on the trailing edge
> > of the elevator that causes the elevator to ac
> > Its possible that it might be necessary to write an FGFlightPlan
> > module as well - can someone tell me whether real life ATC
> > actually knows whats in a flightplan after its been filed or is it
> > simply a case of the pilot just requests what's on his/her flightplan?
> ..this depends
Opportunity for instant fame - the European and especially UK developers?
I gave a talk (about FlightGear) last year; the conference was interesting.
Slightly off-topic, has _anybody_ submitted for LinuxTag's conference yet ?
-
Substitution needed in
FlightGear/configure.in
FlightGear/src/FDM/JSBSim/Makefile.am
RCS file: /var/cvs/FlightGear-0.7/FlightGear/configure.in,v
retrieving revision 1.105
diff -C3 -r1.105 configure.in
*** configure.in24 Feb 2002 19:56:02 - 1.105
--- configure.in
Nope, it isn't in the CVS archive ... someone forgot to check it in ?
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> > There seems to be a vestigial reference to TOWER_VIEW in
> > 0.7.9, but as Michael says, the code section that was in
> > 0.7.8 is no longer there. This would be a useful feature
> > for simulating r/c flight.
> There was never any code to support it; Curt just added it to the enum
> as a
> > We might also need a relative-humidity property. What units should
> > we use? Do the FDMs care about humidity?
>
> The way it would work would be similar to how you posit. You'd get a
> percentage saturation from somewhere (100% in clouds or rain, 20-50%
> for normal days at low altitud
> That's also to be determined. As I mentioned, I'm working from front
> to back. FGEnvironment contains a set of environment information for
> a single place and time. Once we get that working better, I'll add
> FGEnvironmentManager to get the environment information for places
> (and times?)
> Please start with some yasim aircraft and apply parking break.
> Look at skid ball. I thought that it should be in the middle of tube, when
> sitting on runway. but it isn't.
Is your runway flat ?
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
> I experience this phenomenon also at 50 % thust - it's quite pulling as
> much as at full power. Is this still a 'feature' !?
The effect is only proportional to the torque generated by the engine.
Note that this is not the RPM. Torque is proportional to the square
of the difference betwee
> > Is this a 'feature' or is this a bug ? This 'feature' is rather new to me,
> Feature. Perhaps implemented incorrectly. Perhaps not.
On the ones that pull to the left, it's a feature.
On the ones that don't, yet, it's a bug. Does that help ?
> At high power in a steep climb torque will roll
> We have a 'divide by zero' situation in simgear/math/vector.cxx, but I'm
> sure what the right fix is. Here's the offending routine:
Nah.
> double dd = sgdScalarProductVec3(d, d);
> double tmp = ud / dd;
Personally, I'd stick an assert in there that dd must always be positive.
It is
> This could be tight. Right now I'm using 256x256 textures. This could be
> reduced but would require a different approach.
Ok.
> In any case you're looking at
> probably 2-3mb in texture memory over and above what is used now at 16bpp.
Doesn't sound too bad; AGP helps a lot and framerate is
Martin asks:
> From: Alex Perry <[EMAIL PROTECTED]>
> > 8MB + AGP in a RagePro chipset
> UTAH-Glx? I wonder how you would get RagePro running with plain XFree86/DRI?
My understanding is that you have two choices:
(1) port the existing utah driver to DRI ... on your own, o
> Some reuse. I'm running a 16mb Voodoo3 3000. What will you be using?
8MB + AGP in a RagePro chipset
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> http://www.spiderbark.com/fgfs/c172r-tiled-panel.png
> http://www.spiderbark.com/fgfs/c310-tiled-panel.png
Very nice. Do you do enough texture re-use that it'll run well on
low-texture-memory machines ? I'm doing a demo on Wednesday 8-)
Other than that, you need some mini texture fragments
> OTOH getting beyond something fairly simple would probably need
> some sort of time history of key events and some aero data.
Ok, here's one as example. It's the second plane I trained in, after the
first one was intentionally flown acrobatically until the wings failed.
This accident wasn't me
Rick said:
> The ideal, but probably unobtainable, result would be a excerpt
> from the accident investigation report:
>
> 'The aircraft impacted nose down with an angle of approximately
> 83 degrees to the vertical and 3 degrees of bank. There was no
> evidence of rotation about any of the aircr
> Alex Perry writes:
> > I suspect the LaRCSim is the most accurate. It is possible to taxi
> > (carefully) with those winds, but takes considerable planning and
> > operation of the controls to make it work out safely.
David comments:
> The tests were run with the
Christian asks:
> "Curtis L. Olson" wrote:
> > Landing lights: I saw a very convincing implimentation of this in a
> > sim where the ground was a 100% flat plane in all directions and they
> > did their own ground lighting calcs. They used a texture to simulate
> > the imperfections of the lens i
Curt comments:
> Erik Hofman writes:
> > Alex Perry wrote:
> > > I see nothing wrong with a fireball feature ... a PLIB sequenced 3D
> > > animation that gets loaded from a file (if requested by config option)
> > > and triggered to be played by the rising edg
> fgfs --aircraft=c172 --airport-id=KSFO --heading=270 --wind=0@50
> The JSBSim C172 actually takes off, weathervanes in the air, then
> lands again facing north. The LaRCSim C172 flips over, and the UIUC
> C172 starts sliding smoothly sideways. YASim takes the prize for this
> one, since it s
> > I'd move it down the list, but it would be a crowd pleaser.
> > People do ask for it.
> From the crash reports I've read and pictures I've seen, small planes
> tend to snap or crumple rather than explode (often none of the above).
The fire (non-ball) does happen occasionally, but is usually d
> > Norman has resigned from the FlightGear project for now ... :-(
> Bummer
Seconded.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> > Additionally, my script runs on a standard Tom's root boot.
> > http://www.toms.net/rb/ I rest my case.
> Tell us, when you got fgfs running from a floppy disk ... :->
No problem.
Etherboot, LTSP, Utah-GLX is easy to install, but impacts framerate.
The trick is to install FGFS _inside_ LT
> > > > Please note that there is a difference between fgfs's internal
> > > > representation of wind, and the way it is set by the user. As an
> > > > engineer, I am partial to using 'to' vectors internally.
> > > Yup, that is more mathematically correct.
There is nothing mathematical about the
> Think of it this way: a YASim aircraft will be as close to the real
> airplane as the real one is to any other aircraft of the same general
> class. That's good enough for me. And in a lot of situations
> (military aircraft in particular), this is as good as we're going to
> get anyway. There
> Ok, there is something really strange here, probably because things
> were changed without a proper understanding of how everything worked
> together. My mind is fryed at the moment looking at this stuff.
> JSBSim seems to be doing the right thing *except* for at KMYF.
Whatever it was I said t
The current CVS hangs for me when ground started at KMYF, yet is fine at KSFO.
Immediate crash. It's a long way to commute, could we fix that sometime?
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flig
> If I created it with MS software I'd blame them for missing standard
> conformance. However, this was produced with one of standard freeware
> Tex-HTML converters (TeX4HT)...
I use latex2html personally. Anyway, it seems more likely that the file
is missing from the upload. Most of the genera
> Alex Perry writes:
> > > Alex Perry writes:
> > > > * On a G400 card with lots of memory, I'm getting 4fps out-the-box.
> > > > This is down from the high 20s previous versions. It improves
> > > > to 14fps if I get rid of the Tex
That's the same error I have on the C172 at simulator startup. FYI.
> JSBsim C310 crashes the sim on gear retraction.
>
> $PATLA,117.30,119.0,111.80,29.0,266*69
> 182: GEAR_CONTACT 1
> 183: Crash Detected
> 184: GEAR_CONTACT 1
> 185: Crash Detected
> 186: GEAR_CONTACT 1
> 187: Crash Detected
>
> I could bind a toggle for the brakes to the indicator.
> I think it's fairly likely somebody might click on it
Good idea, in any case. However, instead of setting the
brakes, how about configuring the weather to have non-zero
wind directly down the runway, just enough to keep the
aircraft fro
> Sounds like we need to organize a focus group. :-)
Yeah, that's what the conferences are for ... to _prove_ to the
doubting new users that the simulator does actually work ...
> I'm worried though that if the new user goes scooting off down the
> runway at 40 knots before they get a chance to
> Alex Perry writes:
> > Dunno. It was the pre2 prebuilt binary from the Nottingham server ...
Curt asked:
> Is it dumping a lot of console output when it runs?
It was dumping at least the first dozen screenfuls that I'm used to
seeing under Linux ... then I minimized the ba
> Alex Perry writes:
> > * On a G400 card with lots of memory, I'm getting 4fps out-the-box.
> > This is down from the high 20s previous versions. It improves
> > to 14fps if I get rid of the Textures.high directory temporarily.
> > Thus, the decision ma
> I've put up a Cygwin compiled binary of the 0.7.9 pre-release
> candidate up at:
>
> http://www.nottingham.ac.uk/~eazdluf/fgfs-win32-bin-0.7.9pre1.zip
>
> in case anyone with windows but without a compiler wants to test
> it.
* On a G400 card with lots of memory, I'm getting 4fps out-the-bo
One of the original reasons for the preferences file (and heirarchy) is
exactly Christian's point. Last time we had this discussion (or whatever
you want to call it 8-) the conclusion was that the aircraft should either
* Appear on the runway as though told to position-and-hold (which implies
t
> Curtis L. Olson writes:
> > As I understand it, in recent versions of plib, they have fixed the
> > bug/feature that prevented oversized textures from being properly
> > scaled down for voodoo users. So in theory, voodoo owners should
> > still see the textures, but they will be a bit blurr
> > I consider this as a required option for novices - although I might be
> > proven to be wrong. Anyway I'd dare to suggest making running engines a
> > default on startup - knowing that this might be an excellent start for a
> > flame war ;-)))
I hereby deliver the flame war. 8-)
_IF_ we ha
> > > Running FG under cygwin allows the socket output to be set to the
> broadcast address, 192.xxx.xxx.255. But under linux Fg returns an error
> > > that make_client_socket failed for the broadcast address. Looks like
> cygwin is faking it.
> >
> > Not necessarily. Did you declare that to be t
> Alex Perry writes:
> > As of right now, the script that used to ground-start now fails with
> > a terrain intersection error immediately after the aircraft bounces
> > on the gear and then departs to never-never land. A flight-start works
> > ok, except that left cl
> Running FG under cygwin allows the socket output to be set to the broadcast address,
>192.xxx.xxx.255. But under linux Fg returns an error
> that make_client_socket failed for the broadcast address. Looks like cygwin is
>faking it.
Not necessarily. Did you declare that to be the broadcast ad
> so it sounds like it's best to leave the defaults alone and run from
> /usr/local/bin. And should one assume
> that by putting the base in /usr/local/FlightGear/ requires NO argument to
> set the root for fgfs
Err, I've got my base in /usr/local/lib/FlightGear and I don't recall
over-riding any
c++ -DPKGLIBDIR=\"/usr/local/lib/FlightGear\" -g -O2 -L/usr/local/lib -L/usr/X11R6/lib
-o fgfs main.o fg_commands.o fg_init.o fg_io.o fg_props.o fgfs.o globals.o options.o
splash.o viewer.o viewer_lookat.o viewer_rph.o viewmgr.o
../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.a
../../
> Well my talk at Linux.conf.au didn't go all to plan. The talk went okay, but
> the projector decided to kill itself making the demos a little difficult. I
> got to do a demo for the conference dinner though. A lot of people were
> impressed, so we can expect to see a few in fgfs-user's soon.
> The statement in question is this:
> Many pilots have not been made aware that full rudder inputs,
> under certain conditions, can jeopardize the integrity of the
> vertical tail fin and that in some airline modes, rudder
> deflections can be achieved with relatively small pe
> One would think that,
> unlike a Bonanza, a modern commercial transport
> would limit the ability of the
> pilots to damage their own aircraft via structural
> filters and limiters.
WHAT???
Design maneuvering speed is "Va" and is simply and _only_
Va = Vs * sqrt(g load limit)
Where Vs is th
> Anyway, like I said, I'll go with the flow on whatever the consensus is,
> but I would really prefer a situation where rm -rf Aircraft/whatever
> would remove an entire plane. Does it make sense? To me, yes.
I would like every directory to contain a file that lists the relative path
to every ex
http://web.mit.edu/newsoffice/nr/2002/robochopper.html
Their ground station seems to have telemetry but no visualization ...
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> On a slightly different subject, they also did a segment on "aviation
> communities" or something like that. It's basically a community where
> they have taxiways from the neighborhood airstrip up to everyone's
> houses. You could actually land and taxi to your house. That be
> awesome. :-)
> > isn't. It's not a big deal for a linux box to be up this long I know,
> > and I'm not trying to start a big uptime thread, but given our past
> > history of flakiness of service I thought it was worth pointing out.
>
> Well I would've had you beat hands down ;-) if it wasn't for the fact tha
> So, what you are saying is that my having set the visibility to 90
> statute miles was not a good thing? ;) Any ideas as to what I should
> expect for a worst-case visibility? The reason I chose such a large
> visibility is because the fog effect looked, to me, more like fog and
> less li
> checking for gluLookedAt in -lGLU... (cached) no
> checking for gluLookedAt in -lMesaGlu... (cached) no
> checking for glutGetModifiers in -lfreeglut... (cached) no
> checking for glutGetModifiers in -lglut... (cached) no
It's possible that those are static on SUSE, so aren't installed
> Not
> being a pilot, I am sure that may visibility range is set too high
If you want realistic numbers to try (for the US pacific coast) ...
* Set the time to 3pm local and visisility to 6 statute miles.
* Or 9am and 20 statute miles.
* If you want to pretend it's a cold clear sunny day after
> Someone should actually go through all the entries and pick
> appropriate non-texture colors for each material. I thought it would
> be intresting to taket the average of all the pixels in the texture,
> but never got around to seeing how well that would work. But it's
> something you could th
> Alex, what sgi hardware features are you referring to, and are these
> available on any of the machines our developers have access to?
> I'm still not sure what special graphics features sgi provides (that
> something like a mid-hi level geforce card doesn't) that we'd be
> interested in.
I'm
> >>To explain what Erik's talking about: You don't get an appropriate video
> >>card that you can use in an SGI for just $50. 2x 4 MByte Texture RAM to
> >>upgrade an Octane SSI to MXI cost more than $1000 - and you can't use
> >>FlightGear's textured scenerey without TRAM
> > In my last jo
> You don't expect a software rendering 386 to give decent frame rates, do
> you?
Haven't tried that yet, because just the FGFS base is 50MB ... and that PC
only has a 100MB HD. My 486 doesn't do very well, due to software 3D.
If I come across an ISA 3D card spare, I try it ... it might be usabl
> Alex, Christian, Erik? Durk, AFAIK, you will not be in europe then?
Generally, they prefer to have different presenters in successive
years for each project because that makes the talks more interesting.
Having successfully excused myself from consideration 8-) ...
That leaves Christian and Er
> Must search for the 'book' that came with the machine for the actual
> 'card'
> but i remember something like AGP . The driver is the Intel
> 810e Chipset Graphics Driver PV 2.1 (as Alex mentioned) ... I guess the
> on card mem. would be minimal, maybe 2 or 4 MB max. - Must find
> that book! Thi
> Real time plotting is something I've always wanted to do. There is the
> remnant of a socket interface in FGfdmSocket, and it is/was used in
> FGOutput. I actually wrote a small program that accepted data from a JSBSim
> output stream a couple years ago. I haven't seen xoscope. What is it?
http
> From: "Alex Perry" <[EMAIL PROTECTED]>
> > Under Debian, the headers for the compiler are separate from the binaries
> > for runtime. Did you install both parts ?
> yes i've installed all parts from rpm packages I have library libpng.a and
> li
> Alex warns:
> >JSBSim actually works very hard to simulate realistically and uses
> >the processor; with logging turned on, it does significant disk I/O.
> >If you're short of memory and having to swap, the extra disk load
> >can crucify the performance of Windows to keep the application running
> > Geoff:
> > It appears that your machine may not be capable of running FlightGear
> > properly. This stuff should not be happening. ...
> > ... I ran into similar things to what you are seeing a year ago when I
> > had a seriously underpowered machine/display card.
Right.
> More specifically
> Hi Guys!
> Yerstaday i had to reinstall my linux and my second CD from mandrake linux
> distribution was scratched
> so i download missing developers (zlib,jpeg,png) packets from internet in
> rpm format and install them using rpmdrake utility
> but when i run ./configure script i see this resul
> >We can, though -- what kind of a noise should it be?
> Kind of a fluttering noise; lots of burbling.
In high engine power conditions for prop planes, there is another sound
that is due to the prop disk loading being asymmetric when uncoordinated.
The other reason for prop asymmetry is due to a
> Open source software may also be tested, legally, also to
> airworthiness standards. And, by the FAA too.
>
> ..which leaves closed source software behind as, _un-certifiable_.
That's true for various categories of avionics, which have coverage tests,
but not for inspection and training too
> In some ways, it was harder than it would be for a real pilot, since I
> didn't have the peripheral vision or the motion cues (I cannot feel
> when I'm in a slip, for example, or when I'm descending rapidly, and I
> cannot feel any force feedback from the controls).
Don't be too sure; once you'
> From my research on the Web, the C172R default panel configuration
> (and the typical C172R for sale on the Web) comes with a simple GPS
> (not yet modelled), two NAVCOMM radios, ADF, transponder, and
> autopilot (no altitude control). There are two VOR gauges, one of
> which has a glidescope,
> Alex Perry writes:
>
> > > > Disused airfields are fairly common in the UK, can I suggest the
> > > > ability to handle these is something add to the 'to do' list?
> > > Basically, we just need to support closed ("X") runways,
> > More specifically, the DME is not on a stock C172R panel (nor is the
> > MP gauge, which is also gone). We stuck the DME on the C172 panel
> > originally because the C172 was the only plane we had.
> True. I do recall MP on pix of the 172R(G?) Alex flies. That reminds me..
> Does cylinder hea
> I'm not terribly familiar with the airport database code, but I can't
> believe these would be difficult to support. Just make up a few new
> runway textures with big yellow X's on them. The hard part will be
> finding the data for the ancient runway locations. Anyone?
The NOS charting servi
> > Disused airfields are fairly common in the UK, can I suggest the
> > ability to handle these is something add to the 'to do' list?
> Basically, we just need to support closed ("X") runways, then make
> airports where all the runways are closed. CYOW, my home airport, has
> one closed runway
> Could we abandon MetaKit completely please?
> The 2.4.2-32 version which is supplied by SimGear doesn't compiler
> properly. I vote for using David's plain text sulution (at least for now).
I don't recall David's solution.
It seems to me that we're only using MK for doing simple record lookup
> 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 lig
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
> >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.
___
Flight
> 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.
It took me some consistent hassling, too.
> So plib devlopers can do their own business, but I'm moving on.
Don'
401 - 500 of 559 matches
Mail list logo
