At 4/12/02, you wrote:
>Michael Selig
>
> >With this version day does turn to night, after a short period of
> >flying. I know this is being discussed in another thread.
>
>FYI
>speeding time up momentarily will turn the lights on to
>
>'t' key followed by 'T' key
>
>A real fix is in the pipe.
>
Michael Selig
>With this version day does turn to night, after a short period of
>flying. I know this is being discussed in another thread.
FYI
speeding time up momentarily will turn the lights on to
't' key followed by 'T' key
A real fix is in the pipe.
Norman
__
At 4/12/02, you wrote:
>Michael Selig writes:
>
> > When I start up I see this:
> > http://amber.aae.uiuc.edu/~m-selig/tmp/beech.gif
>
>Yes, it looks like your gear code isn't holding the plane above the
>ground, so it's resting at its origin. When I try
>
> fgfs --aircraft=c172-uiuc
>
>using
At 4/12/02, you wrote:
>Michael Selig writes:
>
> > When I start up I see this:
> > http://amber.aae.uiuc.edu/~m-selig/tmp/beech.gif
>
>Yes, it looks like your gear code isn't holding the plane above the
>ground, so it's resting at its origin. When I try
>
> fgfs --aircraft=c172-uiuc
>
>using
David Megginson wrote:
> I think we've always used +z up. YASim uses +z down internally, if
> I recall correctly, but that shouldn't affect anything else.
Heh, actually... YASim is +z up too.
For the record, the YASim internal aircraft coordinate frame:
+ Take your right hand.
+ Point your
Michael Selig writes:
> When I start up I see this:
> http://amber.aae.uiuc.edu/~m-selig/tmp/beech.gif
Yes, it looks like your gear code isn't holding the plane above the
ground, so it's resting at its origin. When I try
fgfs --aircraft=c172-uiuc
using the UIUC files currently in the base
At 4/12/02, you wrote:
>Michael Selig writes:
> > Using our FGFS CVS checkout (Simgear, flightsim, fgfsbase) from 4/7/02 +
> > our own uiuc mods, I just remade/installed Simgear and remade fgfs, and I
> > still get this problem.
> >
> > Besides Norman and all of us at UIUC, are other people seeing
Michael Selig writes:
> Using our FGFS CVS checkout (Simgear, flightsim, fgfsbase) from 4/7/02 +
> our own uiuc mods, I just remade/installed Simgear and remade fgfs, and I
> still get this problem.
>
> Besides Norman and all of us at UIUC, are other people seeing UIUC and
> LaRCsim models bel
At 4/12/02, you wrote:
>David Megginson writes:
> >
> >Michael Selig writes:
> >
> > > ... while all these wonderful *uiuc-set.xml airplanes are now being
> > > buried alive, I have a few simple questions (multiple choice):
> >
> >I cannot reproduce your problem -- with yesterday evening's CVS, I
David Megginson writes:
>
>Michael Selig writes:
>
> > ... while all these wonderful *uiuc-set.xml airplanes are now being
> > buried alive, I have a few simple questions (multiple choice):
>
>I cannot reproduce your problem -- with yesterday evening's CVS, I see
>a C172 sitting nicely on top of t
Michael Selig writes:
> ... while all these wonderful *uiuc-set.xml airplanes are now being
> buried alive, I have a few simple questions (multiple choice):
I cannot reproduce your problem -- with yesterday evening's CVS, I see
a C172 sitting nicely on top of the runway with any of the followi
Bruce Finney writes:
> The convention for moving models for flight simulation visual system
> is for the origin to be at the CG location for aircraft models.
That would be problematic, since (as Jon and others have pointed out)
the CG isn't fixed. In JSBSim, we take any arbitrary reference po
... while all these wonderful *uiuc-set.xml airplanes are now being buried
alive, I have a few simple questions (multiple choice):
What is the variable that dictates where the little green HUD center dot
goes? (OK, things in the uiuc_gear code have an effect on this mystery
variable, but the
> The convention for moving models for flight simulation visual system
> is for the origin to be at the CG location for aircraft models. The
The *initial* CG location? The CG location can change.
Jon
smime.p7s
Description: application/pkcs7-signature
> The convention for moving models for flight simulation visual system
> is for the origin to be at the CG location for aircraft models. The
> coordinate system that we use on our "heavy iron" visual system is +y
> out the nose, +x to the right and +z up. For an industry disertation on
> the subj
The convention for moving models for flight simulation visual system
is for the origin to be at the CG location for aircraft models. The
coordinate system that we use on our "heavy iron" visual system is +y
out the nose, +x to the right and +z up. For an industry disertation on
the subject there
At 4/10/02, you wrote:
>Michael Selig wrote:
> > I can ask this differently. What sets the height above the runway of
> > the hud-ladder target spot (wrt the 3D model view) --- ie the center
> > spot? For c310-yasim and c172-larcsim, it's above the runway. For
> > UIUC models, it's below the ru
Michael Selig wrote:
> I can ask this differently. What sets the height above the runway of
> the hud-ladder target spot (wrt the 3D model view) --- ie the center
> spot? For c310-yasim and c172-larcsim, it's above the runway. For
> UIUC models, it's below the runway (a recent change).
Whe
At 4/10/02, you wrote:
>Apparently something has changed w/ the z-placement of the model on the
>runway. With the recent CVS, my models are now sitting below the runway
>and I can only see (sometimes) the tops of the airplanes. In my
>*-model.xml files, this was working:
>
>
> -.2
> -.6
Apparently something has changed w/ the z-placement of the model on the
runway. With the recent CVS, my models are now sitting below the runway
and I can only see (sometimes) the tops of the airplanes. In my
*-model.xml files, this was working:
-.2
-.6
0
Now to get the models
20 matches
Mail list logo
