Michael Selig writes:
I speculate that the new problem running w/ the MagicCarpet FDM (buried
aircraft) is related to the same problem running w/ the LaRCsim/UIUC FDM
that I have reported. All the while, this has not been a problem running
w/ JSBSim FDM. The problem started around the
On Fri, 26 Apr 2002 09:33:00 -0500 (CDT)
Curtis L. Olson [EMAIL PROTECTED] wrote:
Ok, now isn't this very interesting. There is definitely some
confusion going on here. I agree with Jim, it's not the fault of the
viewer code.
Ignoring the issue of the CG possibly moving during the
Jon, it would also be nice if the user can directly or indirectly
control CG position as well. This can greatly affect the performance
of a plane and an instructor could throw in a tail heavy configuration
along with a few failed instruments, low visibility, and some healthy
turbulance to make
Curtis L. Olson [EMAIL PROTECTED] said:
Michael, I believe the correct solution is to specify the pilot view
offset relative to the CG. We also need to specify the offset from
the CG to the external model's origin (0,0,0) point so that it can be
drawn correctly.
Hopefully Jim can explain
Jim Wilson [EMAIL PROTECTED] said:
Curtis L. Olson [EMAIL PROTECTED] said:
Michael, I believe the correct solution is to specify the pilot view
offset relative to the CG. We also need to specify the offset from
the CG to the external model's origin (0,0,0) point so that it can be
Hello again,
To set the stage, running the current CVS version of everything, on a
P2-300 Linux machine with kernel 2.4.18. Interfacing with CH Flight Sim
Yoke USB and CH Pro Pedals USB. Working great with the default c172, now
that the old (failed) Nvidia card is replaced with a
Jon S Berndt writes:
On Fri, 26 Apr 2002 13:10:21 -0500
Michael Selig [EMAIL PROTECTED] wrote:
Pertaining to the question about where the target spot is
located, i.e. what the viewer code uses as the reference
point for centering the model on the screen. This point
should be the aircraft
On Fri, 26 Apr 2002 15:25:58 -0400
Norman Vine [EMAIL PROTECTED] wrote:
Jon S Berndt writes:
Yes. The one foggy point in my mind is what problems (if
any) might be associated with a floating CG (i.e. from
fuel burnoff, etc.).
IMHO You need two (2) CG's.
1) the 'reference' static CG usually
--- Jon S Berndt [EMAIL PROTECTED] wrote:
On Fri, 26 Apr 2002 15:25:58 -0400
Norman Vine [EMAIL PROTECTED] wrote:
Jon S Berndt writes:
Yes. The one foggy point in my mind is what
problems (if
any) might be associated with a floating CG (i.e.
from
fuel burnoff, etc.).
IMHO You need
On Fri, 26 Apr 2002 13:14:49 -0700 (PDT)
Tony Peden [EMAIL PROTECTED] wrote:
I think a fixed reference point on the aircraft that
has nothing to do with the center of gravity would be
much better. Less potential for confusion that way.
And that could be the initial CG. If we provide a
That was the problem. Thanks guys.
I built the current cvs version of simgear
and flightgear with plib 1.4.2, and everything
seems to work. Is it true that the cvs version of
flightgear always use the most recent stable verion of
plib? Or is the cvs version of plib sometimes used?
Mark
On Fri, 26 Apr 2002 22:47:41 +0200 (MEST)
[EMAIL PROTECTED] wrote:
I think you would need a whole bunch of input CG's that go together to
make one output CG. The static CG of the aircraft (that of the
airframe itself) is just one of those input CG's. Its position is given
by the manufacturer
On Fri, 26 Apr 2002 11:43:42 -0500 (CDT)
Curtis L. Olson [EMAIL PROTECTED] wrote:
Jon, it would also be nice if the user can directly or
indirectly control CG position as well. This can greatly affect the
performance of a plane and an instructor could throw in a tail heavy
configuration
So Jon S Berndt says:
On Fri, 26 Apr 2002 15:25:58 -0400
Norman Vine [EMAIL PROTECTED] wrote:
Jon S Berndt writes:
Yes. The one foggy point in my mind is what problems (if
any) might be associated with a floating CG (i.e. from
fuel burnoff, etc.).
IMHO You need two (2) CG's.
1) the
On Fri, 2002-04-26 at 09:43, Curtis L. Olson wrote:
Jon, it would also be nice if the user can directly or indirectly
control CG position as well. This can greatly affect the performance
of a plane and an instructor could throw in a tail heavy configuration
along with a few failed
On Thu, 25 Apr 2002 23:11:25 -0500,
Michael Selig [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
I would not have to speculate if I knew what I need to know about c++
...
..why _is_ FG written in C++ and not C?
..pointers to docs?
..merits of C that I see: the linux kernel is
On Friday 26 April 2002 9:56 am, Marcel Wittebrood wrote:
Dear developers,
I work with cygwin under windows 2000 logged in as administrator.
Now I have a few questions :
I used the following argument to be able to look at the variable tree
with telnet:
--props=socket,bi,5,5500,tcp
One
Arnt Karlsen writes:
..why _is_ FG written in C++ and not C?
I'm going to limit myself to one public posting in this thread and
will send any further responses offline.
I very much doubt that I would be contributing to FlightGear if it
were written in C rather C++. I wrote my first large
Michael Selig [EMAIL PROTECTED] said:
I think the doc above is out-of-date. The offsets can be controlled w/
these properties:
**
$FG_ROOT/Aircraft/beech99/Models/uiuc/beech99/beech99-model.xml
**
?xml version=1.0?
PropertyList
Boslough, Mark B writes:
That was the problem. Thanks guys.
I built the current cvs version of simgear
and flightgear with plib 1.4.2, and everything
seems to work. Is it true that the cvs version of
flightgear always use the most recent stable verion of
plib? Or is the cvs version of
Norman Vine [EMAIL PROTECTED] said:
IMHO You need two (2) CG's.
1) the 'reference' static CG usually determined from manufacturer
specs or something similar for use in FGFS for reference purposes.
2) The 'actual' dynamic CG of the aircraft, as determined by vehicle
Hi Curt,
This is very helpful and I agree on the concept of scheduling tile caching for
all the views. First I'm going to try and resolve the Aircraft issues and get
the faking out of the viewer (it is really only faking with the tower views).
Let me do some work with this and get back to you.
Is it safe to summarize the responses as follows? The reason that the
MagicCarpet FDM does not properly position the aircraft on the runway is
because it has no concept of airframe. This means that it does not take
into account the relative position of the pilot's view with respect to the
Yep. We already do that. But the empty-weight, unloaded CG
doesn't change.
Surely, when I switch from the VFR panel to the IFR panel,
the FDM adds a POINT_MASS in the appropriate place ... ? No ?
8-)
___
Flightgear-devel mailing list
[EMAIL
Jim Wilson writes:
Norman Vine [EMAIL PROTECTED] said:
IMHO You need two (2) CG's.
1) the 'reference' static CG usually determined from manufacturer
specs or something similar for use in FGFS for reference purposes.
2) The 'actual' dynamic CG of the aircraft, as
Jonathan Polley writes:
p.s. I am ignoring CG here because, to me, it is only one of the
components of understanding the airframe. To me, airframe means body size
and shape.
Yes, I think we need to keep the terminology and concepts straight.
There is some confusion in this thread which is
Arnt Karlsen writes:
..can C code be generated from C++ or Java source without undue
difficulty using some tool? How about C++ from Java source?
Originally, back in the old days, C++ was implimented via a translater
that produced C code for final compilation. So, yes C code can be
generated,
You should have a look at the bindings in your joystick.xml file
as there a bunch of defaults in there that you probably won't like.
I locally have a chproducts.xml file which is used inside the preferences.xml
file instead of the standard joystick.xml file, so that CVS doesn't keep
whingeing
On Friday 26 April 2002 10:50 pm, Alex Perry wrote:
You should have a look at the bindings in your joystick.xml file
as there a bunch of defaults in there that you probably won't like.
I locally have a chproducts.xml file which is used inside the
preferences.xml file instead of the standard
Curtis L. Olson [EMAIL PROTECTED] said:
It may be that in most cases the CG doesn't move enough from frame to
frame to have a noticable visual effect. However, it seems like in
the long run we would be a lot better off using some fixed reference
point on the airframe, rather than the CG.
That's a thought. Let me put some comments in there first though ...
On Friday 26 April 2002 10:50 pm, Alex Perry wrote:
You should have a look at the bindings in your joystick.xml file
as there a bunch of defaults in there that you probably won't like.
I locally have a chproducts.xml
This thread brings up a good question: How do you override the default
config files (or any file in FGBASE) without creating an entire copy of
the FGBASE directory (besides symlinks...think cross-platform)? IMHO, I
think we should consider using a personal ~/.fgfs/ directory for each
user that
* [EMAIL PROTECTED] (Alex Perry) [2002.04.27 23:03]:
For example, say I'm a long-time X-Plane user and just can't live with
the default FG key bindings. I could create my very own
~/.fgfs/keyboard.xml and completely override the master file.
That's exactly why the keymappings are broken
Jim Wilson writes:
David Megginson [EMAIL PROTECTED] said:
The problem is in PUI and/or the prop picker -- the font we're
currently using does not seem to have a '|' character in it, and that
must be throwing something off. Here's what gdb says:
0x082bceab in puFont::getStringWidth(char
For example, say I'm a long-time X-Plane user and just can't live with
the default FG key bindings. I could create my very own
~/.fgfs/keyboard.xml and completely override the master file.
That's exactly why the keymappings are broken out of the preferences.xml
You can have two
Actually I would call this a FGFS problem in that FGFS is
asking for a character that is not present in the PLib font
that is being used. The PLib Font system does not claim
to be a universal font renderer in fact just the oposite in that
it gives you only the characters that it can pack
On Fri, Apr 26, 2002 at 09:33:23PM -0700, Alex Perry wrote:
For example, say I'm a long-time X-Plane user and just can't live with
the default FG key bindings. I could create my very own
~/.fgfs/keyboard.xml and completely override the master file.
That's exactly why the
On Saturday 27 April 2002 12:44 am, Simon Fowler wrote:
On Fri, Apr 26, 2002 at 09:33:23PM -0700, Alex Perry wrote:
For example, say I'm a long-time X-Plane user and just can't live
with the default FG key bindings. I could create my very own
~/.fgfs/keyboard.xml and completely
38 matches
Mail list logo
