Frederic Bouvier wrote:
Was this in PLIB 1.6, again? The alpha transparency is fine using the CVS
I am using the CVS plib and I am seeing this bug.
That's interesting -- is anyone else seeing this problem?
All the best,
David
___
Flightgear-devel
Roy Vegard Ovesen wrote:
Am I being ignored? I don't hope so because I think that the changes
I've made makes the GPS module quite usefull for navigation.
No -- apologies. I typically juggle 30-100 active items in my INBOX, aside
from the 500-1000 spams I receive every day. Patches, bug
Frederic BOUVIER wrote:
I don't know for the original bug reporter, but I am using Windows and NVIDIA
if it is of any importance.
That could matter -- I'm using Linux and NVIDIA. Do you have trouble with
transparencies anywhere else? Do other people using Windows and NVIDIA see
a white
Melchior FRANZ wrote:
All needles are OK. The only bug that I see is the non-transparent
attitude 'needle': http://members.aon.at/mfranz/pa28.jpg
Yes -- I have that problem as well -- it has something to do with drawing order.
All the best,
David
___
Frederic BOUVIER wrote:
Another thing that I noticed about the pa28 panel was the plane in the
TC was not transparent where it should be. The rgb file did have an
alpha channel but because the file was only 256 colors the alpha channel
was not transparent in FlightGear. It was OK when I opened it
Melchior FRANZ wrote:
No. plib has a bug: it doesn't recognize grayscale images with alpha layer yet.
See ssgLoadSGI.cxx:301, where the alpha information is wrongly written to the
blue layer, while the alpha layer is disabled. :-]
Ah -- that explains what's going on here. I had thought that the
Jim Wilson wrote:
Last October I updated the 3D model howto and it still hasn't made it to the
web page. The page was way out of date then, and since Erik has added even
more updates. It wouldn't be such a big deal but there's a few important time
saving items in there. And someone new would
I've bound Ctrl-R to the radios dialog. I imagine that this will be a very
frequently-used command, especially for aircraft that do not have
fully-interactive radios yet.
All the best,
David
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Vivian Meazza wrote:
I've bound Ctrl-R to the radios dialog. I imagine that this
will be a very
frequently-used command, especially for aircraft that do not have
fully-interactive radios yet.
Is that hard coded? I was literally in the process of binding R/r for seat
raise/lower. Rather
Martin Spott wrote:
This aircraft gets really nice.
Thanks. The big breakthrough was my finally learning to use Blender to make
the textures (such as the panel plastics and screws) as well as the geometry
-- using a good 3D modeller with a bit of lighting can make even a
ham-fisted dolt like
I'm struggling a bit with the best way to implement text for the new
(3D-capable) animation code in FlightGear. Plib's current approach seems
suboptimal -- it uses textured fonts (good), but instead of adding the text
directly to a scene graph, it requires a separate drawing pass for it (bad).
David Luff wrote:
I'll second that - it really is good. It looks really good, and at high
resolutions the frame rate is much better than the default - I've seen 60
(pa28) vs. 30 (c172) at some locations and resolutions.
The old (2D) panel code seemed to be the real killer, since I'm using much
Martin Spott wrote:
As the next step you probably might want to sell your Warrior in favour
of an Archer :-))
In retrospect, I wish I'd bought an Archer, since the cost of ownership is
virtually identical, but there's a bit more power and useful load when you
need it. On balance, though
Andy Ross wrote:
Honestly, I think you might be fooling yourself on the 2D/3D
performance issues. There's no secret sauce in ssg that makes it
faster; my guess is that the existing 3D cockpits are faster than the
2D ones because they use fewer and smaller textures, and do less
animation of the
Martin Spott wrote:
We don't have two-seaters with gyros at our flight school ;-)
- except the turn indicator - and we need at least dual NAV/COM as well
as an ADF and DME for IFR flight in Germany. Everything below is not
allowed for IFR.
Fuel costs don't help, obviously, but they're a
Norman Vine wrote:
My not so WAG is that the newer code draws MUCH less then the old approach.
i.e. All of the 2D Panel was drawn as was all of the scenery that it obscured.
In the new approach SSG is clipping those instruments not seen and the occluded
scenery is not drawn. Note this
Norman Vine wrote:
Ah... OK but keep in mind you are still drawing all of the Panel even if it is not
all in view, this includes all of the 'state changes' taking place in the 2D code that
aren't necessarily happening in the 3D code and SSG might also be smart enough
to optimize some of these
Jim Wilson wrote:
One interesting thing I picked up on that didn't occur to me before: it seems
that the translucent prop disk object ends up costing 2-3 fps while in the
cockpit view. I wonder if it is worth the cost.
I don't think that we need any prop disk at all for cruise RPMs -- the
Roy Vegard Ovesen wrote:
I too, experienced this, no needles in the instruments. I use a NVidia
card under Cygwin. After installing the cvs version of plib, the needles
appeared (I used to have plib 1.6.0).
Ah, yes -- the last official PLIB version has a bug (I can hardly consider
it a
Jim Wilson wrote:
For the time being though, I propose that we try to get this default angle to
a higher value. From my testing 61 degrees seems to be a good number. 61
degrees means that a 6 sided cylinder will be smoothed. Anything less (e.g. 4
or 5 sides) will be sharp sided. Many of the
Melchior FRANZ wrote:
The FlightGear project has provided KDE with input/output filters
for SGI images (*.rgb, *.rgba, *.bw, *.sgi). This enables every
KDE application that deals with graphics to load and save this
format, so editing textures is now possible with kpaint, kolourpaint,
and
Vivian Meazza wrote:
We seem to have jumped into something without really thinking it through.
Pity. We need to implement something like the AC3D 'crease' sooner rather
than later.
Actually, what we need is a proper graphics format that specifies per-vertex
normals. What we have now is a
Melchior FRANZ wrote:
For the graphics *editors* (kpaint, kolourpaint, krita): no, not nearly.
They are all still very basic. (On the other hand, any of these is a lot
better than gimp for drawing simple things like rectangles and circles,
which gimp just doesn't grok without external module
Erik Hofman wrote:
Silently ignore texture files that are not present.
How about putting out a warning at a very low priority level, so that people
can debug problems if they need to?
All the best,
David
___
Flightgear-devel mailing list
[EMAIL
Erik Hofman wrote:
There was a developer who had an almost finished 3d model of the
Spitfire once. I have no idea why it never showed up.
I have a copy of his unfinished model, if anyone wants it.
All the best,
David
___
Flightgear-devel mailing
Vivian Meazza wrote:
That could be useful. Could you let me have a copy?
I'll send it via private e-mail. Also, for anyone interested in the
Hurricane (the Spitfire's weaker and lesser known sibling, but also the
plane that did the real bulk of the fighting in the Battle of Britain), here
is
Lee Elliott wrote:
Certainly, it was an excellent a/c but as you say, it's contribution in the
BoB, where it was only present in very small numbers, was far out-weighed by
the Hurricane.
I wouldn't say very small numbers -- I think that the ratio was about 2:1
for Hurricanes to Spitfires.
Dave Perry wrote:
I completed my biennial today in a c172. Completed 2.6 hours of dual
and an evening of ground school this week. As I said, the last time I
was current was in 1978. The FARs and airspace have change a lot. I
never complete my instrument rating and I will be doing this
I've just added an EGT (exhaust gas temperature) gauge to the pa28-161
model, and it showed up another YASim engine issue (apologies to Andy for
posting only about the problems -- the model flies beautifully for the most
part).
With the engine running at full blast, YASim sets
Vivian Meazza wrote:
Do you experience the same ?
http://weather.noaa.gov/weather/current/EDLN.html
You don't have permission to access
/weather/current/EDLN.html on this server.
the same with KSFO and other airports,
The whole system's down, since this fails as well:
Matthew Law wrote:
Is it usual to make the approach or initial climb-out with the mixture
set full rich and prop fine in your aircraft? I'm just wondering
because it's part of the downwind and pre-take off checks for the
aircraft I fly (although I skip over the prop check because it's not
David Megginson wrote:
Like the Archer, the Warrior has a fixed-pitch prop. You have to go up
to the Archer (or the now-discontinued Pathfinder) to get a CS prop on a
PA-28.
For go up to the Archer, read go up to the Arrow.
All the best,
David
Ryan Larson wrote:
For landing it is advisable to make sure that your mixture is rich
enough to do a go around with full power.
Unless you choose to do overshoots pushing forward both levers (or knobs, in
a Cessna). I still go to full rich for descent and landing, but it
certainly doesn't do
[This posting is directed primarily at YASim's daddy, Andy Ross, but I'll be
interested in hearing from others as well.]
1. Engine Idle
--
I've been spending a bit of time on the PA-28 model in YASim, and one
problem is that the engine idles far too fast sitting still on the ground
Andy Ross wrote:
I'm not quite sure what convincing values for these properties would
be. The pressures are pump-driven and are, or should be, static under
normal conditions, right?
Not quite. First, I think that the main pumps run off the accessory drive
(I'll have to check), so they will be
Jim Wilson wrote:
If you had an oil-pressure-psi-idle and oil-pressure-psi-maxrpm property you
could then interpolate something reasonable. Oil-temperature could be hacked
up from a normal maximum and some combination of rpm, time and outside temp.
I'm not sure about fuel-pressure. Is that
Jon Berndt wrote:
If neither of the two (YASim and JSBSim) are appropriate for your
expectations, you can code a special flight model in C within LaRCSim or
perhaps set up a special model in UIUC-LaRCSim, although I am not very
familiar with that.
Right, but that's roughly equivalent to writing
Jon S Berndt wrote:
Good point. I was just pointing out that sometimes code changes are
required for special needs, such as in the icing studies done using
UIUC-Larcsim. I would think we ought to be able to model a paraglider
within JSBSim as it is, currently, but I haven't had time to think
Erik Hofman wrote:
The clouds are moving in the right direction at the right speed. I've
checked again this today. The problem must be somewhere else.
Are you sure that they're not moving relative to the aircraft, instead of
relative to a fixed point on the ground?
All the best,
David
Lee Elliott wrote:
I really want 2D instruments for fdm development testing.
Fine if it's disabled by default, but it's a quick and easy way to both get
accurate real-time display of data and control the various system
parameters...
I'm curious -- what, exactly, do you mean? Do you have up
Erik Hofman wrote:
Next time this happens you might want to check the environment settings.
The lowest wind speed is the reported one, the other layers are
generated by fgSetupWinds.
That's probably where things get messed up.
Remember that the wind speed (and cloud speed) is the zero
Lee Elliott wrote:
Ultimately though, I agree that the aim has got to be for a 3D cockpit, with
3D instruments, for proper flying.
That's the unfortunate part of this whole debate -- the confusing names.
Instead of calling it the 2D animation code and the 3D animation code,
we should call it
Arnt Karlsen wrote:
..ahem, _not_; wave lift sometimes cause static clouds over
and downwind of mountain ridges, in some cases you can fly
backwards thru these clouds. ;-)
I'm trying to think this one through. Presumably, you're flying upwind
towards a ridge that has a rotor cloud on its
Roy Vegard Ovesen wrote:
Basically you would move the texture offsets rather than the surface
itself.
Is this possible with 2D instruments too?
As the original author of the 2D instrument code, I *strongly* advise
against building 2D instruments. Since I switched to an all 3D panel in the
plane
Norman Vine wrote:
There will always be a place for a 2D instrument panels
For Instructor panels and as the texture for flat 3D panels
What we mean, Norman, is using the 2D animation-support code instead of the
3D animation-support code. The 3D animation code can still animate a
perfectly flat
Norman Vine wrote:
except a bit of 'time' i.e. the 2D Panel is likely to be a bit faster
due to simpler geometry, esp if your 3D instruments have things
like bezels etc..
You can still use a single textured triangle (or rectangle) with a
transparent background for the bezel with the 3D code if
Roy Vegard Ovesen wrote:
For the FPS Flat Panel Display System that I'm trying to make, a text
feature is almost essential.
Of course. You could do text currently by making a texture for each word
(or letter) and animating them with the 3D code, but integrating plib's 3D
text library would
Erik Hofman wrote:
Modified Files:
radar_misc.rgb
Log Message:
Add support for a storm blib
Excellent.
As far as I know, civilian airliners carry radar that is capable only of
detecting weather, not small things like aircraft. They also use a separate
radar system for ground separation (the
Richard Bytheway wrote:
I noticed that the new 3D instruments on pa28-161 causes my frame rate to
drop to low single digits (2-3 fps) (Windows 2000, Cygwin, Celeron 600,
GeForce2MX). Panning the view so that the instruments are not in view
brings it back up to about 20fps. I cannot remember what
Erik Hofman wrote:
I know that in Europe they recently added a requirement for collision
detection after two civilian aircraft hit each other when the ATC had
given inappropriate directions.
Is that a requirement for TCAS, or for something else in addition to TCAS?
The copilot on one of those
Martin Spott wrote:
Great idea - unfortunately 'fgfs' now dies with a segmentation fault
just a split second after the FlightGear window appears (Linux),
Yes, I was using the wrong executable to test it. Give me about an hour,
and I'll revert if I cannot fix the problem.
All the best,
David
Martin Spott wrote:
The idea is good - don't dump it,
Thanks, but it's going to be too much work for now -- there are some bizarre
interdependencies. For example, FGInterface, the FDM base class that should
know nothing about 3D models, pokes around inside the aircraft model when
the FDM is
Jim Wilson wrote:
Basically I'm thinking about something that utilizes a font texture file in
rgb format that follows a standard layout, (a square grid of ascii positions).
This may appear to be an expensive approach, but it seems to work well with
the 747 models and it could really give the 3D
Curtis L. Olson wrote:
I'm Flying along at 3500' doing about 115 kias. There's a scattered
cloud layer about 800' below me, however, it is outrunning me in the
same direction I'm going. This amount of cloud movement can't be right,
so I assert there is a bug in the cloud movement code
Martin Spott wrote:
I'm not really shure, just guessing but I assume visibility will not be
sufficient with snow. We need to have at least 5000 m ground visibility
in D and 1.500 m visibility in G - I'm not shure if you would comply
with these rules during snowfall,
That's the same as Canada and
Martin Spott wrote:
Oooops, must have missed that in lesson. Probably we didn't touch that
because as a VFR pilot I'm not supposed to fly during snowfall ;-)
I noticed the emoticon, but is that true? Pilots in Canada routinely fly
VFR in light snow, as long as the visibility is sufficient and
David Luff wrote:
Do you have windscreen wipers on a light plane?
You don't really need them in a single, because in flight you have a 200-400
km/hr relative wind blasting the windscreen clear, and even on the ground,
you have the prop blast clearing the window. Frost and fogging are the big
Martin Spott wrote:
Now that I look out of my office window the next question comes up:
When are we going to experience snow in FlightGear ;-))
As far as I learned, rain and snow don't show up in METAR messages as a
weather phenomenon, do they ?
Yes they do. There's a whole series of
Durk Talsma wrote:
Last weekend, I ran across a project on the internet called project AI:
http://www.projectai.com/ which aims at generating realistic AI traffic
paterns for Microsoft FlightSim 200[24]. Basically, the project aims at 1)
creating real-world airline schedule databases; b)
Norman Vine wrote:
This is because GPS positioning is *NOT* acurate with out a ground based
signal to augment it !
It's much better than it used to be before they turned off selective
availability.
The big difference is that GPS accuracy remains roughly constant during any
specific approach,
Erik Hofman wrote:
Sounds good, implement first, optimize later.
The standard Unix developer's rules (from memory):
1. Make it work.
2. Make it right.
3. Make it efficient.
I've worked as a consultant on too many projects where people have done
these steps in reverse, never with a happy
Erik Hofman wrote:
I've worked as a consultant on too many projects where people have
done these steps in reverse, never with a happy outcome. #3 usually
produces code so obfuscated that #2 and #1 become difficult or
impossible.
Yes, I can imagine making it efficient often produces hard to
Curtis L. Olson wrote:
A simple list of id's of metar stations. We can use this list to mark
which airports have corresponding metar data so we don't flood the noaa site
with bogus queries.
It might be a good idea actually to add lat/lon/elev of each station to the
list, and to use it instead
Lee Elliott wrote:
Dunno if we want to get into adding nav sats to the celestial stuff so we know
if they're above the horizon or not:)
If anyone wants to do that, the almanac data for the satellites is published
and freely available (higher-end units and standalone software can predict
Curtis L. Olson wrote:
However, these values are interpolated (and thus overwritten)
constantly. I think these need to be written to the
/environment/config/... tree for all the boundary and aloft layers.
Then when the environment manager reinit() is called these values will
be loaded into
Curtis L. Olson wrote:
I vote for some sort of simple approach that just warps the values when
ever they change. Once we get the nearest station updating working,
then we could do something slightly nicer by interpolating the old/new
values over time so they change smoothly. Personally I
Curtis L. Olson wrote:
But this assumes that the aircraft is properly initialized at ground
level at the station id location when the properties are set.
You don't have to known anything about the station elevation when you set
pressure-sea-level-inHg, so there's no need for the aircraft to be
Erik Hofman wrote:
I notice that the cloud layers are moving. At one point it almost
looked like they were keeping up with my Cessna 172, is that
intentional or did a cloud positioning bug creep in?
The clouds already moved along with the wind for a couple of months, but
since we've only used
Martin Spott wrote:
Are '--wind=' and '--random-wind' exclusive should I be able to add
randmness to my default wind settings ?
For now, they're exclusive.
All the best,
David
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Jim Wilson wrote:
That's great. No doubt that makes even the worst diaper disaster look like a
piece of cake. :-)
As long as he doesn't put dry ice in the diaper pail.
All the best,
David
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Curtis L. Olson wrote:
Hi, quick announcement ... baby! Amelia Esther, 8lbs 1oz, born 6:12am
this morning, less than 1 hour from first contraction to delivery. 12
minutes from arrival at the hospital to delivery. Everyone is doing
good. I'll be pretty much offline for a couple days. If I
Andy Ross wrote:
OK, this feature is checked in. But it *is* using an index currently,
because I don't have a handy hash table available in the Airplane
class. I'll get that fixed eventually. Most planes have no more than
a handful of weight tags, so hopefully the index won't be too
confusing.
In honour of Curt's return to changing diapers, here's an aviation-related
scatological story:
http://www.salon.com/tech/col/smith/2002/10/03/askthepilot13/index.html
All the best,
David
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Jim Wilson wrote:
Since it is likely that the results are the same, and we have the distinct
advantage over a real world GPS because we are running an FDM and have the
velocities, why don't we just use the arctangent method in the gps code and
save a few cycles?
Feel free to tinker. In the
This question is directly mainly at Andy, but others can chime in as well.
I've noticed that the performance of the PA-28-161 is slightly sluggish in
the climb, and I'm wondering if it has to do with weight. The published
performance numbers for this plane (and most others) in the POH assume
Andy Ross wrote:
It wouldn't be hard to get the solver to handle both situations. You
could have a fuel-fraction=... attribute in the approach and
cruise blocks, and a set-weight index=... wgt-lbs=... sub-tag
where you set the weights. Does that sound acceptable?
I can tune the numbers for a
Frederic Bouvier wrote:
Could someone with CVS write access add the -kb sticky tag to these files :
data/Aircraft/Instruments-3d/adf/adf.rgb
data/Aircraft/Instruments-3d/ai/ai.rgb
data/Aircraft/Instruments-3d/alt/alt.rgb
data/Aircraft/Instruments-3d/asi/asi.rgb
I know that the recent long debates on issues like the Visual Reference
Point for outside views have been driving many people crazy, and have caused
some tempers to flare, but there's also a positive side: FlightGear now has
enough developers who know the code that we *can* have long debates
Roy Vegard Ovesen wrote:
The GPS instrument does this in the same way as you suggest (as do most
real gps devices), take a look at the gps.cxx source file to see the
details. I believe the actual formula can be found someplace in SimGear.
But if you are just looking for the true flight path
Jim Wilson wrote:
Any objection to my putting that on the bus in generic-electrical.xml?
Go nuts (that's Canadian for go right ahead).
All the best,
David
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Norman Vine wrote:
I hope that you take into consideration that that is a *very* expensive
function to call !
I think it's on a 1 hz update, but I'd have to go back into the code.
All the best,
David
___
Flightgear-devel mailing list
[EMAIL
I've started work on some 3D panel instruments. You can see them, in
various stages of completion, in the latest CVS version of the pa28-161.
All the best,
David
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Jim Wilson wrote:
Yes it is. I'm probably being really dense, but I can't think of a reason why
it would be important to know what the origin is in fdm coordinates. So long
as position is reported to fgfs at the nose, we should be fine.
Assuming that the model also has its origin at the nose.
Russell Suter wrote:
Don't get me wrong, I'm not saying this is a bad system, I'm just not
sure I agree it
is an industry standard...
The FAA uses positive numbers towards the tail in specifying longitudinal
weight and balance limits in the TCDS; all weight and balance calculations
I've seen
Jon S Berndt wrote:
Given each JSBSim aircraft config file, we will need to add the
AC_VRP ###
entry to each aircraft file.
No, let's not do that -- instead, let FlightGear pass the VRP through the
JSBSim API. That way, we can use different 3D models with the same flight
model.
All the
Jon Berndt wrote:
No, let's not do that -- instead, let FlightGear pass the VRP through the
JSBSim API. That way, we can use different 3D models with the
same flight model.
That _absolutely_ defeats the whole purpose.
I don't see that. What is the benefit of a configurable VRP at all, if the
Martin Spott wrote:
I can't withstand the impression that changing the _camera_ position
didn't lead to the intended success. Take a simple stick and rotate it
around one of its ends. For an observer the phenomenon is still the
same even when he changes his viewpoint.
If you want to rotate the
Jon S Berndt wrote:
JSBSim made a change recently that is likely not yet in FlightGear CVS.
The lat/lon/alt position now reported by JSBSim (CVS) is the position of
the VRP (Visual Reference Point) - i.e. the tip of the prop hub (or
similar nose tip location on non-prop aircraft). As long as
Vivian Meazza wrote:
So put the (visual) model origin at or near the CofG - what's the problem?
Seems to work OK in practice.
It depends on the aircraft. A light trainer like the Piper Cherokee or the
Cessna 172 typically allows only about a foot of variation in the location
of the CG along
Jim Wilson wrote:
That is why the model code does not need to know where the CG is. The 3D
model designer does need to know the FDM origin or reference point or
whatever you want to call the vertex in space at which the FDM reports the
lon/lat/alt of the aircraft. So if she puts the origin of
Jim Wilson wrote:
Yes. In YASim, the 0,0,0 of the fuselage property is the origin. So if ax=0,
ay=0, az=0 is used then the nose is origin in YASim.
It would be nice to be able to specify the point in YASim as well, so we
don't have to physically alter the models. For the PA-28-161, though,
Andy Ross wrote:
I'm not sure exactly what this is for. I can (and probably should)
export the C.G. position for the view code to use appropriately. But
the VRP stuff seems like a double-correction. It's basically
identical to the view center offset stuff, isn't it?
It's the location on the
Jim Wilson wrote:
Actually, it isn't that. It is just the location that the camera points to.
You don't want it pointing at the nose. So add the entry below to the
external views in your xml wrapper that track the plane. The value is the
distance in meters from the FDM reference point (the
Jim Wilson wrote:
I wonder if we can model the broken air vent door on the pilot's side that
blows -35 degC air on my feet when I'm flying in the winter.
It's already there (parameter: --frostbite=mins where mins is number of
minutes before you lose your toes). With that all you need is an old
Andy Ross wrote:
Indeed, the twist assignment for wings looks a little wrong. These
are the twist assignments for the symmetrical left and right wing
segments:
s-setTwist(_twist * frac);
s-setTwist(_twist * Math::sqrt(frac));
It looks like I screwed it up between versions
[EMAIL PROTECTED] DID NOT write:
The message contains Unicode characters and has been sent as a binary attachment.
For anyone keeping track, this spam with Martin's e-mail forged on it came from
ma164090190.user.veloxzone.com.br 200.164.90.190
Does that look familiar to anyone? If so, and
Martin Spott wrote:
Hello David, I like your PA-28 very much, but I can't resist to note
that there is one 'feature' that is really annoying (I must admit that
this word is a bit too strong in this context !):
At least in the outside views the aircraft rotate around its nose.
It's difficult to
Matthew Law wrote:
The bottom line is it isn't just for getting in and out below minimums.
It is a required clearance before you will even be allowed into your
destination if it lies within a class D or E CTR.
From what you posted, UK SVFR sounded like the same thing we have in North
America
Andy Ross wrote:
Probably because of the internal engine friction, I was looking at the
propeller only. What's the right windmilling RPM? I can tune, but
need numbers. :)
The higher the airspeed, the higher the windmilling RPM. Using my very weak
math and physics skills, a fixed 60-inch-pitch
Dave Perry wrote:
I updated plib, SimGear, FlightGear, and the base package from cvs
Thursday evening. Now the 3d model for the default c172 is very
angular. I don't see this on the other models.
Did you blow away any patches you might have added to plib?
All the best,
David
301 - 400 of 2319 matches
Mail list logo
