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}
> [E
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 do
> 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?
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
> 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.
> 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 Dynamics
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 Fl
> > 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
> > > 13971 Segmentation fault
> > [you *are* joking, aren't you?!?!]
> Err, no. Sorry. Curt suggest I recompile ... in progress ...
Ok, that fixed it (dunno what it was).
I'm getting zbuffer fighting in the distance a little bit, but it's minor
compared to the junk you get when cloud layers
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
> Modified Files:
> fg_props.cxx
> Log Message:
> More work on saving and restoring flights.
> 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)?
* [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 -r
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 wr
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
* [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 strin
> 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
"Curtis L. Olson" wrote:
> Update of /var/cvs/FlightGear-0.9/releases
> In directory baron:/tmp/cvs-serv18174
> Added Files:
> FlightGear-0.9.6.tar.gz
> Log Message:
> Official source release for v0.9.6
I'm asking just to find out: Do we all agree that it makes much sense
to build the up
Frederic Bouvier wrote:
> Sent: 12 October 2004 18:12
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
> releasesFlightGear-0.9.6.tar.gz, NONE,
>
> Martin Spott wrote:
>
> > "Curtis L. Olson" wrote:
&g
Vivian Meazza wrote:
> Frederic Bouvier wrote:
>
> > Sent: 12 October 2004 18:12
> > To: FlightGear developers discussions
> > Subject: Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
> > releasesFlightGear-0.9.6.tar.gz, NONE,
> >
> > Martin Spot
Jon Berndt wrote:
Erik Hofman wrote:
Add a protocol for the ACMS protocol which seems to be used as an
output format for black-box data flight data. This configuration
does not work directly since there is no FDM available that reads
the accelerations from the property tree and translates them int
Erik Hofman writes:
> Jon Berndt wrote:
> >>Erik Hofman wrote:
> >>
> >>
> >>>Add a protocol for the ACMS protocol which seems to be used as an
> >>>output format for black-box data flight data. This configuration
> >>>does not work directly since there is no FDM available that reads
> >>>the accel
* Vivian Meazza -- Tuesday 16 November 2004 18:06:
> Melchior FRANZ wrote:
> > OBJECT_SHARED Models/Geometry/Nimitz/nimitz.ac -122.590 37.76 -7.0 90
>
> It should work just with the ... stuff in my earlier post.
Yes. Changed that now.
> Mathias has put all the necessary stuff here:
>
> ftp:/
* Mathias Fröhlich -- Wednesday 17 November 2004 21:42:
> On Mittwoch 17 November 2004 11:29, Melchior FRANZ wrote:
> > * I observed one segfault that I hadn't seen before. The bt, however,
> > didn't look like it had anything to do with the new code. I haven't saved
> > the core file but will do s
On Tue, 30 Nov 2004 14:55:29 + (UTC), Martin Spott
<[EMAIL PROTECTED]>
> Hm ? I thought Curt just made it working with stock PLIB - is it still
> broken ?
It uses the AC3D crease directive, which stock plib doesn't support.
More importantly, FlightGear still tries to load the Nimitz even whe
David Megginson wrote:
On Tue, 30 Nov 2004 14:55:29 + (UTC), Martin Spott
<[EMAIL PROTECTED]>
Hm ? I thought Curt just made it working with stock PLIB - is it still
broken ?
It uses the AC3D crease directive, which stock plib doesn't support.
At 03:47 today.
Modified Files:
nimitz.ac
Log
Erik Hofman wrote:
> Update of /var/cvs/FlightGear-0.9/data/Models/Weather
> In directory baron:/tmp/cvs-serv28318/Models/Weather
>
> Added Files:
> rain.ac rain.rgb rain.xml
> Log Message:
> Add a basic model for rain. Test w. the pc-7
This looks quite interesting but I realize that this
Erik Hofman wrote:
> Update of /var/cvs/FlightGear-0.9/data/Models/Weather
> In directory baron:/tmp/cvs-serv5714
>
> Modified Files:
> rain.ac rain.xml
> Log Message:
> Model changes and add some select's.
Great idea, especially because there's no 'cigar' around the cockpit
anymore ;-)
Martin Spott wrote:
The model looks very nice and the handling feels pretty easy. It's only
Thanks.
that I'm missing the cabin door being coupled to the parking brake as
it was in your first version ;-)
No, it's not ...
:-)
Erik
___
Flightgear-devel mail
"Curtis L. Olson" wrote:
> Update of /var/cvs/FlightGear-0.9/source/src/Network
> In directory baron:/tmp/cvs-serv347
>
> Modified Files:
> net_ctrls.hxx net_fdm.hxx
> Log Message:
> 32 bit integers are somewhat magical and handled pretty well across platforms
> in terms of predictable pack
Martin Spott wrote:
Modified Files:
AIAircraft.cxx
Log Message:
Solaris fixes
^^
+ #elif defined(sun) || defined(sgi)
+ # include ^^^
Hehe ;-)
Thanks for applying these fixes !
So far for my hope to sneak it in ;-)
Erik
___
Flightgear-d
Melchior Franz wrote:
> Update of /var/cvs/FlightGear-0.9/data/Models/Airport
> In directory baron:/tmp/cvs-serv27845
> Modified Files:
> beacon.xml beacon.ac
Jon, are you going to update the respective entry in our database ?
Martin.
--
Unix _IS_ user friendly - it's just selective abo
* Jon Stockill -- Sunday 29 May 2005 20:38:
> Martin Spott wrote:
> > Melchior Franz wrote:
> > > Modified Files:
> > > beacon.xml beacon.ac
> >
> > Jon, are you going to update the respective entry in our database ?
>
> [...] there are database entries for the objects in the base package just
* Jon Stockill -- Sunday 29 May 2005 21:02:
> Melchior FRANZ wrote:
> > With these changes most of the 950 faces are invisible to the ground cache.
> > There's only a simple invisible pyramid instead for intersection tests.
> Is this something that people should consider for any high poly
> struc
* Frederic Bouvier -- Sunday 29 May 2005 21:32:
> Melchior FRANZ a écrit :
>
> >In less verbosity: this technique does only make sense for objects with high
> >face
> >*density*, not high face *number*.
> >
> The beacon has a lot of vertical, or near vertical, faces.
I saw them when I edited i
* Melchior FRANZ -- Sunday 29 May 2005 21:23:
> * Jon Stockill -- Sunday 29 May 2005 21:02:
> > Melchior FRANZ wrote:
> > > With these changes most of the 950 faces are invisible to the ground
> > > cache.
> > > There's only a simple invisible pyramid instead for intersection tests.
>
> > Is this
Erik Hofman wrote:
> Update of /var/cvs/FlightGear-0.9/FlightGear/src/FDM
> In directory baron:/tmp/cvs-serv27859/FDM
>
> Modified Files:
> groundcache.cxx
> Log Message:
> Mathias Fröhlich:
>
> this is basically the past patch I sent to the list and which should now
> really (...!?!?) fi
* Martin Spott -- Thursday 02 June 2005 13:35:
> > Mathias Fröhlich:
> >
> > this is basically the past patch I sent to the list and which should now
> > really (...!?!?) fix the no ground below aircraft problem.
>
> Unfortunately the 'quick hack' was a better solution for my setup.
> Could you
Martin Spott wrote:
> Update of /var/cvs/FlightGear-0.9/docs/getstart/pdf
> In directory baron:/tmp/cvs-serv13049/pdf
> Modified Files:
> FGShortRef.pdf getstart.pdf
> Log Message:
>
> Forgot an update, build with newer pdfTeX.
BTW, did we have a consensus on the use of EMAil addresses in
"Curtis L. Olson" wrote:
> Update of /var/cvs/FlightGear-0.9/source/utils/GPSsmooth
> In directory baron:/tmp/cvs-serv15890
>
> Modified Files:
> Makefile.am
> Log Message:
> Attempt to add -lwinmm for windows builds (untested.)
I'd like to suggest another fix, as the IRIX build lacks "-lm
Martin Spott wrote:
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear/utils/GPSsmooth
In directory baron:/tmp/cvs-serv8203
Modified Files:
Makefile.am
Log Message:
IRIX fixes.
Thanks - works,
'course it works, it's tested on IRIX :-)
Erik
Martin Spott wrote:
Solaris needs '$(X_EXTRA_LIBS)' as well to resolve dependencies that
are introduced by '-lplibnet',
Does $(opengl_LIBS) work as well?
Erik
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.
Melchior Franz wrote:
> Update of /var/cvs/FlightGear-0.9/data/gui
> In directory baron:/tmp/cvs-serv29971
Ich seh' schon, waehrend die Mehrheit in Urlaub faehrt, baust Du in der
Zwischenzeit den halben FlightGear um :-)
Tschuess,
Martin.
--
Unix _IS_ user friendly - it's just selectiv
* Martin Spott -- Saturday 09 July 2005 11:51:
> Ich seh' schon, waehrend die Mehrheit in Urlaub faehrt, baust Du in der
> Zwischenzeit den halben FlightGear um :-)
No, I'm not going to rewrite fgfs while the others are on vacation. :-)
Although these changes look extensive, they aren't really.
"Curtis L. Olson" wrote:
> Update of /var/cvs/FlightGear-0.9/data/Aircraft/BAC-TSR2/Models
> In directory baron:/tmp/cvs-serv26968/Models
> Modified Files:
> BAC-TSR2-model.xml
[...]
I really like this aircraft - it spreads some sort of 'charisma', very
much like the Concorde !
Thanks,
Martin Spott wrote:
Hello Erik,
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear
In directory baron:/tmp/cvs-serv29428
Modified Files:
configure.ac
Log Message:
Prepare for OpenAL 1.1 and a separate alut lubrary.
Did you actually manage to compile current OpenAL CVS on IR
Erik Hofman wrote:
> Update of /var/cvs/FlightGear-0.9/data/Aircraft/c150/Models/Vintage
> In directory baron:/tmp/cvs-serv14308/Models/Vintage
>
> Added Files:
> README.TXT c150-01.rgb c150-02.rgb c150-int.rgb c150-int2.rgb
> Log Message:
> Add Mark Miller's c150 vintage look livery.
> (Se
> 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 _
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 creat
Michael Basler wrote:
>
> 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.
>
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 t
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.
>
>
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
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 maski
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 co
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 I'll only have t
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 n
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.
> >
> > So
Erik Hofman <[EMAIL PROTECTED]> wrote:
> Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main
> In directory seneca:/tmp/cvs-serv12094/src/Main
> Modified Files:
> main.cxx
> Log Message:
> Andy wrote:
> This is just a port of an old 3D HUD patch to the new view code.
Oh yeah, this looks
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main
In directory seneca:/tmp/cvs-serv13494
Modified Files:
fg_commands.cxx
Log Message:
Don't start paused for in air starts.
Do you think this is a good idea?
Wouldn't it be better to sepecify this in the command line?
Erik
[Originally sent to [EMAIL PROTECTED] by mistake.]
Curtis L. Olson writes:
> With these changes, the GS will bring you in precisely to the
> touchdown point as defined in the default.ils.gz file (it wouldn't
> before.) The only issue that remains is that it will bring you in
> to the elevati
Curtis L. Olson writes:
> You bastards! Writing property names to char arrays that are too short for
> the data you are putting in it. :-( Fixed ...
> for (index = 0; index < MAX_ENGINES; index++) {
> ! char name[32];
> sprintf(name, "/controls/engines/engine[%d]/throttle", i
David Megginson writes:
> Curtis L. Olson writes:
>
> > Modified Files:
> >default.ils.gz
> > Log Message:
> > Align all the approaches I could automatically match up to runways.
>
> Where we have exact data on the lat/lon of the localizer and GS, we
> should use it, and fix our airport
Curtis L. Olson writes:
> The problem is that I have two data sets both providing "exact"
> locations for the localizer and both disagreeing significantly on the
> position and orientation. :-(
We have to decide on the authority of each data point individually.
Anything that we get from the DA
David Megginson writes:
> We have to decide on the authority of each data point individually.
> Anything that we get from the DAFIF or FAA data should stand as-is,
> for example. For Robin Peel's data, we should fix things only when
> there is a known problem.
The problem is that in my spot check
Curtis L. Olson writes:
> I don't know if either DAFIF or FAA could be considered
> "authoritative".
I'd consider FAA authoritative for U.S. airports, and DAFIF for other
countries, again, until proven otherwise.
> I'm guessing that when an ILS is installed, someone goes out and
> stands at
Jim Wilson writes:
> Sigh... can't we just leave this the way it was for now and tell people that
> we recommend a 3 axis stick??? :-/ If not we need time to check the joystick
> configs (and I don't have time to do the two I have today). I'd much rather
> see this patch added right after releas
Jim Wilson wrote:
Hi Erik,
I'm not sure what you mean by "saner values" for everything else. These
values only affect the contrast, specifically the darkness of the shadows.
Take a look at this screenshot. The shaded part of the aircraft (and
buildings but thats hard to see) is much too bright.
Erik Hofman <[EMAIL PROTECTED]> said:
> Take a look at this screenshot. The shaded part of the aircraft (and
> buildings but thats hard to see) is much too bright. It's almost like it
> is about four our earlier (and very foggy):
>
>
> http://www.a1.nl/~ehofman/fgfs/download/f104-dawn.jpg
>
>
Jim Wilson wrote:
Erik Hofman <[EMAIL PROTECTED]> said:
What I'm trying to do now is get every lighting state to a completely
sunny day with almost unlimited visibility. From there the state should
be adjusted based on visibility, number of cloud layers and cloud types.
That would be much easie
Erik Hofman <[EMAIL PROTECTED]> said:
> I can overwhelm you with pictures of other simulators that show this
> isn't the right lighting for these situations...
There is no "right" unless you can simulate the eye/brain, which you cannot.
The eye is going to make it brighter than it really is at
Jim Wilson wrote:
Erik Hofman <[EMAIL PROTECTED]> said:
a. We are in the open terrain.
b. It is a clear sky and there is almost unlimited visibility.
Are you saying that the lighting would then be adjustable based on view? You
didn't infer that earlier. If so, I'll sit tight.
This means high
Martin Spott wrote:
The F-50 has evolved to a really nice aircraft. But there are still a few
issues that appear very strange to me:
1.) I need do accelerate the aircraft up to almost 200 knots before I manage
to lift the nose. After this is done, the aircraft has an impressive
climb rate
On Friday, September 5, 2003, at 03:12 pm, Martin Spott wrote:
3.) I know, you should not employ the flaps at 200 kts
But if you do so, the aircraft climbs like attached to a high
speed elevator :-)
I've been flying the Fokker 100 quite a bit, and I've noticed similar
instabilities
On Fri, 5 Sep 2003 16:01:59 +0100
James Turner <[EMAIL PROTECTED]> wrote:
- a similar elevator effect to that martin described,
when deploying the flaps at high speeds
- very odd high pitch angle behavior ... I can't really
describe it, alas. It seems like way too much lift is
getting developed
James Turner wrote:
I've been flying the Fokker 100 quite a bit, and I've noticed similar
instabilities. Roughly (I am not a pilot)
- very rapid control response, especially on the roll axis). This
sometimes extends to a 'snap' condition where I command an aileron
reversal (okay, I just pull
"Curtis L. Olson" <[EMAIL PROTECTED]> wrote:
> Update of /var/cvs/FlightGear-0.9/data/Airports
> In directory baron:/tmp/cvs-serv7323
> Modified Files:
> basic.dat.gz
> Log Message:
> Updated airport data (including new airports from Robin Peel.)
Wohoo, he even includes Chambley Airbase in
On Fri, 2003-09-05 at 08:01, James Turner wrote:
> On Friday, September 5, 2003, at 03:12 pm, Martin Spott wrote:
>
> > 3.) I know, you should not employ the flaps at 200 kts
> > But if you do so, the aircraft climbs like attached to a high
> > speed elevator :-)
>
> I've been flyi
Erik Hofman <[EMAIL PROTECTED]> wrote:
> Update of /var/cvs/FlightGear-0.9/FlightGear/src/Cockpit
> In directory baron:/tmp/cvs-serv26208
> Modified Files:
> panel.cxx
Although this improves the altimeter display in the default aircraft,
the c310u3a-3d looks a bit strange now at my end:
h
Erik Hofman <[EMAIL PROTECTED]> wrote:
> Update of /var/cvs/FlightGear-0.9/FlightGear/src/Cockpit
> In directory baron:/tmp/cvs-serv3773
> Modified Files:
> panel.cxx
> Log Message:
> Try to prevent z-buffer problems for video cards with a 16-bit depth buffer
_Slight_ improvement on a 24 b
Erik Hofman <[EMAIL PROTECTED]> wrote:
> Update of /var/cvs/FlightGear-0.9/FlightGear/src/Cockpit
> In directory baron:/tmp/cvs-serv8404
> Modified Files:
> panel.cxx
> Log Message:
> Don't just disable depth buffer writes but instead disable the depth test all
> together
By accident my m
"Curtis L. Olson" <[EMAIL PROTECTED]> wrote:
> Update of /var/cvs/FlightGear-0.9/www/Docs/InstallGuide
> In directory baron:/tmp/cvs-serv19466/Docs/InstallGuide
> Modified Files:
> getstart.html getstartap1.html getstartap2.html
> getstartap3.html getstartch1.html getstartch2.html
>
Martin Spott writes:
> "Curtis L. Olson" <[EMAIL PROTECTED]> wrote:
> > Update of /var/cvs/FlightGear-0.9/www/Docs/InstallGuide
> > In directory baron:/tmp/cvs-serv29188/Docs/InstallGuide
>
> > Modified Files:
> > getstart.css getstart.html getstartap1.html getstartap2.html
> > getstartap
"Curtis L. Olson" wrote:
> Update of /var/cvs/FlightGear-0.9/source/src/Systems
> In directory baron:/tmp/cvs-serv25673
>
> Modified Files:
> vacuum.cxx vacuum.hxx
> Log Message:
> Allow a single vacuum system to be driven by multiple pumps.
That's fine. This topic becomes even more intere
Erik Hofman wrote:
> Update of /var/cvs/FlightGear-0.9/FlightGear/src/ATC
> In directory baron:/tmp/cvs-serv30924/src/ATC
[...]
> * Use "const string&" rather than "string" in function calls when appropriate.
[...]
I have the impression that the changes to the FlightGear subtree didn't
make it in
On Sunday 27 November 2005 05:19 pm, Martin Spott wrote:
> > Sets correctly the VRP at the nose :
>
> Yep, the VRP appears actually to be located at the nose, but the offset
> to the CG is still missing :-)
> Have a try, look at the aircraft from an outside view (chase view w/o
> yaw), activate t
Hello Curt,
"Curtis L. Olson" wrote:
> Update of /var/cvs/FlightGear-0.9/data/Aircraft/Rascal
> In directory baron:/tmp/cvs-serv29111
>
> Added Files:
> README.Rascal Rascal110-set.xml Rascal110.xml
> rascal-electrical.xml thumbnail.jpg
[...]
> yasim
> Rascal110
> 0.8
I'm ver
Martin Spott wrote:
Erik Hofman <[EMAIL PROTECTED]> wrote:
Update of /var/cvs/FlightGear-0.9/data/Models/Geometry
In directory baron:/tmp/cvs-serv27779
Added Files:
frighter.ac
Shou?ld this ship frighten us ? ;-)
Only if it's directly above you ...
Erik
___
Am Montag, 2. Februar 2004 11:51 schrieb Melchior FRANZ:
> Don't know. I'm Austrian.
> No, seriously: I can't stand German keyboards. Their layout is brain-dead,
> so I'm using an US-American one. I'd say that it's up to those who suffer
> the most to fix the unfortunate situation. (I use the compo
> The places where they put "unimportant" things like @, [, ], {, }, \,
> etc. Face it: German keyboards may be suitable for secretaries or poets,
> but they are a royal pain for technical stuff like programming.
If you look back in history (damn, I'm not that old) keyboards _have_ been
designed
Am Montag, 2. Februar 2004 23:38 schrieb Melchior FRANZ:
> Who? The Empress? She was actually called Sisi ...
http://dict.leo.org/?search=sissy&lang=de
> That a solution for non-US-keyboards is necessary was never argued about,
> and actually discussed a few times already. It's just that nobody f
Martin Spott wrote:
Hello David, I like your PA-28 very much, but I can't resist to note
that there is one 'feature' that is really annoying (I must admit that
this word is a bit too strong in this context !):
At least in the outside views the aircraft rotate around its nose.
It's difficult to tel
> > Hello David, I like your PA-28 very much, but I can't resist to note
> > that there is one 'feature' that is really annoying (I must admit that
> > this word is a bit too strong in this context !):
> > At least in the outside views the aircraft rotate around its nose.
> > It's difficult to tell
David Megginson <[EMAIL PROTECTED]> said:
> Martin Spott wrote:
>
> > Hello David, I like your PA-28 very much, but I can't resist to note
> > that there is one 'feature' that is really annoying (I must admit that
> > this word is a bit too strong in this context !):
> > At least in the outside v
Jim Wilson wrote:
Actually, it isn't that. It is just the location that the "camera" points to.
You don't want it pointing at the nose. So add the entry below to the
external views in your xml wrapper that track the plane. The value is the
distance in meters from the FDM reference point (the n
David Megginson wrote:
Thanks -- that did the trick. The plane is actually flying well, and
I'm starting to feel tempted to go back and do more work to make it a
fully-usable alternative to the [EMAIL PROTECTED]@#na 172 -- after all, it would be
nice for users to be able to fly a light single w
David Megginson <[EMAIL PROTECTED]> said:
> I wonder if we can model the broken air vent door on the pilot's side that
> blows -35 degC air on my feet when I'm flying in the winter.
It's already there (parameter: --frostbite=mins where mins is number of
minutes before you lose your toes). With
Jim Wilson wrote:
I wonder if we can model the broken air vent door on the pilot's side that
blows -35 degC air on my feet when I'm flying in the winter.
It's already there (parameter: --frostbite=mins where mins is number of
minutes before you lose your toes). With that all you need is an old
a
-0.7
That should do the trick :)
David Megginson wrote:
Jim Wilson wrote:
Actually, it isn't that. It is just the location that the "camera"
points to.
You don't want it pointing at the nose. So add the entry below to the
external views in your xml wrapper that track the plane. The val
201 - 300 of 591 matches
Mail list logo