* David Megginson -- Wednesday 26 June 2002 03:10:
I now think that was a mistake, since people probably want
their own, local, customized .cvsignore files if they want any at
all.
Huh?? You think that everybody should maintain his own .cvsignore
files now? They are supposed to list all
Andy Ross writes:
Norman Vine wrote:
I think that you will find that inorder to get 'high quality' fonts
one needs to use a vector based font directly. The only problem in
doing this is that the polygon count goes up considerably.
Have you tried the antialiased fonts in KDE, WinXP or recent
I don't mind either way.
I have found it generally useful to have them provided, and have wished the plib would
do the same (for .deps directories, in particular).
However, I have only ever worked on small patches, never adding files, so I have never
needed to take note of the ? and unknown
[EMAIL PROTECTED] wwrites:
I have found it generally useful to have them provided, and
have wished the plib would do the same (for .deps directories,
in particular).
FYI
the FlightGear 'configure' is designed to be able to be run in
a directory other then then the CVS source tree.
This has
FYI
the FlightGear 'configure' is designed to be able to be run in
a directory other then then the CVS source tree.
That sounds well worth a try. Thanks.
This has several advantages amongst them keeping the source
tree MUCH cleaner :-)
And being able to keep a debug build and a release
Personally, I agree with Fred. The number of people who will actually
be using a custom cvsignore will be far fewer than those of us who will
not.
Can you make your custom cvsignore read-only so cvs can't stomp on it?
* [EMAIL PROTECTED] (Frederic BOUVIER) [2002.06.26 07:09]:
Yes, but people
Cameron Moore writes:
Personally, I agree with Fred. The number of people who will actually
be using a custom cvsignore will be far fewer than those of us who will
not.
That seems to be the consensus -- I won't remove them.
All the best,
David
--
David Megginson, [EMAIL PROTECTED],
Andy Ross writes:
* For safety. The A-4 had automatic slats that were retracted by
aerodynamic force -- they dropped automatically at low airspeeds and
high AoA's. On the ground, they just hung open. This was a great
idea for maintenance purposes, but left open the possibility that
that is simple and effective. I've always thought it would be kind of
fun to impliment something like this on an R/C model, not that the
typical R/C model would need them ...
I once saw an F-4 with controllable slats - they weren't automagic though.
The Bf-109 and Me-110 has aerodynamic
Andy Ross writes:
I should explain the problem a little better. What's happening is
that there is no place to put a normal vector in the .ac file. The
plib loader thus has to generate its own normals by averaging the
normals of each polygon attached to a vertex. For vertices that are
On Wed, 2002-06-26 at 14:08, Curtis L. Olson wrote:
Andy Ross writes:
* For safety. The A-4 had automatic slats that were retracted by
aerodynamic force -- they dropped automatically at low airspeeds and
high AoA's. On the ground, they just hung open. This was a great
idea for
On Wed, 2002-06-26 at 14:08, Curtis L. Olson wrote:
The helio courier also has this feature. The leading edge slats are
split so you have two per wing ... four total acting independently of
each other. Depending on a variety of factors, each of the four could
deploy/retract at a
Ryan Larson writes:
I can get hires photos of a Warrior, Archer, Arrow, Grumman Tiger,
Beechcraft Sierra, C182, C172R, C172RG, Mooney 201, Saratoga II and possibly
an Aztec F.
I love my new flying club!
What do we have and what do we need? Would it also be helpful to get hires
photos
On Wed, 2002-06-26 at 15:15, Curtis L. Olson wrote:
On Wed, 2002-06-26 at 14:08, Curtis L. Olson wrote:
The helio courier also has this feature. The leading edge slats are
split so you have two per wing ... four total acting independently of
each other. Depending on a variety of
Setting all the view offsets to 0 I was able to prove that the
position/rotation matrices generated on the model and the camera are
numerically identical. Here's a sample from the dump:
POS Aircraft
0.823776 -0.150286 -0.546632 0.00
0.468893 0.722572 0.507965 0.00
0.318641 -0.674762
Jim Wilson writes:
Setting all the view offsets to 0 I was able to prove that the
position/rotation matrices generated on the model and the camera are
numerically identical. Here's a sample from the dump:
POS Aircraft
0.823776 -0.150286 -0.546632 0.00
0.468893 0.722572 0.507965
Jim Wilson [EMAIL PROTECTED] said:
This tells me the problem is most likely in plib, or at least plib
is where we send these numbers.
On further investigation, it appears that this is almost certainly due to
normal variation in fdm position and orientation output. The variations are
ace project writes:
In my previous mail (Multplayer efforts ?) We asked
for the status on multiplayer-capabilities. We
received responses that suggested that such an engine
was not maintained for a while.
We ourselves could use the engine for adding NPC to
the project, but thats still a
Jim Wilson writes:
On further investigation, it appears that this is almost certainly due to
normal variation in fdm position and orientation output. The variations are
probably correct, but the way 3D rendering works you get what appears to be a
jump when a pixel boundry is crossed. This
Jim Wilson wrote:
On further investigation, it appears that this is almost certainly due to
normal variation in fdm position and orientation output.
This theory doesn't work though. Think about it: in cockpit mode, the
orientation of the aircraft is bolted to the FDM orientation. If
the FDM
Curtis L. Olson wrote:
It seems strange that everything else in the cockpit and 3d model of
the aircraft is perfectly stable and only this one instrument is
jittery.
Actually, the whole cockpit is jittering. The ball just has more
high-frequency information to catch your eye.
The panel
Jim Wilson writes:
Curtis L. Olson [EMAIL PROTECTED] said:
It seems strange that everything else in the cockpit and 3d model of
the aircraft is perfectly stable and only this one instrument is
jittery.
That's an optical illusion. Turn off the panel and you'll see that the whole
David Megginson wrote:
1. Can you post a copy of your modified base-package files
(a4-yasim-set.xml and a4-blue.xml)?
The -set files don't require any significant changes -- just remove
the panel entries and that's it. The model files for the A-4 and
172 are attached. All they needed is a
23 matches
Mail list logo
