Maybe I'm misunderstanding why you are doing this. Lower pitch angle, fast
spinning prop. That doesn't makes sense?
Best,
Jim
Andy Ross said:
Update of /var/cvs/FlightGear-0.9/source/src/FDM/YASim
In directory baron:/tmp/cvs-serv7517
Modified Files:
Propeller.cpp
Log Message:
Jim Wilson wrote:
Maybe I'm misunderstanding why you are doing this. Lower pitch
angle, fast spinning prop. That doesn't makes sense?
Not pitch angle: A lower value of _j0 indicates a low advance ratio,
which increases windmilling speed. This was just a sign bug to the
previous checkin,
Andy Ross said:
Jim Wilson wrote:
Maybe I'm misunderstanding why you are doing this. Lower pitch
angle, fast spinning prop. That doesn't makes sense?
Not pitch angle: A lower value of _j0 indicates a low advance ratio,
which increases windmilling speed. This was just a sign bug to the
Jim Wilson wrote:
Is any of this addressing the low rpm propeller issue discussed last
week? (In other words, should I bother trying to correctly adjust
the p51d prop config yet?)
In theory, yes. I haven't had a whole lot of time to test it yet, but
the slow/windmilling propeller regime
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear/docs-mini
In directory baron:/tmp/cvs-serv6438
Added Files:
README.sound
Log Message:
Add an explanation for using Arts.
--- NEW FILE ---
ALSA and Arts
-
This article leads me
Martin Spott wrote:
ALSA and Arts
This article leads me to the assumption that OpenAL at least on Linux
is situated _always_ on top of the ALSA OSS emulation layer and does
not use the ALSA interface directly but I find it hard to believe
Why should I avoid directly using the ALSA layer
* Erik Hofman -- Wednesday 28 April 2004 13:22:
The major problem here is Arts that doesn't play nice with programs that
don't support Arts directly. This problem has annoyed me so much that if
I had to chose an desktop manager it would never be KDE until they
decide to stop using Art
Erik Hofman said:
Martin Spott wrote:
ALSA and Arts
This article leads me to the assumption that OpenAL at least on Linux
is situated _always_ on top of the ALSA OSS emulation layer and does
not use the ALSA interface directly but I find it hard to believe
Why should I avoid
* Melchior FRANZ -- Wednesday 28 April 2004 13:46:
- aRts can use ALSA
- KDE can play sound without aRts (AFAIK; haven't tried)
Oh, I forgot to mention: the main problems with aRts and ALSA seem
to lie in ALSA, at least for some chips (e.g. AC97). This improved
vastly in the latest 2.6.* Linux
Melchior FRANZ wrote:
* Melchior FRANZ -- Wednesday 28 April 2004 13:46:
- aRts can use ALSA
- KDE can play sound without aRts (AFAIK; haven't tried)
Oh, I forgot to mention: the main problems with aRts and ALSA seem
to lie in ALSA, at least for some chips (e.g. AC97). This improved
vastly in
* Erik Hofman -- Wednesday 28 April 2004 14:15:
Melchior FRANZ wrote:
Oh, I forgot to mention: the main problems with aRts and ALSA seem
to lie in ALSA, at least for some chips (e.g. AC97). This improved
vastly in the latest 2.6.* Linux kernels.
Sure, the most widely used sound option
Melchior FRANZ wrote:
* Erik Hofman -- Wednesday 28 April 2004 14:15:
Melchior FRANZ wrote:
Oh, I forgot to mention: the main problems with aRts and ALSA seem
to lie in ALSA, at least for some chips (e.g. AC97). This improved
vastly in the latest 2.6.* Linux kernels.
Sure, the most widely used
Jim Wilson wrote:
Is this still true? I'm running KDE and can't remember the last
time artsd got in the way. To be honest though, I don't recall what
changed. Maybe I just turned off most of the stupid sounds in the
kde apps.
My impression was that recent versions of arts and esd released
Erik Hofman said:
Update of /var/cvs/FlightGear-0.9/FlightGear/src/Input
In directory baron:/tmp/cvs-serv26245
Modified Files:
input.cxx input.hxx
Log Message:
Make it possible to define a target-platform tag in the joystick
configuration file. This would make it possible to have
* Jim Wilson -- Tuesday 27 April 2004 15:12:
Erik Hofman said:
Make it possible to define a target-platform tag in the joystick
configuration file. This would make it possible to have different
configuration files for Windows.
Just curious, why is this required?
Because Unix and Windows
Melchior FRANZ wrote:
* Jim Wilson -- Tuesday 27 April 2004 15:12:
Erik Hofman said:
Make it possible to define a tag in the joystick
configuration file. This would make it possible to have different
configuration files for Windows.
Just curious, why is this required?
Because
Jim Wilson wrote:
Erik Hofman checked in:
Make it possible to define a target-platform tag in the joystick
configuration file. This would make it possible to have different
configuration files for Windows. Possible values are: Windows, UNIX
or All. Not specifying the tag equals to 'All'.
* Frederic Bouvier -- Tuesday 27 April 2004 15:49:
Melchior FRANZ wrote:
Because Unix and Windows don't always agree on axis numeration.
In fact, they never agree. axis 2 3 are reverted, and the hat has
different numbering, for the same joystick name.
So we'd need two config files for
On Tue, 27 Apr 2004 06:58:41 -0700
Andy Ross [EMAIL PROTECTED] wrote:
Many/most of the joysticks don't work for windows users. They
download the program, try it, and then complain when the view is
constantly spinning around. One presumes the axis mappings are
simply different between the
Melchior FRANZ wrote:
So we'd need two config files for *every* joystick (with more than
two axes)? That's IMHO not acceptable. I'd rather prefer a mechanism
that makes one and the same config file work for both systems then.
After endless times of no discussion and no solutions I hacked
Erik Hofman wrote:
After endless times of no discussion and no solutions I hacked
something together that works for every situation. Not acceptable
won't do in this case unless I see something show up that is elegant
and that works in every situation.
Agreed. We need to get something
axes as defined in the file.
Richard
-Original Message-
From: Erik Hofman [mailto:[EMAIL PROTECTED]
Sent: 27 April 2004 3:21 pm
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Re: [Flightgear-cvslogs]CVS:
FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17
* Erik Hofman -- Tuesday 27 April 2004 16:21:
Melchior FRANZ wrote:
So we'd need two config files for *every* joystick (with more than
two axes)? That's IMHO not acceptable.
Not acceptable won't do in this case unless I see something show up
that is elegant and that works in every
On Dienstag, 27. April 2004 16:33, Melchior FRANZ wrote:
* Erik Hofman -- Tuesday 27 April 2004 16:21:
Melchior FRANZ wrote:
So we'd need two config files for *every* joystick (with more than
two axes)? That's IMHO not acceptable.
Not acceptable won't do in this case unless I see
Melchior FRANZ wrote:
* Erik Hofman -- Tuesday 27 April 2004 16:21:
Melchior FRANZ wrote:
So we'd need two config files for *every* joystick (with more than
two axes)? That's IMHO not acceptable.
Not acceptable won't do in this case unless I see something show up
that is elegant and that works
* Erik Hofman -- Tuesday 27 April 2004 16:37:
I bet you can come up with a clever solution where only the platform
specific part are in the actual configuration file and everything else
gets included from a shared file ...
axis unix=2 windows=3
descRudder/desc
binding
* Melchior FRANZ -- Tuesday 27 April 2004 16:49:
* Erik Hofman -- Tuesday 27 April 2004 16:37:
I bet you can come up with a clever solution where only the platform
specific part are in the actual configuration file and everything else
gets included from a shared file ...
axis
Melchior FRANZ wrote:
Whereby unix would be an alias for n and the line could also be
written as
axis n=2 windows=3
This is syntactically cleaner, but the code changes required are
severe. XML Attributes in property files are interpreted only by the
SimGear property parser, they aren't
* Andy Ross -- Tuesday 27 April 2004 17:23:
Melchior FRANZ wrote:
axis n=2 windows=3
This is syntactically cleaner, but the code changes required are
severe. XML Attributes in property files are interpreted only by the
SimGear property parser, they aren't available in the resulting
Melchior FRANZ wrote:
* Andy Ross -- Tuesday 27 April 2004 17:23:
Melchior FRANZ wrote:
axis n=2 windows=3
This is syntactically cleaner, but the code changes required are
severe. XML Attributes in property files are interpreted only by the
SimGear property parser, they aren't available in
* Erik Hofman -- Tuesday 27 April 2004 17:50:
Right now code other than SimGear's property I/O code can access the
attributes. To get this working I need to access them in FlightGear, but
every(?) attribute other than n= is disregarded...
I still don't get it. In props_io.cxx:164ff, why
* Melchior FRANZ -- Tuesday 27 April 2004 18:20:
winval = atts.getValue(n_win);// or windows
[...]
if (winval != -1 current_os == windows)
[...]
... assuming that a non existent attribute returns -1.
It's a string or char* and does of course return 0. :-)
m.
to virtual
axes as defined in the file.
Richard
-Original Message-
From: Erik Hofman [mailto:[EMAIL PROTECTED]
Sent: 27 April 2004 3:21 pm
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Re: [Flightgear-cvslogs]CVS:
FlightGear/src/Input input.cxx, 1.43
Curtis L. Olson wrote:
I should point out that the reason these were setup as cout was so
that we wouldn't lose all output if someone compiled with the
--without-logging option. Now that our default output is much less
verbose, people are probably not compiling with this option so it's
I should point out that the reason these were setup as cout was so
that we wouldn't lose all output if someone compiled with the
--without-logging option. Now that our default output is much less
verbose, people are probably not compiling with this option so it's
probably not a big deal ...
Curtis L. Olson wrote:
I should point out that the reason these were setup as cout was so
that we wouldn't lose all output if someone compiled with the
--without-logging option. Now that our default output is much less
verbose, people are probably not compiling with this option so it's
Curtis L. Olson wrote:
The other thing to consider is everyone seems to have one more fix
they'd like to get in. If we waited for everyone to be happy, we
literally would never be able to have a release. At some point we have
to draw the line and ship. The 0.9.4 release is simply the
David Megginson said:
Curtis L. Olson wrote:
The other thing to consider is everyone seems to have one more fix
they'd like to get in. If we waited for everyone to be happy, we
literally would never be able to have a release. At some point we have
to draw the line and ship. The
Jim Wilson wrote:
David Megginson said:
I would support a 4-week code freeze before 1.0, however, and I do think
it's just about time for a 1.0.
We're close, maybe next release, but I think we need to get the
subsystem/initialization thing straightened out first. Fred's fix for the
tilemanager
Jim Wilson wrote:
I would support a 4-week code freeze before 1.0, however, and I do think
it's just about time for a 1.0.
We're close, maybe next release, but I think we need to get the
subsystem/initialization thing straightened out first. Fred's fix for the
tilemanager last week
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/data/Aircraft/bo105/Models
In directory baron:/tmp/cvs-serv12689/Models
Modified Files:
bo105.ac bo105.xml
Added Files:
README bo105-1.rgb bo105.nas
Removed Files:
shadow.rgb
Log Message:
Melchior FRANZ:
- add
* Martin Spott -- Friday 26 March 2004 15:37:
Ha, there is a funny effect: Did you ever fly a loop which shadowing
enabled ? When I do this, I see the shadow flipping through the sky -
similar to a meteorite :-)
Whoops ... I'll look into it, but I don't promise a solution. (You aren't
Melchior FRANZ wrote:
* Martin Spott -- Friday 26 March 2004 15:37:
Ha, there is a funny effect: Did you ever fly a loop which shadowing
enabled ? When I do this, I see the shadow flipping through the sky -
similar to a meteorite :-)
Whoops ... I'll look into it, but I don't promise a
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/releases
In directory baron:/tmp/cvs-serv13253
Added Files:
FlightGear-0.9.4.tar.gz
Log Message:
Official 0.9.4 release.
Oooops, I wonder if we ever get the chance to do real testing before a
release. I'm very well aware that
Martin Spott wrote:
Oooops, I wonder if we ever get the chance to do real testing before a
release. I'm very well aware that this is primarily Curt's project but
on the other hand these surprisingly short pre-release stages make it
very hard for peripheral efforts to keep up with the release
On Friday 26 March 2004 23:35, Martin Spott wrote:
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/releases
In directory baron:/tmp/cvs-serv13253
Added Files:
FlightGear-0.9.4.tar.gz
Log Message:
Official 0.9.4 release.
Oooops, I wonder if we ever get the chance to do
On Friday 26 March 2004 23:43, Erik Hofman wrote:
Martin Spott wrote:
Oooops, I wonder if we ever get the chance to do real testing before a
release. I'm very well aware that this is primarily Curt's project but
on the other hand these surprisingly short pre-release stages make it
very
Martin Spott wrote:
Oooops, I wonder if we ever get the chance to do real testing before a
release. I'm very well aware that this is primarily Curt's project but
on the other hand these surprisingly short pre-release stages make it
very hard for peripheral efforts to keep up with the release
On Fri, 26 Mar 2004 17:28:12 -0600
Curtis L. Olson [EMAIL PROTECTED] wrote:
Martin Spott wrote:
Oooops, I wonder if we ever get the chance to do real testing before
a release. I'm very well aware that this is primarily Curt's project
I apologize if the schedule was a bit compressed, but I
Jon S Berndt wrote:
On Fri, 26 Mar 2004 17:28:12 -0600
Curtis L. Olson [EMAIL PROTECTED] wrote:
Martin Spott wrote:
Oooops, I wonder if we ever get the chance to do real testing before
a release. I'm very well aware that this is primarily Curt's project
I apologize if the schedule was a bit
Martin Spott said:
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/releases
In directory baron:/tmp/cvs-serv13253
Added Files:
FlightGear-0.9.4.tar.gz
Log Message:
Official 0.9.4 release.
Oooops, I wonder if we ever get the chance to do real testing before a
Melchior FRANZ wrote:
- texturing (no idea which livree; certainly not ADAC ;-)
I'd give a strong vote for something civilian,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
Curtis L. Olson said:
Jim Wilson wrote:
How about this one? ;-)
http://www.spiderbark.com/fgfs/barneymobile.png
Is that the don't-ask-don't-tellicopter.
Haha! Is this what they call aviation innuendo? What about these folks:
http://www.harrierpilot.com/oct01/purple.jpg
They
* Jim Wilson -- Thursday 25 March 2004 01:54:
How about this one? ;-)
http://www.spiderbark.com/fgfs/barneymobile.png
That's a nice color, indeed. But it doesn't really go well with the Red Cross.
I added it, because the long version of the Bo was constructed for use as
rescue helicopter. The
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/data/Aircraft/bo105/Models
In directory baron:/tmp/cvs-serv17582/Models
Modified Files:
bo105.ac bo105.xml shadow.rgb
Log Message:
New updates from Melchior in the color of the day.
Ooooh, I found the yellow one definitely nicer,
* Martin Spott -- Wednesday 24 March 2004 16:40:
Ooooh, I found the yellow one definitely nicer, it was a cute, coloured
spot in the colloection of mostly uniform coloured aircraft,
Hmm ... but the current one fits the seats better, doesn't it?
m.
* Martin Spott -- Wednesday 24 March 2004 16:40:
Ooooh, I found the yellow one definitely nicer, it was a cute, coloured
spot in the colloection of mostly uniform coloured aircraft,
Oh, well. Actually I like both versions. I just think that the yellow
one got a bit boring already, and that the
Melchior FRANZ said:
* Martin Spott -- Wednesday 24 March 2004 16:40:
Ooooh, I found the yellow one definitely nicer, it was a cute, coloured
spot in the colloection of mostly uniform coloured aircraft,
Oh, well. Actually I like both versions. I just think that the yellow
one got a bit
Jim Wilson wrote:
How about this one? ;-)
http://www.spiderbark.com/fgfs/barneymobile.png
Is that the don't-ask-don't-tellicopter.
Curt.
--
Curtis Olson Intelligent Vehicles Lab FlightGear Project
Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED]
Minnesota
On Wed, 24 Mar 2004 19:52:57 -0600,
Curtis L. Olson [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
Jim Wilson wrote:
How about this one? ;-)
http://www.spiderbark.com/fgfs/barneymobile.png
Is that the don't-ask-don't-tellicopter.
..using these names sounds like neat nice
Hi,
On Montag, 22. Mrz 2004 12:53, Martin Spott wrote:
Jim Wilson wrote:
Martin Spott said:
I'm sorry to say this but I can't resist to note that some of the
changes in your patch reverted David's the PA-28 rotates around it's
nose corrections.
I'm not aware of any difference of
Jim Wilson wrote:
Update of /var/cvs/FlightGear-0.9/data/Aircraft/pa28-161
In directory baron:/tmp/cvs-serv21723
Modified Files:
pa28-161-set.xml
Log Message:
Missed one.
Thanks,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
Hello,
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/source/utils/Modeller
In directory baron:/tmp/cvs-serv24024/utils/Modeller
Modified Files:
Makefile.am
Log Message:
Various final tweaks for the 0.9.4.pre1 release.
I appreciate very much having this pre-release
Martin Spott wrote:
Hello,
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/source/utils/Modeller
In directory baron:/tmp/cvs-serv24024/utils/Modeller
Modified Files:
Makefile.am
Log Message:
Various final tweaks for the 0.9.4.pre1 release.
I appreciate very much having
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/data/Scenery/w130n30/w123n37
In directory baron:/tmp/cvs-serv5777
Modified Files:
942050.stg
Log Message:
Put a sock in it.
Index: 942050.stg
===
RCS file:
Frederic Bouvier wrote:
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/data/Scenery/w130n30/w123n37
In directory baron:/tmp/cvs-serv5777
Modified Files:
942050.stg
Log Message:
Put a sock in it.
Index: 942050.stg
===
RCS file:
Martin Spott said:
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/source/src/FDM/YASim
In directory baron:/tmp/cvs-serv14214/src/FDM/YASim
Modified Files:
YASim.cxx
Log Message:
Jim Wilson:
Remove some hardcoded dependencies between fdm, viewer and acmodel
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/source/src/FDM/YASim
In directory baron:/tmp/cvs-serv14214/src/FDM/YASim
Modified Files:
YASim.cxx
Log Message:
Jim Wilson:
Remove some hardcoded dependencies between fdm, viewer and acmodel classes and
replaced them with
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/data/Aircraft/f16
In directory baron:/tmp/cvs-serv29648/f16
Modified Files:
f16-3d-set.xml f16-set.xml
Removed Files:
f16-3d-jsbsim-set.xml f16-jsbsim-set.xml
Log Message:
[...]
You should also modify this one:
isnix:
Martin Spott wrote:
You should also modify this one:
PropertyList include=f16-jsbsim-set.xml
^^
This is no longer present,
Thanks for catching this.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/source/src/FDM/UIUCModel
In directory baron:/tmp/cvs-serv19850/UIUCModel
Hehe, just when you thought it was a while back you heard from the UIUC
developers someone comes running out of their shelter just to throw a
bunch of new code at you
On Thu, 11 Mar 2004 20:07:10 -0500, David Megginson
[EMAIL PROTECTED] wrote:
Was this in PLIB 1.6, again? The alpha transparency is fine using the
CVS plib.
I'm pretty sure it was CVS plib.
--
Roy Vegard Ovesen
___
Flightgear-devel mailing list
Frederic Bouvier wrote:
Was this in PLIB 1.6, again? The alpha transparency is fine using the CVS
I am using the CVS plib and I am seeing this bug.
That's interesting -- is anyone else seeing this problem?
All the best,
David
___
Flightgear-devel
David Megginson wrote:
Frederic Bouvier wrote:
Was this in PLIB 1.6, again? The alpha transparency is fine using
the CVS
I am using the CVS plib and I am seeing this bug.
That's interesting -- is anyone else seeing this problem?
No, not for IRIX, not for Linux.
Erik
David Megginson wrote:
Frederic Bouvier wrote:
Was this in PLIB 1.6, again? The alpha transparency is fine using the CVS
I am using the CVS plib and I am seeing this bug.
That's interesting -- is anyone else seeing this problem?
I don't know for the original bug reporter, but I am
Frederic BOUVIER wrote:
I don't know for the original bug reporter, but I am using Windows and NVIDIA
if it is of any importance.
That could matter -- I'm using Linux and NVIDIA. Do you have trouble with
transparencies anywhere else? Do other people using Windows and NVIDIA see
a white
* David Megginson -- Friday 12 March 2004 15:29:
That's interesting -- is anyone else seeing this problem?
All needles are OK. The only bug that I see is the non-transparent
attitude 'needle': http://members.aon.at/mfranz/pa28.jpg
The SGI image seems to be OK, though (and I'm an SGI image expert
David Megginson wrote:
Frederic BOUVIER wrote:
I don't know for the original bug reporter, but I am using Windows and NVIDIA
if it is of any importance.
That could matter -- I'm using Linux and NVIDIA. Do you have trouble with
transparencies anywhere else? Do other people using
Melchior FRANZ wrote:
All needles are OK. The only bug that I see is the non-transparent
attitude 'needle': http://members.aon.at/mfranz/pa28.jpg
Yes -- I have that problem as well -- it has something to do with drawing order.
All the best,
David
___
* Melchior FRANZ -- Friday 12 March 2004 15:59:
All needles are OK. The only bug that I see is the non-transparent
attitude 'needle': http://members.aon.at/mfranz/pa28.jpg
The SGI image seems to be OK, though (and I'm an SGI image expert :-).
I'll look into plib ...
Yep, looks very much like
* David Megginson -- Friday 12 March 2004 16:21:
All needles are OK. The only bug that I see is the non-transparent
attitude 'needle': http://members.aon.at/mfranz/pa28.jpg
Yes -- I have that problem as well -- it has something to do with drawing order.
No. plib has a bug: it doesn't
David Megginson wrote :
Melchior FRANZ wrote:
All needles are OK. The only bug that I see is the non-transparent
attitude 'needle': http://members.aon.at/mfranz/pa28.jpg
Yes -- I have that problem as well -- it has something to do with drawing order.
I am confused. We were speaking
Melchior FRANZ wrote:
* Melchior FRANZ -- Friday 12 March 2004 15:59:
All needles are OK. The only bug that I see is the non-transparent
attitude 'needle': http://members.aon.at/mfranz/pa28.jpg
The SGI image seems to be OK, though (and I'm an SGI image expert :-).
I'll look into plib ...
Yep,
* Frederic BOUVIER -- Friday 12 March 2004 16:24:
I guess Melchior use Linux and he post a screenshot of what I am seeing.
plib bug. I'm working on a fix.
m.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
On Fri, 12 Mar 2004 10:03:00 -0500, David Megginson
[EMAIL PROTECTED] wrote:
Frederic BOUVIER wrote:
I don't know for the original bug reporter, but I am using Windows and
NVIDIA if it is of any importance.
That could matter -- I'm using Linux and NVIDIA. Do you have trouble
with
Frederic BOUVIER wrote:
Another thing that I noticed about the pa28 panel was the plane in the
TC was not transparent where it should be. The rgb file did have an
alpha channel but because the file was only 256 colors the alpha channel
was not transparent in FlightGear. It was OK when I opened it
Melchior FRANZ wrote:
No. plib has a bug: it doesn't recognize grayscale images with alpha layer yet.
See ssgLoadSGI.cxx:301, where the alpha information is wrongly written to the
blue layer, while the alpha layer is disabled. :-]
Ah -- that explains what's going on here. I had thought that the
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/data/Aircraft/sgs126/Panels
In directory baron:/tmp/cvs-serv22201/Panels
Modified Files:
glider-panel.xml
Log Message:
David Culp:
Here are two files for the sgs126. The sgs126-jsbsim-set.xml file now starts
the glider in the
Martin Spott wrote:
Erik Hofman wrote:
Here are two files for the sgs126. The sgs126-jsbsim-set.xml file now starts
the glider in the air by default. I think some people didn't know it is a
glider, [...]
I assume we already have two of them: The ASW-20 and the SGS 126 -
don't we ?
Yes, but
David Megginson wrote:
Update of /var/cvs/FlightGear-0.9/data/Aircraft/pa28-161/Models
In directory baron:/tmp/cvs-serv6690/Aircraft/pa28-161/Models
Modified Files:
pa28-161.ac panel.rgb
Added Files:
bench-back.rgb glareshield.rgb
Log Message:
Added textures for the back
Martin Spott wrote:
This aircraft gets really nice.
Thanks. The big breakthrough was my finally learning to use Blender to make
the textures (such as the panel plastics and screws) as well as the geometry
-- using a good 3D modeller with a bit of lighting can make even a
ham-fisted dolt like
Martin Spott writes:
David Megginson wrote:
Update of /var/cvs/FlightGear-0.9/data/Aircraft/pa28-161/Models
In directory baron:/tmp/cvs-serv6690/Aircraft/pa28-161/Models
Modified Files:
pa28-161.ac panel.rgb
Added Files:
bench-back.rgb glareshield.rgb
Log Message:
David Luff wrote:
I'll second that - it really is good. It looks really good, and at high
resolutions the frame rate is much better than the default - I've seen 60
(pa28) vs. 30 (c172) at some locations and resolutions.
The old (2D) panel code seemed to be the real killer, since I'm using much
On Thu, 11 Mar 2004 17:10:30 +, David Luff [EMAIL PROTECTED]
wrote:
One bug though - I don't see the instrument needles under Linux with an
NVidia card. I thought you simply hadn't done them, until I saw them
under Cygwin with an ATI card. I see the large tilting plane in the
turn
On Thu, 11 Mar 2004, David Megginson wrote:
I used geometry for the needles, and they must just be too narrow to show
up. It's strange, because I also use Linux+NVIDIA (GeForce2Go), and the
needles do show up on my system at 1600x1200.
In any case, I'll be switching to bigger quads with
Roy Vegard Ovesen wrote:
I too, experienced this, no needles in the instruments. I use a NVidia
card under Cygwin. After installing the cvs version of plib, the needles
appeared (I used to have plib 1.6.0).
Ah, yes -- the last official PLIB version has a bug (I can hardly consider
it a
David Megginson wrote:
Roy Vegard Ovesen wrote:
Another thing that I noticed about the pa28 panel was the plane in the
TC was not transparent where it should be. The rgb file did have an
alpha channel but because the file was only 256 colors the alpha channel
was not transparent in
On Fri, 27 Feb 2004 17:37:48 +0100 (CET)
Frederic BOUVIER wrote:
Erik Hofman wrote:
David Megginson wrote:
Martin Spott wrote:
Great idea - unfortunately 'fgfs' now dies with a segmentation fault
just a split second after the FlightGear window appears (Linux),
Yes, I
It's fixed in CVS now... Thanks !
--
Jorge Van Hemelryck
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Erik Hofman wrote:
Modified Files:
radar_misc.rgb
Log Message:
Add support for a storm blib
Excellent.
As far as I know, civilian airliners carry radar that is capable only of
detecting weather, not small things like aircraft. They also use a separate
radar system for ground separation (the
201 - 300 of 537 matches
Mail list logo
