-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 4 Mar 2002 16:31, you wrote:
David Findlay wrote:
Andy Ross wrote:
I spent most of today working on a virtual cockpit interface for the
panel, and I'll be damned, it works!
Umm, one problem. When you look down, the panel
Andy Ross writes:
No problems there. YASim now reports this number in
/gear/gears[n]/compression-norm (should be an OK choice, according to
our rapidly evolving property conventions). The remaining problems
are only bookkeeping. We need to make exactly certain that the FDM
and the model
Melchior FRANZ writes:
AFAIK no. It was David who suggested that the reason could be
some wrong parameter in the c310 propeller setup, but there's
no solution yet.
Yup, the FDM's scare me, I don't go any where near them. :-)
Curt.
--
Curtis Olson IVLab / HumanFIRST Program
Andy Ross writes:
Another thing that might be helpful is if the FDM's would report the
amount of each gear compression to FlightGear so that could be
animated (and hopefully keep the tires above the ground.)
No problems there. YASim now reports this number in
On Mon 4. March 2002 13:21, you wrote:
Andy Ross writes:
Another thing that might be helpful is if the FDM's would report the
amount of each gear compression to FlightGear so that could be
animated (and hopefully keep the tires above the ground.)
No problems there. YASim
David Megginson writes:
Interesting -- I won't promise to integrate this into the 3D models
this week, but it should show up eventually.
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
Martin Dressler writes:
I hope you mean this as a joke.
I'm not sure. It's no more extreme than animating the elevator trim
tabs, which people _have_ asked for; in fact, the prop blade pitch is
more visible than the trim-tab position, and could have some useful
educational and debugging
--- Curtis L. Olson [EMAIL PROTECTED] wrote:
David Megginson writes:
Interesting -- I won't promise to integrate this
into the 3D models
this week, but it should show up eventually.
How far should this go? For variable-pitch props,
we could something
like
VS Renganathan writes:
How about leaving the ascii format as it is 'without further support', so
that we could continue using it. If its possible to leave it in a working
condition without breaking that would be wonderful. Afterall the ascii
format's similarity with Wavefront .obj format
Tony Peden writes:
I agree but keep in mind this will only get us so far
as long as the gear models don't have some idea of the
terrain height below each wheel. On a slope, the
uphill wheel(s) will still appear to be underground
and the downhill above it.
Was anyone able to devise a way
Hi,
Can you post what you changed? I'm not sure from the above exactly
which tags went where. Certainly, if you put the right tags in the
right places, it should work. :)
Here it is. I posted it earlier, but you might have missed the msg.
For both YASim and JSBSim the flaps seem inop.
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,
and a model
Alex Perry [EMAIL PROTECTED] said:
As far as I'm concerned, the outside view is purely for entertainment
since there is nothing realistic about hanging a couple dozen feet behind
the aircraft in the open air, operating the controls remotely.
Hmmm purely is one of those tricky words. There's
Alex Perry [EMAIL PROTECTED] said:
the instrument panel, dubious maneuvers apply a brown overlay to
the passenger seats ...
hehe...what's the property for that?
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Curtis L. Olson wrote:
Andy Ross writes:
No problems there. YASim now reports this number in
/gear/gears[n]/compression-norm (should be an OK choice, according
to our rapidly evolving property conventions). The remaining
problems are only bookkeeping. We need to make exactly
Curt asked:
Is anyone still using this ancient file format?
Yes.
Does anyone have any objections to ending support
in flightgear for it?
Is it easy to create a atg2btg converter (I only have btg2atg) or does
someone write a btg importer/exporter to plib? If so, then it is
completely ok by
Wolfram Kuss writes:
Is it easy to create a atg2btg converter (I only have btg2atg) or does
someone write a btg importer/exporter to plib? If so, then it is
completely ok by me.
Mostly I don't change the scenery (only add objects via ind file etc)
and also I work on this very seldomly, so
Hi,
Oh, never mind, it's just a typo. Note spelling of the property
above, and here:
[...]
data-flaps = fgGetDouble(/surface-positions/flaps-pos-norm);
[...]
Snip the stray s, and you should see correct behavior. This, it
must be admitted, is the biggest disadvantage of a
John Wojnaroski wrote:
How complete is the 747 wing model for slats, spoilers? Note they are
in the XML file; is it just a question of specifying the control axis
input.
Indeed. I have the /controls/spoilers property bound to the same
joystick axis I use for mixture (or maybe propeller
So Curtis L. Olson says:
Wolfram Kuss writes:
Is it easy to create a atg2btg converter (I only have btg2atg) or
does someone write a btg importer/exporter to plib? If so, then it is
completely ok by me.
Mostly I don't change the scenery (only add objects via ind file etc)
and also I work
There is a binary to ascii converter named btg2atg (atg = ascii terra
gear, btg = binary terra gear), but not vice versa, at least not that
I know of.
Bye bye,
Wolfram.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Wolfram Kuss writes:
There is a binary to ascii converter named btg2atg (atg = ascii terra
gear, btg = binary terra gear), but not vice versa, at least not that
I know of.
There's not a reverse converter, but it wouldn't be that hard to do if
someone wanted to make one ...
Curt.
--
Curtis
On Mon, 2002-03-04 at 06:42, Curtis L. Olson wrote:
Tony Peden writes:
I agree but keep in mind this will only get us so far
as long as the gear models don't have some idea of the
terrain height below each wheel. On a slope, the
uphill wheel(s) will still appear to be underground
and
On Mon, 2002-03-04 at 09:37, Andy Ross wrote:
Curtis L. Olson wrote:
Andy Ross writes:
No problems there. YASim now reports this number in
/gear/gears[n]/compression-norm (should be an OK choice, according
to our rapidly evolving property conventions). The remaining
problems
On Monday 04 March 2002 04:54 pm, you wrote:
Can anyone confirm or deny this?
Wasn't there a similar message a few releases ago?
It would be good to check obviously, but IIRC something
just matched the virus sig
___
Flightgear-devel mailing list
Wolfram Kuss wrote:
Curt asked:
Is anyone still using this ancient file format?
Yes.
Does anyone have any objections to ending support
in flightgear for it?
Is it easy to create a atg2btg converter (I only have btg2atg) or does
someone write a btg importer/exporter to plib? If
Wolfram Kuss writes:
There is a binary to ascii converter named btg2atg (atg = ascii terra
gear, btg = binary terra gear), but not vice versa, at least not that
I know of.
There's not a reverse converter, but it wouldn't be that hard to do if
someone wanted to make one ...
I assert that
27 matches
Mail list logo
