Currently, there's a problem with our *-set.xml system for aircraft
selection. If I want to fly the YASim DC-3, say (I love that plane),
then I invoke FlightGear like this:
fgfs --aircraft=dc3-yasim
So far, so good. Now, let's say that someone prefers another 3D model
to my modest effort,
David Megginson writes:
My proposed solution is to add a layer of abstraction to every
*-set.xml file. It will be annoying for John and me, but will make
things simpler for everyone else.
Hmm. On further reflection, this might cause trouble for properties
that are tied, like
David,
It seems to me like it would be *much* simpler to just make a copy of
the dc3-yasim-set.xml file. Say I wanted an American Airlines DC-3:
http://dfw.citysearch.com/E/V/DALTX/0213/06/66/cs1.html
I could make a dc3-aa-yasim-set.xml and repaint your model.
This means one -set.xml
* David Megginson -- Thursday 21 February 2002 15:26:
[...]
This is a little ugly, but ordinary users should never have to see
it. Now, the user can put
-prop:/config/aircraft/dc3-dpm/sim/model/path=Models/dc3-usa.ac
in her .fgfsrc and get a different 3D model for the DC-3 without
I had some tests with 0.7.9 source and today's CVS (_very_ nice panel), with
0.7.9 base package and today's CVS, I tried different airports but the
'feature' is still there: Several models tend to bank to the left when the
stick is in the middle:
c172-larcsim does not
c172 does
c182 does
c310
I had some tests with 0.7.9 source and today's CVS (_very_ nice panel),
with
0.7.9 base package and today's CVS, I tried different airports but the
'feature' is still there: Several models tend to bank to the left when the
stick is in the middle:
c172-larcsim does not
c172 does
c182 does
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 you
Some time ago I recall a dicussion on the correct way to handle
the markings when runways crossed, which I don't recall ever being
definitively decided.
The images at:
http://www.spaceimaging.com/gallery/ioweek/archive/iow093001/iow
093001.htm
clearly show that our present way of simply
From: Alex Perry [EMAIL PROTECTED]
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 ?
Sort of ;-)
I
Martin Spott wrote:
I had some tests with 0.7.9 source and today's CVS (_very_ nice panel), with
0.7.9 base package and today's CVS, I tried different airports but the
'feature' is still there: Several models tend to bank to the left when the
stick is in the middle:
c172-larcsim does
Curtis L. Olson writes:
It seems to me like it would be *much* simpler to just make a copy of
the dc3-yasim-set.xml file. Say I wanted an American Airlines DC-3:
http://dfw.citysearch.com/E/V/DALTX/0213/06/66/cs1.html
I could make a dc3-aa-yasim-set.xml and repaint your model.
Martin Spott writes:
I experience this phenomenon also at 50 % thust - it's quite pulling as
much as at full power. Is this still a 'feature' !?
Angle-of-attack will matter as much as, if not more than thrust. In
fact, if you're using less throttle, you're probably keeping the nose
David Megginson [EMAIL PROTECTED] said:
David Megginson writes:
My proposed solution is to add a layer of abstraction to every
*-set.xml file. It will be annoying for John and me, but will make
things simpler for everyone else.
Hmm. On further reflection, this might cause
On Wednesday 20 February 2002 09:03, you wrote:
Also what video are you use and version of drivers
Geforce2 with NVIDIA_kernel-1.0-2314 compiled locally. Running Debian 2.2
updated to Woody and a custom 2.4.17 kernel from source.
Wm
--
William L. Riley
[EMAIL PROTECTED]
On Thu, 21 Feb 2002 16:13:16 -, D Luff
[EMAIL PROTECTED] wrote:
Some time ago I recall a dicussion on the correct way to handle
the markings when runways crossed, which I don't recall ever being
definitively decided.
The images at:
Curt,
Thanks, this has been very helpful. Been playing around with ssg a little bit
and trying to gleen some sort of understanding from the documentation, which
is very good but in some cases terse.
It looks like the panel graphic objects will need to all be ssgTransform nodes
so that they can
On Thu, 21 Feb 2002, Curtis L. Olson wrote:
Just like we have competing FDM's with different focus, strengths
and weaknesses, I don't think it is bad to have competing
weather/environment management systems with different focus,
strengths and weaknesses.
When you say weather/environment
Hi,
If anyone has tried running the FG/OpenGC displays across a network of mixed
platforms you might experience a problem with the sizeof() function used to
determine the size of the network data packet.
Linux and cygwin calculate the value differently in aligning the bits in
memory.
the
18 matches
Mail list logo
