[EMAIL PROTECTED] wrote:
Modified Files:
f16.xml
Log Message:
improved f-16 from Erik Hofman
Oh, _very_ nice, but eerm, did anyone manage to get the beast off the
runway without crashing _before_ take-off ? Is it possible ?
Martin.
--
Unix _IS_ user friendly - it's just
On Tuesday 25 February 2003 2:22 pm, Martin Spott wrote:
[EMAIL PROTECTED] wrote:
Modified Files:
f16.xml
Log Message:
improved f-16 from Erik Hofman
Oh, _very_ nice, but eerm, did anyone manage to get the beast off
the runway without crashing _before_ take-off ? Is it
John Check writes:
On Tuesday 25 February 2003 2:22 pm, Martin Spott wrote:
[EMAIL PROTECTED] wrote:
Modified Files:
f16.xml
Log Message:
improved f-16 from Erik Hofman
Oh, _very_ nice, but eerm, did anyone manage to get the beast off
the runway without crashing
On Tuesday 25 February 2003 3:40 pm, Curtis L. Olson wrote:
John Check writes:
On Tuesday 25 February 2003 2:22 pm, Martin Spott wrote:
[EMAIL PROTECTED] wrote:
Modified Files:
f16.xml
Log Message:
improved f-16 from Erik Hofman
Oh, _very_ nice, but eerm,
Curtis L. Olson wrote:
John Check writes:
On Tuesday 25 February 2003 2:22 pm, Martin Spott wrote:
[EMAIL PROTECTED] wrote:
Modified Files:
f16.xml
Log Message:
improved f-16 from Erik Hofman
Oh, _very_ nice, but eerm, did anyone manage to get the beast off
the runway without
John Check [EMAIL PROTECTED] wrote:
On Tuesday 25 February 2003 2:22 pm, Martin Spott wrote:
[EMAIL PROTECTED] wrote:
Modified Files:
f16.xml
Log Message:
improved f-16 from Erik Hofman
Oh, _very_ nice, but eerm, did anyone manage to get the beast off
the runway without
Log Message:
Add Carsten Hoefer's excellent flight tutorial to help system
Thanks, John!
I hope Carsten will find time to go on with it later.
Michael
--
Michael Basler, Jena, Germany
[EMAIL PROTECTED]
http://www.geocities.com/pmb.geo/
Does this mean, the document is also part of cvs?
Can anyone give me a hand on how to continue writing using cvs?
Where do I have to send or put new chapters?
Thanks,
Carsten
Michael Basler schrieb:
Log Message:
Add Carsten Hoefer's excellent flight tutorial to help
system
Thanks,
Carsten,
Does this mean, the document is also part of cvs?
Luckily, indeed. Plus, it certainly will become part of the next official
release (if you don't object, of course).
Can anyone give me a hand on how to continue writing using cvs?
Where do I have to send or put new chapters?
Doh! Sorry for letting this onto -cvslogs. I wasn't paying attention
to which list I was looking at. I think I need some sleep...
* [EMAIL PROTECTED] (Chris) [2003.02.18 23:03]:
Hi,
I would like to edit the clouds, but where I can find the *.cld format
tools for?
about this post
On 12/30/02 at 7:47 PM [EMAIL PROTECTED] wrote:
Date: Mon Dec 30 14:47:23 EST 2002
Author: cvsroot
Update of /home/cvsroot/FlightGear/FlightGear
In directory bitless:/tmp/cvs-serv15423
Modified Files:
preferences.xml
Log Message:
Changed default frequencies. KSFO ATIS is not on standby
On 12/28/02 at 7:10 PM [EMAIL PROTECTED] wrote:
Date: Sat Dec 28 14:10:41 EST 2002
Author: cvsroot
Update of /home/cvsroot/FlightGear/FlightGear/Aircraft/Instruments
In directory bitless:/tmp/cvs-serv31667/Instruments
Modified Files:
single-magneto-switch.xml
Log Message:
Changed to use
David Luff writes:
On 12/30/02 at 7:47 PM [EMAIL PROTECTED] wrote:
Date: Mon Dec 30 14:47:23 EST 2002
Author: cvsroot
Update of /home/cvsroot/FlightGear/FlightGear
In directory bitless:/tmp/cvs-serv15423
Modified Files:
preferences.xml
Log Message:
Changed default frequencies.
On 1/2/03 at 11:52 AM Curtis L. Olson wrote:
David,
Another feature request would be to create a volume and on/off switch
property and honor them. Volume could go from 0.0 - 1.0 scaled
appropriately, and on/off is pretty self explanitory. It would also
be nice to have a servicable property so
On 1/2/03 at 11:52 AM Curtis L. Olson wrote:
Another feature request would be to create a volume and on/off switch
property and honor them. Volume could go from 0.0 - 1.0 scaled
BTW, can you hear the audio ATIS OK on your Linux box? There have been a
few problems reported with it over
David Luff writes:
On 1/2/03 at 11:52 AM Curtis L. Olson wrote:
Another feature request would be to create a volume and on/off switch
property and honor them. Volume could go from 0.0 - 1.0 scaled
BTW, can you hear the audio ATIS OK on your Linux box? There have been a
few problems
David Luff writes:
This is fantastic and works beautifully! Unfortunately the default startup
at the moment leaves the magneto switch stuck in the starter position, and
the only way to get it back so the above can work properly if required is
to hit the space bar as before.
Can you find
[EMAIL PROTECTED] wrote:
Lee Elliott
I also noticed that there don't appear to be models included for the F-104,
F-15 F-16 and I think I could probably do some and animate them for fgfs if
they'd be useful.
I would realy like it if someone could add 3D models for those aircraft.
I've
Michael Basler wrote:
I tried this. It was still recognizable after conversion in the HTML. I
simply searched for my address (Ctrl-GF in IE) and it was found :-( I tried
several font changes etc. which all did not hide the address.
A clever sign for/aft the @ being invisible but masking
Christian,
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Christian
Mayer
This gives ma an idea:
Render only the @ to a picture and include this picture instead of the
real @ sign in the address. I think this should fool enough
address-harvesters.
Sounds like a cool idea
Norman,
[mailto:[EMAIL PROTECTED]]On Behalf Of Norman Vine
Sent: Tuesday, December 17, 2002 8:09 PM
To: [EMAIL PROTECTED]
Why not just use ' at ' instead of '@'
note spaces surrounding 'at'
Something similar already occured to me but I've dismissed it as being
to ugly. If those named
Norman Vine wrote:
Michael Basler writes:
Christian Mayer wrote:
This gives ma an idea:
Render only the @ to a picture and include this picture instead of the
real @ sign in the address. I think this should fool enough
address-harvesters.
Sounds like a cool idea as
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/www/Docs/InstallGuide
In directory seneca:/tmp/cvs-serv28258
Modified Files:
getstart.html getstart.pdf getstartap1.html getstartap2.html
getstartap3.html getstartch1.html getstartch2.html
getstartch3.html
Chrisitan,
Well, I think even addresses like
something @ something.com
aren't save against spammers.
I guessed it.
So far the best recepie is to convert the address to little pixel
graphics and to include the images on the page.
...which 100 or so graphics you are going to create...?
Christian,
Including images in LaTeX is no problem - that just leaves us with the
problem how we are generating the images...
Exactly. Although the HTML converter might become a bit slow with 100+ pix.
Perhaps no serious problem.
I'm sure that one of the Unix gurus knows a fast way to do
Michael Basler writes:
Chrisitan,
Well, I think even addresses like
something @ something.com
aren't save against spammers.
I guessed it.
So far the best recepie is to convert the address to little pixel
graphics and to include the images on the page.
...which 100 or so
Curt,
Could you fake something as an equation:
$ curt\@flightgear.org $
latex2html would convert this to a graphic automatically ... although
in equation mode you have to worry about things getting interpreted as
equations and variables ...
Yes, latex2html does, but tex4ht which I use
Modified Files:
obj.cxx
Log Message:
Have DummyBSphereEntity inherit from ssgBranch instead of ssgEntity,
to allow building with the latest plib CVS.
Uh, I appreciate this one _very_ much because it enables me to follow the
current development.
Thanks,
Martin.
--
Unix _IS_
Tony Peden writes:
The 48 in number checks with my copy of the POH (from which many
other numbers have been derived, so we should probably stick with
that)
You've talked before about forking, and that might not be a bad idea.
Right now, we're more-or-less targetting a 172R, but the 48
On Thu, 2002-09-19 at 04:26, David Megginson wrote:
Tony Peden writes:
The 48 in number checks with my copy of the POH (from which many
other numbers have been derived, so we should probably stick with
that)
You've talked before about forking, and that might not be a bad idea.
I don't really object to that -- except that I wonder how many folks
will be able to really tell the difference. Surely, even in the real
thing, the differences are fairly subtle. I'm also not so sure that we
have the fidelity that making that distinction implies.
I recommend the split,
Alex Perry writes:
The last ten degrees _are_ mostly drag, but that's what you need
(a) to get a steep final in rugged terrain
(b) for fast descents in emergency management
(c) for a relatively quick flare for short fields
Speaking of quick flares, I'm finally getting the hang of
Tony Peden writes:
It looks like this may have helped crosswind handling on the ground
considerably. The relatively small amount of testing I've done shows
that the c172 will sit still in up to a 15 knot crosswind and turn very
slowly in 20 knots.
Let us know what you think.
I'll
On Wed, 2002-09-18 at 05:52, David Megginson wrote:
Tony Peden writes:
It looks like this may have helped crosswind handling on the ground
considerably. The relatively small amount of testing I've done shows
that the c172 will sit still in up to a 15 knot crosswind and turn very
Tony Peden writes:
I didn't look at everything, but the nose wheel was in NONE and the
mains CASTERED as far back as I looked (which went back to the beginning
of time for the configurable gear). I can't explain the CASTERED mains,
but I understood what you call steer groups to be brake
David Megginson writes:
Note a second problem with this code: it uses getDrPos (the actual
rudder position) and ignores maxSteerAngle from the config file. A
better option would probably be
SteerAngle = SteerGain*FCS-GetDrCmd()*maxSteerAngle*RADTODEG;
For RADTODEG, read DEGTORAD.
On Wed, 18 Sep 2002 09:29:40 -0400
David Megginson [EMAIL PROTECTED] wrote:
Here's an excerpt from FGLGear.cpp:
case bgNose:
SteerGain = -0.50;
BrakeFCoeff = rollingFCoeff;
break;
In other words, if gear belongs to bgNone, it gets
SteerGain=0.0, so
On Wed, 18 Sep 2002 10:15:54 -0400
David Megginson [EMAIL PROTECTED] wrote:
For RADTODEG, read DEGTORAD.
Use
degtorad
and
radtodeg
These are consts from the FGJSBBase class. This is where
commonly used constants are being migrated to, instead of
#defines, which we are moving away from.
Jon S Berndt writes:
I may be guilty, here. Note that this file needs to be
gone through again with a fine tooth comb and validated.
Just when I think I can't become more overwhelmed than I
already am ...
Wife pregnant with triplets again?
(Don't laugh, my wife has a friend who had two
Is there some reasoning behind setting the steering gains according to
the brake selection? This makes no sense to me. It looks to me like
their needs to be a separate steering selection (or just specify the
gain in the config file).
Agreed. I beg your indulgence - let me have a look at
On Wed, 2002-09-18 at 17:48, Jon Berndt wrote:
Is there some reasoning behind setting the steering gains according to
the brake selection? This makes no sense to me. It looks to me like
their needs to be a separate steering selection (or just specify the
gain in the config file).
On Sat, 06 Jul 2002 13:49:36 -0700,
Andy Ross [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
Arnt Karlsen wrote:
..(during the Falklands War, the Britts tested refuelling of
Harriers and Sea Harriers, from ships, in-hover refuelling,
believe I saw this in Air Progress magazine
Arnt Karlsen wrote:
..(during the Falklands War, the Britts tested refuelling of Harriers
and Sea Harriers, from ships, in-hover refuelling, believe I saw this
in Air Progress magazine in the mid 80'ies.)
I think what you're remembering is the Sky Hook gadget that was
developed but never
On Fri, 5 Jul 2002 14:37:10 -0500,
Jon Berndt [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
FWIW, JSBSim sets no maximum for number of tanks. I'm not sure how
this might be affected by lack of ability to control them. Also, is
there a standard way to select a source tank and a
...or, between aircraft for in-flight refuelling?
..(during the Falklands War, the Britts tested refuelling of Harriers
and Sea Harriers, from ships, in-hover refuelling, believe I saw this
in Air Progress magazine in the mid 80'ies.)
exactly.
smime.p7s
Description:
David Luff writes:
CylinderHeadTemp_degK += (dqdt_cylinder_head / HeatCapacityCylinderHead) *
dt;
Corrected.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
Flightgear-devel mailing list
[EMAIL
Was this a mistake?
Best,
Jim
[EMAIL PROTECTED] said:
Date: Tue Jun 11 13:06:29 EDT 2002
Author: cvsroot
Update of /home/cvsroot/FlightGear/FlightGear/Aircraft
In directory bitless:/tmp/cvslck/cvs-serv8782/Aircraft
Modified Files:
X15-set.xml
Log Message:
Command line help
Cameron Moore writes:
* [EMAIL PROTECTED] (Curtis L. Olson) [2002.05.16 23:06]:
Update of /var/cvs/FlightGear-0.7/FlightGear/src/Main
In directory seneca:/tmp/cvs-serv26528/src/Main
Modified Files:
options.cxx
Log Message:
Bernie Bright:
To make MSVC happy it appears we
* [EMAIL PROTECTED] (Curt Olson) [2002.05.17 08:43]:
Cameron Moore writes:
* [EMAIL PROTECTED] (Curtis L. Olson) [2002.05.16 23:06]:
Update of /var/cvs/FlightGear-0.7/FlightGear/src/Main
In directory seneca:/tmp/cvs-serv26528/src/Main
Modified Files:
options.cxx
Log
Cameron Moore writes:
* [EMAIL PROTECTED] (Curt Olson) [2002.05.17 08:43]:
Cameron Moore writes:
* [EMAIL PROTECTED] (Curtis L. Olson) [2002.05.16 23:06]:
Update of /var/cvs/FlightGear-0.7/FlightGear/src/Main
In directory seneca:/tmp/cvs-serv26528/src/Main
Modified Files:
Curtis L. Olson [EMAIL PROTECTED] writes:
Originally this was changed to something like:
cout usage:
Nicely formatted text
that will look
exactly like it is entered
here when
it is displayed by the program.
This is very 'pretty' to be able
to do. endl;
Cameron Moore wrote:
Then I'd like to request that we revert the changes to
options.cxx:fgUsage(). Is this:
cout say endl
what?! endl;
worse than this?:
cout say\n\
what?!\n;
Far be it from me to argue with Bernie about anything C++, but I prefer
to use the
[EMAIL PROTECTED] wrote:
This can be done portably using the standard string concatenation feature of
the language. The above would look like the following and likely work with
any reasonably modern compiler (this string concatenation feature did not
exist in KR C but did beginning with
Christian Mayer wrote:
Note: You 2nd version does *not* use the string concatenation.
The 2nd version boils down to the very C++ dependant
operator(operator(operator(cout, usage),endl),...);
Yes, it does. What point are you trying to make by saying very C++ dependant?
Nearly all of
Julian Foad wrote:
Christian Mayer wrote:
Note: You 2nd version does *not* use the string concatenation.
The 2nd version boils down to the very C++ dependant
operator(operator(operator(cout, usage),endl),...);
Yes, it does. What point are you trying to make by saying very C++
Christian Mayer wrote:
I wanted to point out the very big (internal) differnce of the ANSI C
style
string1 string2
THat ends up as string1string2 in a normal array of char
vs.
The C++ way:
cout string1 string2
wich uses the operator() method.
Both are valid and have
So in the end, I'm not sure which is better. They each have their
pluses ...
Lets move it over to an XML file ...
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
* [EMAIL PROTECTED] (Curtis L. Olson) [2002.05.16 23:06]:
Update of /var/cvs/FlightGear-0.7/FlightGear/src/Main
In directory seneca:/tmp/cvs-serv26528/src/Main
Modified Files:
options.cxx
Log Message:
Bernie Bright:
To make MSVC happy it appears we need backslashes on string
MSVC was complaining about the latter. My solution was:
cout say\n\
what?\n\
;
Jonathan Polley
On Thursday, May 16, 2002, at 11:21 PM, Cameron Moore wrote:
* [EMAIL PROTECTED] (Curtis L. Olson) [2002.05.16 23:06]:
Update of /var/cvs/FlightGear-0.7/FlightGear/src/Main
In directory
David Megginson wrote:
Update of /var/cvs/FlightGear-0.7/FlightGear/src/Navaids
In directory seneca:/tmp/cvs-serv23071/src/Navaids
Modified Files:
fix.hxx ils.hxx nav.hxx
Log Message:
Mac OS X patches from Jonathan Polley.
*** 37,41
#elif defined(
Erik Hofman wrote:
David Megginson wrote:
Update of /var/cvs/FlightGear-0.7/FlightGear/src/Navaids
In directory seneca:/tmp/cvs-serv23071/src/Navaids
Modified Files:
fix.hxx ils.hxx nav.hxx
Log Message:
Mac OS X patches from Jonathan Polley.
*** 37,41
#elif
[re: FGControls::parking_brake]
Melchior FRANZ writes:
Yes, you are right. That should be 1.0!
David, could you change this, please? Sorry for the inconvenience.
Actually, it doesn't matter -- when the property is bound, FGControls
will pick up the default property value anyway. I will
Jim Wilson writes:
- add animations for the model as a whole
- add submodels
- add billboards
- add UV animations
Billboards-? you mean like those big signs they allow in other states? Is
animation for blinking aircraft lights included in the above?
No -- I
Hmmm, The bigger airports tend to use the same frequency for each end
of their runways. So this change will probably break half the
approaches at the major airports (KLAX, KMSP, KORD, KDFW, etc.)
I made a change to return the matching station that points most
directly at us. This should be the
Are you using scenery_center or next_scenery_center? It's been so
long I don't recall all the resoning, but next_scenery_center was made
available to the view manager so it can get the view position correct
even when we cross a tile boundary and the offsets change.
Regards,
Curt.
Jim Wilson
Curtis L. Olson [EMAIL PROTECTED] said:
Are you using scenery_center or next_scenery_center? It's been so
long I don't recall all the resoning, but next_scenery_center was made
available to the view manager so it can get the view position correct
even when we cross a tile boundary and the
David,
It sounds like you are bypassing SG_LOG() because it isn't doing what
you want. This seems like a bandaid solution at best. Perhaps we
should put these messages back in as SG_LOG( SG_ALERT ) and then
default 'release' builds to a minimum logging level of SG_ALERT rather
than collapsing
Curtis L. Olson writes:
It sounds like you are bypassing SG_LOG() because it isn't doing what
you want. This seems like a bandaid solution at best. Perhaps we
should put these messages back in as SG_LOG( SG_ALERT ) and then
default 'release' builds to a minimum logging level of
* [EMAIL PROTECTED] (Curtis L. Olson) [2002.03.21 08:58]:
Index: panel_io.cxx
===
RCS file: /var/cvs/FlightGear-0.7/FlightGear/src/Cockpit/panel_io.cxx,v
retrieving revision 1.36
retrieving revision 1.37
diff -C2 -r1.36 -r1.37
Cameron Moore wrote:
* [EMAIL PROTECTED] (Curtis L. Olson) [2002.03.21 08:58]:
Index: panel_io.cxx
===
RCS file: /var/cvs/FlightGear-0.7/FlightGear/src/Cockpit/panel_io.cxx,v
retrieving revision 1.36
retrieving revision
--- David Megginson [EMAIL PROTECTED] wrote:
Tony Peden writes:
Restoring a flight is not
working in a running FlightGear session because
of
JSBSim trim-routine
problems,
What is it doing (or not, as the case may be)?
It's not setting body velocities from the save
--- David Megginson [EMAIL PROTECTED] wrote:
Tony Peden writes:
Restoring a flight is not
working in a running FlightGear session because
of
JSBSim trim-routine
problems,
What is it doing (or not, as the case may be)?
It's not setting body velocities from the save
Bernie Bright wrote:
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.7/FlightGear/src/Cockpit
In directory seneca:/tmp/cvs-serv20681
Modified Files:
panel_io.cxx
Log Message:
Sgi doesn't define the != operator for string != char[] so we need to cast
the char array into a
David,
This is going to mess up rendering of distant mountains for people
with voodoo cards (i.e. 16 bit buffers).
Depth buffer precision is *very* sensitive to the near clip plane
distance:
http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html
I'm really nervous about forcing this
David Megginson writes:
Changed the near clip plane to 0.1f regardless. Previously, it jumped
to 10m after takeoff, but that doesn't really make sense any more,
especially if models are going to have interior views. Is there any
real saving in pushing the near plane out anyway?
On 5 Mar 2002, at 8:40, Curtis L. Olson wrote:
David,
This is going to mess up rendering of distant mountains for people
with voodoo cards (i.e. 16 bit buffers).
And not just 16 bit cards - I get flashing polygons in the sky with
two different 32 bit cards at 0.5, progressively cured by
Alex Perry writes:
and for the latter you're in ground haze in any case.
You Californians speak for yourselves!
:-)
Cheers - Dave
--
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Curtis L. Olson wrote:
I'm really nervous about forcing this down to 0.1 for all cases. This
will mess things up for people with voodoo cards.
Can we change this back?
Perhaps we need to do a separate pass for rendering the 3d model and
change the near clip plane just for that
Curt wrote:
Perhaps we need to do a separate pass for rendering the 3d model and
change the near clip plane just for that portion of the rendering.
Yes. That should be easy to do. BoB does it as well, they even have 3
or 4 different parts of the geometry that they render with 3 or 4
Alex Perry writes:
Putting the clip plane at 0.1 is an easy way to stop me doing demos of FGFS.
I don't _have_ a machine with better than 16 bit depth buffering, and the
notebook that I do most of the demos with cannot of course be upgraded.
I understand. How does everything look with
Andy Ross writes:
Or just turn the depth buffer off for the cockpit and sort the
geometry; for most cockpit layouts, this should be pretty feasible.
It won't work if the cockpit has moving parts (yokes or whatnot) that
obscure other pieces.
I don't think this is an easy option, at least
David Megginson [EMAIL PROTECTED] said:
I don't think this is an easy option, at least not with a true 3D
model wrapped around the viewer. We'll have to find a more robust
solution. To start, I can make the depth buffer 0.1 only when the
interior model view is enabled, so no one loses
Curtis L. Olson [EMAIL PROTECTED] said:
David,
Assuming all of this is being drawn via plib/ssg then you could put
all the geometry in a separate ssgRoot node and call ssgCullandDraw()
on this root after everything else has been rendered. We have a
couple ssgRoot's already so we can
Jim Wilson wrote:
Ummm...why not clear the z-buffer and use a seperate scene graph?
Note that there are *lots* of people using pre-geforce generation
hardware. Probably more than not.
Actually, it's those folks who are at risk. Clearing the whole z
buffer soaks up big chunks of
Or just turn the depth buffer off for the cockpit and sort the
geometry; for most cockpit layouts, this should be pretty feasible.
It won't work if the cockpit has moving parts (yokes or whatnot) that
obscure other pieces.
Even if they obscure, it is only a problem if they swap places so
David Luff writes:
Alex Perry writes:
and for the latter you're in ground haze in any case.
You Californians speak for yourselves!
[EMAIL PROTECTED]
Ya see, here the temperature is _above_ freezing and _not_ raining
at the same time 8-). I'll take poor visibility over days of drizzle...
On Tue, 2002-03-05 at 18:16, Alex Perry wrote:
David Luff writes:
Alex Perry writes:
and for the latter you're in ground haze in any case.
You Californians speak for yourselves!
[EMAIL PROTECTED]
Ya see, here the temperature is _above_ freezing and _not_ raining
at the same time
Jim Wilson writes:
Ummm...why not clear the z-buffer and use a seperate scene graph? Note that
there are *lots* of people using pre-geforce generation hardware. Probably
more than not.
Time -- I don't know if I'll have time to figure all that out this
week.
All the best,
David
--
Alex,
Try doing a make clean inside JSBSim and then rebuild everything.
Curt.
Alex Perry writes:
You likely don't notice any of this if you
are running a card with a 32bit depth buffer (i.e. geforce.)
Don't worry Curt, leave the change in, I don't see the problem on 16 bit ...
You likely don't notice any of this if you
are running a card with a 32bit depth buffer (i.e. geforce.)
Don't worry Curt, leave the change in, I don't see the problem on 16 bit
...
Loading tile /usr/local/lib/FlightGear/Scenery/w120n30/w118n32/1023667
ESC[1mESC[4mJSBSim Flight
13971 Segmentation fault
[you *are* joking, aren't you?!?!]
Err, no. Sorry. Curt suggest I recompile ... in progress ...
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
* [EMAIL PROTECTED] (Curtis L. Olson) [2002.01.17 09:25]:
! echo -n Running automake
! if [ $OSTYPE = IRIX -o $OSTYPE = IRIX64 ]; then
! echo --add-missing --include-deps
! automake --add-missing --include-deps
! else
! echo --add-missing
! automake --add-missing
! fi
Ok, thanks, this should now be installed for FlightGear and SimGear.
I'll work on TerraGear at some future time when I get a chance.
Curt.
Ross Golder writes:
This is how it appears to be set up for me:
In CVSROOT/loginfo, add the line :
DEFAULT $CVSROOT/CVSROOT/syncmail %{sVv}
[EMAIL
On Thu, 2001-12-13 at 03:48, David Megginson wrote:
Date: Wednesday December 12, 19101 @ 21:48
Author: david
Wow! What're things like in the year 19101, David? Has FlightGear 1.0
been release yet :o) ?
--
Ross
___
Flightgear-devel
Ross,
I believe what David was doing was adding the autogenerated files to
the .cvsignore files ... (threw me at first too.)
Curt.
Ross Golder writes:
Why add auto-generated files to the CVS repository?
I think it is generally considered (by other open source projects
anyway) a bad idea
Ross Golder writes:
Why add auto-generated files to the CVS repository?
I didn't -- I added config.h to .cvsignore, so that cvs won't complain
about an unknown file.
Modified Files:
.cvsignore
Log Message:
Added config.h, which is autogenerated.
All the best,
David
--
Phew! :-)
Did we get anywhere with adding cvs diff output to the cvslogs messages,
as per SourceForge? That would have made it a bit more obvious.
--
Ross
On Tue, 2001-12-11 at 21:43, Curtis L. Olson wrote:
Ross,
I believe what David was doing was adding the autogenerated files to
the
Ross Golder writes:
Did we get anywhere with adding cvs diff output to the cvslogs messages,
as per SourceForge? That would have made it a bit more obvious.
I think I'm losing email over the side of the bucket ... can someone
send a proper script to me directly?
Thanks,
Curt.
--
Curtis
601 - 698 of 698 matches
Mail list logo
