At 4/11/02, you wrote:
>>>Jon wrote:
>>>The data is all there. In fact, the model files the UIUC guys use
>>>present pretty much the same information that JSBSim does. Perhaps
>>>someone could write a translator?
>
>On Thu, 11 Apr 2002 13:33:30 -0500
> Michael Selig wrote:
>
>>Some thoughts - I
... 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
Hi!
I want to plot some trees in the scenary, but how do I know where
is the ground?
Thanks in advance,
Marcio Shimoda
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
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
Sam Varner writes:
>On Thu, 2002-04-11 at 19:44, Norman Vine wrote:
>> What OS ?
>> What compiler ?
>
>Gcc-3/Linux. It's actually the link time that takes so long.
compile as much as you feel comfortable with without debugging
at least plib and ssg and probably most of flightgear except for the
Alex Perry wrote:
>
> Personally, I've always preferred that event registration takes two
> parameters; the first delay time and the repeat delay time.
> This lets you do one-shot as well as immediate and non-immediate modes.
> Can we do something like that with Boost in future ?
> Obviously we c
"Curtis L. Olson" wrote:
>
> Bernie Bright writes:
> > Your analysis is correct. The old event manager executes an event when
> > it is registered and then subsequently every 'interval' milliseconds. I
> > can replace the old behaviour but wonder if I should. IMO registering
> > an event to be
On Thu, 2002-04-11 at 19:44, Norman Vine wrote:
> What OS ?
> What compiler ?
Gcc-3/Linux. It's actually the link time that takes so long.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-deve
Personally, I've always preferred that event registration takes two
parameters; the first delay time and the repeat delay time.
This lets you do one-shot as well as immediate and non-immediate modes.
Can we do something like that with Boost in future ?
Obviously we can support it right now if we w
Bernie Bright writes:
> Your analysis is correct. The old event manager executes an event when
> it is registered and then subsequently every 'interval' milliseconds. I
> can replace the old behaviour but wonder if I should. IMO registering
> an event to be run every x millseconds doesn't imply
"Curtis L. Olson" wrote:
>
> David Megginson writes:
> > All ambient lighting has suddenly vanished from my FlightGear, even
> > with my previously-built binary. I still see the 2D panel and the
> > runway lights, but nothing else, no matter what the time of day.
> > Other 3D programs like Blende
hat address
a couple other problems found as well.
Synced to CVS 21:50 EDT 2002-04-11
Description:
Minor fixes. Made some changes to get lighting correct for time of day
for now. MSVC compatibility fix and returned to clearing z-buffer only in
LOOKFROM (formerly pilot view).
Files:
http://www.sp
David Megginson writes:
> All ambient lighting has suddenly vanished from my FlightGear, even
> with my previously-built binary. I still see the 2D panel and the
> runway lights, but nothing else, no matter what the time of day.
> Other 3D programs like Blender and TuxRacer are still working fine.
Jim,
I did what you recommended and changed "virtual const sgMat4 &get..."
to "virtual const sgMat4 * get..." If I changed "virtual const sgMat4
&get..." to "virtual sgMat4 &get..." then everything worked.
Jonathan Polley
On Thursday, April 11, 2002, at 07:02 PM, Jim Wilson wrote:
>>> Jon wrote:
>>> The data is all there. In fact, the model files the UIUC
>>> guys use present pretty much the same information that
>>> JSBSim does. Perhaps someone could write a translator?
>
>On Thu, 11 Apr 2002 13:33:30 -0500
> Michael Selig wrote:
>
>>Some thoughts - I think it would be
David Megginson writes:
> All ambient lighting has suddenly vanished from my FlightGear, even
> with my previously-built binary. I still see the 2D panel and the
> runway lights, but nothing else, no matter what the time of day.
> Other 3D programs like Blender and TuxRacer are still working
All ambient lighting has suddenly vanished from my FlightGear, even
with my previously-built binary. I still see the 2D panel and the
runway lights, but nothing else, no matter what the time of day.
Other 3D programs like Blender and TuxRacer are still working fine.
Has anything else ever noticed
Jonathan Polley <[EMAIL PROTECTED]> said:
> Changing the '&' to a '*' did not solve the problem. When I made Fred's
> change (removing 'const' but leaving the '&') I was able to get it to
> build.
Ummm...did you change those to a pointer to an array of arrays? It wasn't
just a matter of chan
Sam Varner writes:
>
>I was wondering if anyone had tips on
>reducing compile and startup times.
What OS ?
What compiler ?
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
I just made my first, um, "flight" dynamics model for Vamos. It doesn't
do anything useful yet. But I was wondering if anyone had tips on
reducing compile and startup times.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear
Would it be possible to convert the property string to a token? This way,
if I were to want to read the property I can avoid all the messy string
processing. The token could be an index into a table or a pointer to the
proper structure and the read/write routines could be overloaded to accep
Thanks. On a related note, has anyone decided how the issues that MSVC
has with JSBSim (getting confused on some of the overloading) will be
resolved?
Thanks again,
Jonathan Polley
On Thursday, April 11, 2002, at 09:35 AM, Curtis L. Olson wrote:
> Jonathan Polley writes:
>> There are older
Changing the '&' to a '*' did not solve the problem. When I made Fred's
change (removing 'const' but leaving the '&') I was able to get it to
build.
Thanks!
Jonathan Polley
On Thursday, April 11, 2002, at 12:37 AM, Jim Wilson wrote:
> Jonathan on those four lines (thats all there is) change
David Megginson wrote:
> The YASim C172 idle is better -- it's down to 1000 RPM -- but it's
> still about 200-300 RPM too high based on what I saw yesterday (this
> is at an airfield under 400ft ASL).
Yeah, it was basically a hack. There are two "core" problems that I
can think of with the mo
Frederic Bouvier writes:
> MSVC has no 'fmax' function. 'max' is ok (a macro !).
Hmm -- max won't work under GCC because it's an inlined function. I
guess I'll have to write out the comparison.
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
On Thu, 11 Apr 2002 18:52:24 +0200
Martin Spott <[EMAIL PROTECTED]> wrote:
>make[4]: Entering directory
>make[4]: *** [JSBSim.o] Error 1
>
>quickstep: 18:51:57 ~> gcc --version
>2.95.3
Yep, we're aware of it.
I'll fix this when I get home. We use the max/min
functions in other parts of JSBS
FYI
-Original Message-
From: Norman Vine [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 11, 2002 11:41 AM
To: '[EMAIL PROTECTED]'
Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
Subject: RE: More Tweaks
Tony Peden
>
>--- Norman Vine <[EMAIL PROTECTED]> wrote:
>> Jon, Tony
>>
>> FYI
>> pr
make[4]: Entering directory `/usr/local/src/FlightGear/src/FDM/JSBSim'
g++ -DFGFS -I../../.. -I../../../src -I/opt/gnu/include -I/usr/local/include
-I/usr/local/FlightGear/include -I/usr/X11R6/include -O3 -D_REENTRANT -c JSBSim.cxx
JSBSim.cxx: In method `bool FGJSBsim::copy_to_JSBsim()':
JSBSim
With the latest cvs compiling under linux with gcc version 2.95.4 I'm
getting the following error.
c++ -DFGFS -I../../.. -I../../../src -I/usr/local/include -I/usr/X11R6/include -Wall
-O2 -c JSBSim.cxx
JSBSim.cxx: In method `bool FGJSBsim::copy_to_JSBsim()':
JSBSim.cxx:335: implicit declarati
From: "David Megginson" <[EMAIL PROTECTED]>
> I've added a new property, /controls/parking-brake (also available
> through FGControls). For both JSBSim and the YASim C172, this
> property overrides the toe brakes for the main gear (actually, for
> YASim, it is just added then clamped).
in JSBSim
David Megginson <[EMAIL PROTECTED]> said:
> I've added a new property, /controls/parking-brake (also available
> through FGControls). For both JSBSim and the YASim C172, this
> property overrides the toe brakes for the main gear (actually, for
> YASim, it is just added then clamped).
>
> The
The new, configurable mouse code is now the default. If you haven't
been using it already, try rebuilding and let me know if you see any
problems. Unless anything comes up, we'll probably remove the old
mouse code in a few days (it's still available with the configure
option --with-old-mouse for
The YASim C172 idle is better -- it's down to 1000 RPM -- but it's
still about 200-300 RPM too high based on what I saw yesterday (this
is at an airfield under 400ft ASL).
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-de
I've added a new property, /controls/parking-brake (also available
through FGControls). For both JSBSim and the YASim C172, this
property overrides the toe brakes for the main gear (actually, for
YASim, it is just added then clamped).
The 'B' key now toggles the parking brake on and off. Ther
Jonathan Polley writes:
> There are older issues with building under MSVC:
>
> Main/viewer.cxx has a #include that should be either
> "fg_props.hxx" or , which ever you prefer.
>
> Both Network/raw_ctrls.hxx and Network/net_fdm.hxx have static constants
> defined as a part of their classes.
If you are using Win32 try PFE (Programmers File Editor)
(http://www.lancs.ac.uk/people/cpaap/pfe/), you can select Unix or Dos line endings as
a default and when you save.
It has some language awareness as well.
Richard
> -Original Message-
> From: Jon Berndt [mailto:[EMAIL PROTECTED]
Sorry about that. I've got to find a darned editor that doesn't do that to
me. I'm guilty!
Jon
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Frederic
> Bouvier
> Sent: Thursday, April 11, 2002 6:03 AM
> To: FlightGear Development
> Subject: [Fli
Hello,
the file prop_75in2f.xml has been introduced in CVS with DOS/Windows line
endings ( CRLF or "\r\n" ). When people like me check out with WinCVS,
LF are replaced by CRLF, so the file has now CRCRLF file endings and the
parser of JSBsim bombs !
A bad correction would be to put it binary (-k
Hello,
removing the const before sgMat4 cure the problem.
Cheers,
-Fred
- Original Message -
From: "Jim Wilson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, April 11, 2002 7:37 AM
Subject: Re: [Flightgear-devel] Windows Build Problems
> Jonathan on those four lines (th
41 matches
Mail list logo
