Hi,
OK, changing the fgstream.hxx to sgstream.hxx seams to
work for that problem but doing that started an
avalanche of undefined symbols. I have started to
change these from FG to SG but it seams that there are
about a million of them.
So I have took the CVS advice.
The CVS readme also wrote t
> David Megginson writes:
> > To simulate windshear properly (i.e. in the right place at the right
> > time and magnitude), we would need to do a lot of meteorological work
> > that we're not doing right now. However, you can get the effect of
> > windshear by specifying a large gust factor
> >
>
On Wed, 2003-02-19 at 20:21, Curtis L. Olson wrote:
> David Megginson writes:
> > To simulate windshear properly (i.e. in the right place at the right
> > time and magnitude), we would need to do a lot of meteorological work
> > that we're not doing right now. However, you can get the effect of
>
David Megginson writes:
> To simulate windshear properly (i.e. in the right place at the right
> time and magnitude), we would need to do a lot of meteorological work
> that we're not doing right now. However, you can get the effect of
> windshear by specifying a large gust factor
>
> fgfs --wi
David Culp writes:
> > It looks like there is code that is *supposed* to
> > subtract the wind from the airspeed, but it obviously isn't working.
>
> This made me curious. Does FlightGear simulate windshear?
To simulate windshear properly (i.e. in the right place at the right
time and magni
Felix Kühling writes:
> Actually I saw this effect before and reported it to dri-devel. IIRC I
> also found out that the direction in which you have to bank depends on
> the simulated time of day, or in other words, the direction of the light
> source. Unfortunately I was not able to reproduce the
On Wed, 19 Feb 2003 23:06:33 +0100
Martin Spott <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 19, 2003 at 10:47:30PM +0100, Felix Kühling wrote:
> [... for German readers only ;-) ]
>
> > Also, die vierte Koordinate ist wahrscheinlich nicht das Problem. Ich
> > hab ein paar Debugausgaben in Mes
> It looks like there is code that is *supposed* to
> subtract the wind from the airspeed, but it obviously isn't working.
This made me curious. Does FlightGear simulate windshear?
Dave
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail
On Wed, Feb 19, 2003 at 11:46:49PM +0100, Felix Kühling wrote:
> On Wed, 19 Feb 2003 23:06:33 +0100 Martin Spott <[EMAIL PROTECTED]> wrote:
> > I just found out by accident how to get correct lightning in FlightGear with
> > current DRI drivers _and_ HW-TCL: Just look straight out of the cockpit a
* David Megginson -- Wednesday 19 February 2003 19:55:
> There must be some kind of gamma parameter available for the X11
> config file.
Yes.
$ xgamma -gamma 1.3# with different values ...
then add this value to your /etc/X11/XF86config, section "Monitor":
Section "Monitor"
Vert
On Wed, Feb 19, 2003 at 10:47:30PM +0100, Felix Kühling wrote:
[... for German readers only ;-) ]
> Also, die vierte Koordinate ist wahrscheinlich nicht das Problem. Ich
> hab ein paar Debugausgaben in Mesa eingebaut, und die bestätigen, dass
> die vierte Koordinate immer 0.0 ist.
I just f
> I'm afraid you are on the wrong track.
To be honest: I _did_ expect something like that ;-)
> Emissive, is just what it says. It adds light emission to the textures
> (to make them brighter).
Yep, this looks quite 'cool' at night
I recieved some explanation from Felix. He is talking ab
Erik Hofman writes:
> I'm afraid you are on the wrong track.
> Emissive, is just what it says. It adds light emission to the textures
> (to make them brighter).
That's right. If you want to see what happens, try the same thing at
night, and the whole world will be flood-lit. There must be s
Emmissive means the light the object inherently generates. So if you
were drawing a small light at a distance (i.e. a christmas tree light)
you would set the emmissive RGB component to whatever gives you the
proper light color. This means that no matter what happens else where
with lighting, the
Martin Spott writes:
> They _are_ all set to zero by default. I tried 0.5 and 1.0 - but still
> without noticeable effect. Felix is talking about an uninitialized 4th
> component of "light position", so it would be likely be another place to
> look for. I still remember seeing changing colours duri
Martin Spott wrote:
I have something interesting on the topic - it boils down to fiddling with
the RGB values for "the emissive light colour for the material" in
'materials.xml'. I have a handfull of screenshots for you to compare.
With hardware-TCL, 'emissive' RGB values set to 0.0 (current defa
> Could you guys please find out if this makes noticeable differences on other
> platforms than Linux/DRI/Radeon ? Maybe we're dony by simply changing these
> defaults.
I forgot to post the URL for the patch:
ftp://ftp.ihg.uni-duisburg.de/FlightGear/Devel/materials.xml.diff
in case your ed
I have something interesting on the topic - it boils down to fiddling with
the RGB values for "the emissive light colour for the material" in
'materials.xml'. I have a handfull of screenshots for you to compare.
With hardware-TCL, 'emissive' RGB values set to 0.0 (current default):
http://documen
> One extra step would be setting all and values for
> to zero also. If that doesn't work the problem is probably
> not related.
Because I was tired fiddling with thousands of sections in 'materials.xml' I
just used search 'n replace to modify _everything_ to 0.5 that was set to
0.0 by defau
David Megginson writes:
> Hmm. Should the fourth last line be this instead?
>
> Math::vmul33(s->orient, v, v); // to body coordinates
>
> I'll give it a try.
Yes, that was it.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
David Megginson wrote:
> Hmm. Should the fourth last line be this instead?
>
>Math::vmul33(s->orient, v, v); // to body coordinates
Bingo. Good catch. If that's not the bug, then it's *a* bug. :)
Andy
--
Andrew J. RossBeyond the OrdinaryPlausibility Producti
Erik,
> One extra step would be setting all and values for
> to zero also.
They _are_ all set to zero by default. I tried 0.5 and 1.0 - but still
without noticeable effect. Felix is talking about an uninitialized 4th
component of "light position", so it would be likely be another place to
lo
Curt,
> [...] I'd be happy to take
> another look at something you think is questionable if you point me to
> where it is.
Investigation is in progress,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
-
Andy Ross writes:
> Is the problem with the CAS output number, or is the whole
> simulator ignoring the wind?
Fortunately, it's just the CAS output number. I tried doing a
full-stall landing into a 25 kt headwind in the J3 Cub and was able to
set it straight down like a helicopter -- it's just
All
First I want to thank you guys for this incredibly interesting
project. I have always been interested in flight simulators and
being a
programmer also wondered how they were coded. Thanks to the
FlightGear project I will finally find out.
Not being a
David Megginson wrote:
> Before I plunge in to try to fix this, does Andy (or anyone else)
> have any suggestions? It looks like there is code that is
> *supposed* to subtract the wind from the airspeed, but it obviously
> isn't working.
Eeew, that sounds bad. Like you said, I'm pretty sure this
David Megginson wrote:
> Dave Perry writes:
> > I flew the j3cub again and I take back my assesment of the climb and
> > glide. It appears that it starts with significant nose down trim.
>
> The Cub should start at neutral trim -- is there something else
> (i.e. your joystick) pushing the trim for
On Wed, 19 Feb 2003 15:48:35 +0100
[EMAIL PROTECTED] (Michael Basler) wrote:
John,
the correct link ist of course:
www.nasawatch.com
Regards, Michael
Thanks.
And to think I proofread that posting before I made it ...
Jon
___
Flightgear-devel ma
I've found a serious, and surprisingly not-previously-detected YASim
bug. The calibrated airspeed does not allow for wind. Here's an easy
way to test it:
1. Take a YASim plane (such as the J3 Cub), fly to altitude, then
level out. Note exactly where the horizon is on the screen, and
recor
Jon Berndt writes:
> If you are interested in space, you might check out www.naswatch.com
> today. There's a name there today that might be familiar to some of us.
I'm missing it? Did they find Chandra Levy while looking for shuttle
debris in Gary Condit's back yard out in California? Oh, never
John,
the correct link ist of course:
www.nasawatch.com
Regards, Michael
--
Michael Basler, Jena, Germany
[EMAIL PROTECTED]
http://www.geocities.com/pmb.geo/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
If you are interested in space, you might check out www.naswatch.com
today. There's a name there today that might be familiar to some of us.
;-)
Jon
smime.p7s
Description: application/pkcs7-signature
> Another weird thing I've seen today: Taxiing at KSFO to the big building
> (the one on stakes :) with the 747... Halted, with engines on idle, the nose of
> the 747 slowly entered the building and a couple of seconds later the
> 747 makes a "jump" and freezes the simulation.
We've recently discu
David Megginson
>
> Curtis L. Olson writes:
>
> > I've also heard that if you fly tight enough circles, you can lower a
> > rope with a bucket from your aircraft and actually exchange stuff with
> > people on the ground ... kind of like an low budget (low payload)
> > hover. :-)
>
> If you are
Curtis L. Olson writes:
> I've also heard that if you fly tight enough circles, you can lower a
> rope with a bucket from your aircraft and actually exchange stuff with
> people on the ground ... kind of like an low budget (low payload)
> hover. :-)
If you are landing into any kind of headwin
David Megginson writes:
> Was that 32 kt from the HUD, or 32 mph from the ASI?
>
> The J3 cub has a stall speed around 25 kt (roughly 30 mph) and is
> supposed to be able to take off in a 200 ft groundroll and land in a
> 300 ft roll under ideal conditions. Here's what the 1946 owner's
> manual s
Dave Perry writes:
> I flew the j3cub again and I take back my assesment of the climb and
> glide. It appears that it starts with significant nose down trim.
Thanks. Actually, I think you did find a real problem with the
v-speeds, but I'll keep working on it.
The Cub should start at neutral
Dave Perry writes:
> I just took the j3 for a spin. The stall characteristics are
> significantly improved. The response to rudder when a wing drops still
> seems less than in a real aircraft. This could be the range of my pedals.
That can be adjusted very easily. Open up
$FG_ROOT/Aircra
Jim Wilson writes:
> Now I can take off very quickly (even before it reaches the runway number at
> KSFO) just by holding the stick back about half way and it'll continue
> climbing steadily once out of ground effect at about 32 kts. Is that correct
> for the j3?
Was that 32 kt from the HUD,
On 2/18/03 at 9:50 PM Erez Boym wrote:
>Hi,
>
>It's more a TerraGear question but it seams that the
>TerraGear list is dead so I'm trying my luck here,
>hoping some one can help me.
>
>I'm compiling TerraGear and for some reason, it keeps
>complaining about simgear/misc/fgstream.hxx. I have
>all t
Erez Boym wrote:
Hi,
It's more a TerraGear question but it seams that the
TerraGear list is dead so I'm trying my luck here,
hoping some one can help me.
I'm compiling TerraGear and for some reason, it keeps
complaining about simgear/misc/fgstream.hxx. I have
all the latest files from FlightGear
Bernie Bright wrote:
From simgear/screen/tr.h:
extern void trTileSize(TRcontext *tr, GLint width, GLint height, GLint
border);
It looks like GLint is defined as an int when compiling SimGear but is long
when compiling FlightGear.
Ouch, what a horrible way to find thise kind of problems.
I
Martin Spott wrote:
One place to look is materials.xml in the root od the base directory.
Set the values of to zero and see if it changes
anything.
Sorry no success. I tried setting every occurence to 0.5 or 0.0 - without
any noticeable change
One extra step would be setting all and
43 matches
Mail list logo
