On Thu, 12 Feb 2004 19:50:48 -
"Jim Wilson" <[EMAIL PROTECTED]> wrote:
You actually want to be very exact about matching the model to the
FDM origin.
...
Jim (or someone ... *anyone*):
Could you summarize the argument taking place here? I seem to only be
getting parts of it - I guess I did
Vivian Meazza <[EMAIL PROTECTED]> said:
> I was only using the CofG (and approximately at that) as a better visual
> reference than the nose. I was only concerned to make things look right. I'm
> sure that the FDMs are quite correct, or the models wouldn't fly very well,
> if at all. I take it the
Martin Spott <[EMAIL PROTECTED]> said:
> You _might_ be right, but in the case we are talking abouth things are
> different. For example use the "Tower view" and zoom enough to get the
> details. Take off and stay 100 ft above the ground. Now push the
> elevator violently aband you'll notice that
Vivian Meazza <[EMAIL PROTECTED]> said:
> Tried that. Looks just the same to me. As I said some time ago: yer pays yer
> money and yer takes yer choice. Neither is right on the ground for
> differential braking: with one brake full on the aircraft more or less
> rotates around that wheel. The mode
Martin Spott asked
> Subject: Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
>
>
> "Jim Wilson" <[EMAIL PROTECTED]> wrote:
>
> > If you put the model back to the nose and use the method
> that the p51d
> > and the pa28-161 use (the target
"Jim Wilson" <[EMAIL PROTECTED]> wrote:
> If you put the model back to the nose and use the method that the p51d and the
> pa28-161 use (the target offset) you'll look better on the ground.
BTW, it appears to me that the P-51 suffers from the same visual mishap
as the PA-28 does (does this have t
Jim Wilson wrote
> Vivian Meazza <[EMAIL PROTECTED]> said:
>
> >
> >
> > Martin wrote:
> > >
> > > David Megginson <[EMAIL PROTECTED]> wrote:
> > > > Update of /var/cvs/FlightGear-0.9/data/Aircraft/pa28-161
> > > > In directory baron:/tmp/cvs-serv12589
> > >
> > > > Modified Files:
> > > >
Andy wrote
>
>
> Martin Spott wrote:
> > Jim Wilson wrote:
> > > If the camera is tracking the nose, then it moves up and down as
> > > well with the nose. This creates the _illusion_ that the rest of
> > > the aircraft (and of the scene for that matter) is
> moving, and the
> > > nose is r
Andy Ross <[EMAIL PROTECTED]> wrote:
> Martin Spott wrote:
>> Jim Wilson wrote:
>> > If the camera is tracking the nose, then it moves up and down as
>> > well with the nose. This creates the _illusion_ that the rest of
>> > the aircraft (and of the scene for that matter) is moving, and the
>> > n
Martin Spott wrote:
> Jim Wilson wrote:
> > If the camera is tracking the nose, then it moves up and down as
> > well with the nose. This creates the _illusion_ that the rest of
> > the aircraft (and of the scene for that matter) is moving, and the
> > nose is remaining stationary when in fact it
"Jim Wilson" <[EMAIL PROTECTED]> wrote:
> David Megginson <[EMAIL PROTECTED]> said:
>> Martin Spott wrote:
>> > At least in the _outside_ views the PA-28 still rotates around its nose
>> > after the recent changes,
>>
>> That seemed funny to me as well, but when I looked from the outside view, it
David Megginson <[EMAIL PROTECTED]> said:
> Martin Spott wrote:
>
> > I can't withstand the impression that changing the _camera_ position
> > didn't lead to the intended success. Take a simple stick and rotate it
> > around one of its ends. For an observer the phenomenon is still the
> > same ev
Vivian Meazza <[EMAIL PROTECTED]> said:
>
>
> Martin wrote:
> >
> > David Megginson <[EMAIL PROTECTED]> wrote:
> > > Update of /var/cvs/FlightGear-0.9/data/Aircraft/pa28-161
> > > In directory baron:/tmp/cvs-serv12589
> >
> > > Modified Files:
> > > pa28-161-yasim-set.xml
> > > Log Message:
Martin Spott wrote:
I can't withstand the impression that changing the _camera_ position
didn't lead to the intended success. Take a simple stick and rotate it
around one of its ends. For an observer the phenomenon is still the
same even when he changes his viewpoint.
If you want to rotate the sti
-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
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
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
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
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
On Sun, 08 Feb 2004 21:31:30 +0100,
Erik Hofman <[EMAIL PROTECTED]> wrote in message
<[EMAIL PROTECTED]>:
> Martin Spott wrote:
>
> > Anyway: Thanks for this very nice addition to the FlightGear hangar,
>
> I'm already investigating for a larger home airport. KSFO isn't going
> to take it anym
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
Martin Spott wrote:
Anyway: Thanks for this very nice addition to the FlightGear hangar,
I'm already investigating for a larger home airport. KSFO isn't going to
take it anymore.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.fli
> > 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
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
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
> 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 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
Martin Spott wrote:
Erik Hofman wrote:
Martin Spott wrote:
Woohooo !
I take this as a compliment.
Absolutely - with the gear retracted the F16 looks really 'smart'. I
have been waiting all the time for a retractable gear but didn't dare
to ask
It never hurts to ask. It's just that it probb
Erik Hofman <[EMAIL PROTECTED]> wrote:
> Martin Spott wrote:
>>>Update of /var/cvs/FlightGear-0.9/data/Aircraft/f16/Models
>>>In directory baron:/tmp/cvs-serv20447
>>
>>
>>>Modified Files:
>>> f16.ac f16.xml
>>>Log Message:
>>>Add gear animation
>>
>>
>> Woohooo !
> I take this as a compl
Martin Spott wrote:
Update of /var/cvs/FlightGear-0.9/data/Aircraft/f16/Models
In directory baron:/tmp/cvs-serv20447
Modified Files:
f16.ac f16.xml
Log Message:
Add gear animation
Woohooo !
I take this as a compliment.
Thanks!
Erik
___
Flightgear-d
Andy Ross writes:
> Sure, there's a print() function which uses SG_LOG; for exactly this
> purpose. There's even a fancy dump() method on a property node that
> you can use to dump a property tree to the console.
Ok, thanks, I eventually found it. Quite useful, thanks. :-)
> It turns out to be
Curtis L. Olson wrote:
> It appears (to me) to be a property setting problem. Andy, does
> nasal have the ability to dump console output for temporary
> debugging?
Sure, there's a print() function which uses SG_LOG; for exactly this
purpose. There's even a fancy dump() method on a property node
Curt wrote:
> select = sel.getChild("engine", i);
> Could there be a bug in this form of getChild()?
Heh, bingo. That was exactly it. See the other post for notes.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightge
Andy Ross writes:
> Curtis L. Olson wrote:
> > David, (Andy?)
> >
> > It appears that in the latest cvs, we have lost the ability to control
> > the engines independently.
>
> This one is mine. The recent Nasal stuff contains a rework of the
> engine handling to allow for arbitrary numbers of eng
Andy Ross writes:
> Curtis L. Olson wrote:
> > David, (Andy?)
> >
> > It appears that in the latest cvs, we have lost the ability to control
> > the engines independently.
>
> This one is mine. The recent Nasal stuff contains a rework of the
> engine handling to allow for arbitrary numbers of eng
Andy Ross <[EMAIL PROTECTED]> wrote:
> Curtis L. Olson wrote:
>> Previously you could type... etc. to
>> select an engine. Then '{' and '}' would select the magnetos.
>> Finally, "space bar" would kick in the starter motor for as long as it
>> was depressed.
>
> Let me take a look. I presum
Jon S Berndt writes:
> On Mon, 29 Dec 2003 15:49:30 -0600
> "Curtis L. Olson" <[EMAIL PROTECTED]> wrote:
> >David, (Andy?)
> >
> >It appears that in the latest cvs, we have lost the ability to control
> >the engines independently. Previously you could type
> > ... etc. to select an engine. Th
Andy Ross writes:
> Curtis L. Olson wrote:
> > David, (Andy?)
> >
> > It appears that in the latest cvs, we have lost the ability to control
> > the engines independently.
>
> This one is mine. The recent Nasal stuff contains a rework of the
> engine handling to allow for arbitrary numbers of eng
On Mon, 29 Dec 2003 15:49:30 -0600
"Curtis L. Olson" <[EMAIL PROTECTED]> wrote:
David, (Andy?)
It appears that in the latest cvs, we have lost the ability to control
the engines independently. Previously you could type
... etc. to select an engine. Then '{' and '}'
would select the magnetos.
Curtis L. Olson wrote:
> David, (Andy?)
>
> It appears that in the latest cvs, we have lost the ability to control
> the engines independently.
This one is mine. The recent Nasal stuff contains a rework of the
engine handling to allow for arbitrary numbers of engines, and avoid
the "why are there
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
___
David,
As for the STL headers, use these instead:
#include STL_IOSTREAM
#include STL_IOMANIP
There are actually many files that are not using these variables from
simgear/compiler.h. It looks like the ATC code and JSBSim are handling
this on their own instead of letting Simgear do it (though
Just to clarify a couple of things re helicopters:
Once the engine stops there is no torque and the helicopter can be
autorotated to a safe landing using the same principle as a gyrocopter.
This manouvre is part of training to get a licence and is practised
many times.
The danger with an auto
Maik Justus <[EMAIL PROTECTED]> wrote:
> The bo really can loop and act quite different to many other helos.
Zimmerman flew a slightly modified (lubrication of the main gear box)
BO-105 which was able to fly top-down,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its frie
Innis
> You are probably right.Just wonder if they would feel the same way if they
> found something in here they could use.
Contacting them about the panels might be a good way of introducing them to the
joys of FlightGear if they're not already aware of it. :-)
Mally
---
Outgoing mail is ce
Hi Lee
I just hate reinventing the wheel over and over.And as we have a bit of a
shortage of panels in FG I thought it might be a way to get some more.
Anyway there are a couple of people in MSFS who have given there permission
so if I am going to persue this I will restrict myself to those desig
Hi Mally
You are probably right.Just wonder if they would feel the same way if they
found something in here they could use.
Cheers
Innis
The Mad Aussi
"Mally"
> You are absolutely right. But I was just making people aware that some
parts
> of the MSFS panels can be used in FG with little effort.
Hello Innis,
Where people have given permission there is no problem at all but if a FG
document says "you have to get this artwork for yourself because we
aren't allowed to include it" then we're admiting that we don't have
permission to use it but that there's a loop-hole that allows individua
> You are absolutely right. But I was just making people aware that some parts
> of the MSFS panels can be used in FG with little effort.
> What problem would there be if the readme for a panel xml file said that it
> would work with a certain MSFS background.As long as the person uses it
> themsel
> My understanding of the tail rotor is to counteract the torque of the main
> rotor and to rotate the helo around its Z axis in either a CW or CCW
> direction depending on the lift supplied by the tail rotor.
> Loss of a tail rotor more than likely will result in loss of the helo unless
> the pi
Lee Elliott writes>
Hi Lee
You are absolutely right. But I was just making people aware that some parts
of the MSFS panels can be used in FG with little effort.
What problem would there be if the readme for a panel xml file said that it
would work with a certain MSFS background.As long as the
Hi Maik
Maik Justus writes
Hi Innis,
>
The tail rotor could be tied to the rudder but it should give equal
rotation around its axis regardless of the forward speed or lack of it of
the helo.
Hm. I hink this is only correct for acrobatic (3D) model-helos with a (so
called) heading lock gyro, b
On Saturday 18 October 2003 13:03, Innis Cunningham wrote:
> Hi Jim
> Sorry mate the last time I worked on choppers was 30 years ago.
> But what I could suggest is to download a MSFS panel you like and
convert it
> for FG use.
> I have found that you can use the artwork of panels made for FS98 an
Hi Jim
Sorry mate the last time I worked on choppers was 30 years ago.
But what I could suggest is to download a MSFS panel you like and convert it
for FG use.
I have found that you can use the artwork of panels made for FS98 and then
add the instruments from FG.
While for a complete panel for FG
Hi Innis,
Innis Cunningham wrote:
Hi Jim
While mapping the collective to the throttle would work. It is a bit
like mapping a variable pitch prop to a throttle.In most helo's I
worked on the throttle was opened wide and then the collective was
pulled on.
On most modern helos the engine is co
Hi,
Oh, _that_ one is really nice. Although the heli is really very well
thanks
behaved (even with mouse any keyboard control I find it pretty easy to
fly _and_land_)...
The bo is a little bit different to most other helicopters. I don't say
that this simulation is totally realistic, but it sh
Hi
Curtis L. Olson wrote:
It also loops quite easily ... not saying that was the first thing I
tried. How do you run the collective? How about yaw control? The
rudder seemed to act more like an aerodynamic rudder ... not that I
know anything about how a helo is supposed to fly ...
Curt.
The b
Innis Cunningham writes:
> While mapping the collective to the throttle would work. It is a
> bit like mapping a variable pitch prop to a throttle.
It's just a terminology problem, not a flight-modelling problem -- it
sucks using /controls/engines/engine[0]/throttle (or whatever) to
manipulate
Innis Cunningham <[EMAIL PROTECTED]> said:
> Hi Jim
> While mapping the collective to the throttle would work. It is a bit like
> mapping a variable pitch prop to a throttle.In most helo's I worked on the
> throttle was opened wide and then the collective was pulled on.
> It is very interesting
Hi Jim
While mapping the collective to the throttle would work. It is a bit like
mapping a variable pitch prop to a throttle.In most helo's I worked on the
throttle was opened wide and then the collective was pulled on.
It is very interesting to see the look on the passengers faces when the
pilo
David Megginson <[EMAIL PROTECTED]> wrote:
> There are still some problems we need to work out. For example, if
> you set the wind to 0 and turn off the engine, the helicopter still
> slides backwards and turns -- we'll have to figure out why there are
> forces acting on it. To test:
>
> fgfs
"Curtis L. Olson" <[EMAIL PROTECTED]> said:
> It also loops quite easily ... not saying that was the first thing I
> tried. How do you run the collective? How about yaw control? The
> rudder seemed to act more like an aerodynamic rudder ... not that I
> know anything about how a helo is suppose
David Megginson <[EMAIL PROTECTED]> said:
> Martin Spott writes:
>
> > O.k., I'll try tomorrow. I'm curious why it didn't get triggered today.
> > BTW, for those who never flew a heli: If you chose to stand outside
> > then take a position on the left behind the helicopter. This makes the
> >
Jon S Berndt writes:
> On Thu, 16 Oct 2003 17:15:02 -0400
> David Megginson <[EMAIL PROTECTED]> wrote:
>
> >There are still some problems we need to work out. For example, if
> >you set the wind to 0 and turn off the engine, the helicopter still
> >slides backwards and turns -- we'll have
Curtis L. Olson writes:
> It also loops quite easily ... not saying that was the first thing I
> tried. How do you run the collective? How about yaw control? The
> rudder seemed to act more like an aerodynamic rudder ... not that I
> know anything about how a helo is supposed to fly ...
Tr
On Thu, 16 Oct 2003 17:15:02 -0400
David Megginson <[EMAIL PROTECTED]> wrote:
There are still some problems we need to work out. For example, if
you set the wind to 0 and turn off the engine, the helicopter still
slides backwards and turns -- we'll have to figure out why there are
forces acting o
Martin Spott writes:
> O.k., I'll try tomorrow. I'm curious why it didn't get triggered today.
> BTW, for those who never flew a heli: If you chose to stand outside
> then take a position on the left behind the helicopter. This makes the
> first steps lots easier,
There are still some problem
David Megginson writes:
> Martin Spott writes:
>
> > O.k., I'll try tomorrow. I'm curious why it didn't get triggered today.
> > BTW, for those who never flew a heli: If you chose to stand outside
> > then take a position on the left behind the helicopter. This makes the
> > first steps lots e
"Jim Wilson" <[EMAIL PROTECTED]> wrote:
> Martin Spott <[EMAIL PROTECTED]> said:
>> Oh, _that_ one is really nice. Although the heli is really very well
>> behaved (even with mouse any keyboard control I find it pretty easy to
>> fly _and_land_) I'm shure that crash detection should definitely be
On Thursday 16 October 2003 18:10, Jim Wilson wrote:
> Martin Spott <[EMAIL PROTECTED]> said:
>
> > "Curtis L. Olson" <[EMAIL PROTECTED]> wrote:
> > > Update of /var/cvs/FlightGear-0.9/source/src/FDM/YASim
> > > In directory baron:/tmp/cvs-serv7544
> > >
> > > Added Files:
> > > Rotor.cpp Rotor
Martin Spott <[EMAIL PROTECTED]> said:
> "Curtis L. Olson" <[EMAIL PROTECTED]> wrote:
> > Update of /var/cvs/FlightGear-0.9/source/src/FDM/YASim
> > In directory baron:/tmp/cvs-serv7544
> >
> > Added Files:
> > Rotor.cpp Rotor.hpp Rotorblade.cpp Rotorblade.hpp
> > Rotorpart.cpp Rotorpart
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
Martin Spott writes:
> "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 getsta
David Megginson wrote:
Bernie Bright writes:
> Haven't we seen this or something like it before? Instead of "fixing" the
> code every time wouldn't it be easier to supply the missing comparison
> functions for your platform:
>
> inline bool
> operator!=( const std::string& lhs, const char*
Bernie Bright writes:
> Haven't we seen this or something like it before? Instead of "fixing" the
> code every time wouldn't it be easier to supply the missing comparison
> functions for your platform:
>
> inline bool
> operator!=( const std::string& lhs, const char* rhs )
> {
> ret
On 16 Sep 2003 08:39:26 GMT,
Martin Spott <[EMAIL PROTECTED]> wrote in message
<[EMAIL PROTECTED]>:
> Erik Hofman <[EMAIL PROTECTED]> wrote:
> > Update of /var/cvs/FlightGear-0.9/data/Aircraft/T38
> > In directory baron:/tmp/cvs-serv23354
>
> > Modified Files:
> > T38.xml
>
> I'd vote for
Martin Spott wrote:
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
Erik Hofman <[EMAIL PROTECTED]> wrote:
> Martin Spott wrote:
>> Although this improves the altimeter display in the default aircraft,
>> the c310u3a-3d looks a bit strange now at my end:
>>
>> http://document.ihg.uni-duisburg.de/bitmap/FGFS/Panel_04.png
> What depth buffer do you have? I tested
Jim Wilson wrote:
Erik Hofman said:
Martin Spott wrote:
Although this improves the altimeter display in the default aircraft,
the c310u3a-3d looks a bit strange now at my end:
http://document.ihg.uni-duisburg.de/bitmap/FGFS/Panel_04.png
I don't get it. Is this OpenGL implementation dependent or s
Erik Hofman <[EMAIL PROTECTED]> said:
> Martin Spott wrote:
>
> > Although this improves the altimeter display in the default aircraft,
> > the c310u3a-3d looks a bit strange now at my end:
> >
> > http://document.ihg.uni-duisburg.de/bitmap/FGFS/Panel_04.png
>
> I don't get it. Is this OpenGL i
Martin Spott wrote:
Although this improves the altimeter display in the default aircraft,
the c310u3a-3d looks a bit strange now at my end:
http://document.ihg.uni-duisburg.de/bitmap/FGFS/Panel_04.png
I don't get it. Is this OpenGL implementation dependent or something?
I get much better result wi
Erik Hofman <[EMAIL PROTECTED]> wrote:
> It's meant to be the heath buildup that disturbs the airflow and hence
> influences the visibility in the specific area.
Personally I consider the cones a bit dominant for this purpose,
Martin.
--
Unix _IS_ user friendly - it's just selective about who
Martin Spott wrote:
and _if_ they appear the probably should be sort of yellow/orange,
not white,
Not really, the T-38 doesn't have an afterburner.
It's meant to be the heath buildup that disturbs the airflow and hence
influences the visibility in the specific area.
Erik
__
Frederic BOUVIER <[EMAIL PROTECTED]> wrote:
> Martin Spott wrote:
>> Erik Hofman wrote:
>> > Update of /var/cvs/FlightGear-0.9/data/Aircraft/T38
>> > In directory baron:/tmp/cvs-serv23354
>>
>> > Modified Files:
>> > T38.xml
>>
>> I'd vote for a modification of the 3D model. The cones behind
Frederic BOUVIER wrote:
Martin Spott wrote:
I'd vote for a modification of the 3D model. The cones behind the
engines don't look _that_ realistic when sitting idle on the runway:
http://document.ihg.uni-duisburg.de/bitmap/FGFS/T38_01.png
This is where a blend animation can be useful
Done.
Eri
Frederic Bouvier writes:
> Erik Hofman wrote:
> > Update of /var/cvs/FlightGear-0.9/data/Textures/Terrain
> > In directory baron:/tmp/cvs-serv478
> >
> > Added Files:
> > airport.rgb
> > Log Message:
> > Add a default airport cover
>
> binary ? ;-)
>
> BTW, do you consider applying the cvswra
Frederic Bouvier wrote:
Erik, there are a number of new airport objects added but you
didn't update any .stg files. It seems incorrect to me. When
flying around SF, I can see white squares that are the holes
for the unloaded airports.
Yep, Curtis told me about that just yet. I didn't know that (un
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
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
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
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
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
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
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:
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:
> 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:
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.
Michael Selig wrote:
At 7/26/03, Jim Wilson wrote:
Is there a reason this can't be moved out of the main loop yet? It's
been a
while since it was last discussed, but I thought something was going
to be
done with it.
The patch was one I submitted to Erik.
How about this solution for now: Sim
At 7/26/03, Jim Wilson wrote:
Is there a reason this can't be moved out of the main loop yet? It's been a
while since it was last discussed, but I thought something was going to be
done with it.
The patch was one I submitted to Erik.
How about this solution for now: Simply delete or comment out
Bernie Bright writes:
> These latest changes generate a compilation error:
>
> native_fdm.cxx: In function `void FGProps2NetFDM(FGNetFDM*, bool)':
> native_fdm.cxx:252: invalid operands of types `float' and `unsigned int' to
> binary `operator&'
>
> The gear_* members should be converted using ht
301 - 400 of 559 matches
Mail list logo
