RE: [Flightgear-devel] 777 Model

[Norman Vine]

Boris Koenig writes:
> 
> But, there seems to be a project related to openRT that is dedicated to
> developing the necessary hardware: http://www.saarcor.de/

This is a fascinating project but ...  until these chips are as prevalent
in consumer grade hardware as OpenGL cards are today, I think we 
should content ourselves with just dreaming about programing FGFS
in OpenRT. 

Note that FGFS does not utilize many of the features available in the 
more current generations of OpenGL cards but now that OpenGL 2.0 
is a reality that may start to change in the not so distant future.

This *might* make a large differance in the rendering performance
although I suggest that those preoccupied with the rendering speed
profile the code to see where the time is being spent.

I am espescially interested in the profiling results from the newer
higher end cards.  i.e the GForce 4 class or equivalent cards

Cheers

Norman

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] lights flaring on runways in FG

[Peter Larson]

> I get the same ground poly problems that you seem to be getting with your
new
> ATI driver, except I've been getting them for some time now.
>
> It actually only seems to be the airfield polys that are affected but
you'll
> often see it with airfields that are a long way away, to the extent that
you
> can't see the airfield itself but only the displaced polys as they sick up
> through the haze, sometimes to many tens of thousand of feet.
>
> Are you able to fly at night i.e. when the sun is below the horizon?  If I
try
> flying in these conditions FG starts but crashes once I get a few hundred
> feet in the air and I think this is also due to the ATI drivers.

I'm very new on FG, only been running it for two weeks. Also, my PC was just
recently rebuilt, so pretty much everything in new.

I was getting the segfault when I exited FG, but this disappeared when I
installed the latest driver from the ATI web site. I've seen some comments
that there are problems with some VIA chipsets and the ATI Radeon cards, so
I have also installed the latest drivers for the motherboard. My machine was
hanging when the resolution was greater than 1024 x 768, just running
windows, so there is obviously some clashes there. since I did this, I
havn't tried higher than 1024 resolution, so I don't know if I've actually
fixed the problem.

Are you using an ATI card? The problems you described are similar,
especially the long distance problems. I assumed at first that is was really
bad sheet lightning graphics until I noticed they were coming from the
ground!

I've had FG hang once in a night flight, possibly around 100 seconds, as
others indicated in this thread. I'll pay more detail from now on, as I've
assumed most of my problems up until now have been motherboard/video
clashes.

Peter


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.718 / Virus Database: 474 - Release Date: 9/07/2004


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] 777 Model

[Boris Koenig]

On July 20, 2004 03:23 am, Jim Wilson wrote:
Hmmm... that 777 Model page didn't mention a GPU.  In any case, I gather
from reading just the first paragraph on the OpenRT page you'd be 
looking
at having plib utilize the OpenRT API in lieu of OpenGL's.
I may be wrong, but from what I've read, openRT is indeed supposed to
make use of a specific GPU - or alternatively a (cluster of) CPU(s)
@ ~40 GHZ :-)
But, there seems to be a project related to openRT that is dedicated to
developing the necessary hardware: http://www.saarcor.de/
Seemingly, also a project of the same German university.
Ampere K. Hardraade wrote:
All I am saying is that it will be a good idea to look deeper into it instead 
of pushing it aside.  After all, from what I have read on their site, the 
OpenRT library seems to offer some pretty neat capabilities that aren't in 
the current version of plib.
plib makes use of openGL while openRT is a different "rendering" 
approach which doesn't utilize rasterization anymore - so I think Jim
is right in saying that one would really have to drop the entire openGL
approach to make use of something like that.
I don't know the details, but I doubt that it would be really "simple"
to convert to such a new approach, which wouldn't rely on openGL anymore.

In the long term the openRT folks probably hope to replace the openGL 
implementation in many 3D applications with openRT, because it could 
provide a performance boost in many cases, particularly because it would
no longer be necessary to process all graphics data just in order to
determine which parts are really visible or not ...

At the very least, we should keep this real-time-raytracing technology in 
mind.  The idea of Microsoft come out with games that utilize real time 
raytracing while Linux has nothing equivilent is... freightening.
I agree, the whole idea is extremely fascinating: Having had a look at
some of the screenshots or even videos, the stuff seems really to be
pretty amazing and powerful, but currently it's probably really a bit
beyond the scope of any "game", to care too much for openRT, simply
because of the lack of hardware support, I think - be it a relevant
GPU board or the 40 GHZ requirement for openRT :-)
And then I am not even sure if there's really yet an OPEN
implementation available !?
As long as FlightGear keeps getting modularized even more, it should not
be that much of a problem, to consider new technologies - even though
this unlikely to become an issue within the next 3-5 years ;-)
But on the other hand, at http://graphics.cs.uni-sb.de/RTGames
you can read:
"We are very much interested in evaluating new ways for computer games
and therefore like to cooperate with the gaming industry. Thus if you
are in such a position, please send us an email
!"
So, now it depends if FlightGear is considered part of "the gaming
industry" :-)
But if the openRT developers are really also looking for opensource
projects, it would probably be not that bad for FlightGear to at least
indicate some willingness ;-)

-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] 777 Model

[Ampere K. Hardraade]

All I am saying is that it will be a good idea to look deeper into it instead 
of pushing it aside.  After all, from what I have read on their site, the 
OpenRT library seems to offer some pretty neat capabilities that aren't in 
the current version of plib.

At the very least, we should keep this real-time-raytracing technology in 
mind.  The idea of Microsoft come out with games that utilize real time 
raytracing while Linux has nothing equivilent is... freightening.

Regards,
Ampere


On July 20, 2004 03:23 am, Jim Wilson wrote:
> Hmmm... that 777 Model page didn't mention a GPU.  In any case, I gather
> from reading just the first paragraph on the OpenRT page you'd be looking
> at having plib utilize the OpenRT API in lieu of OpenGL's.
>
> Best,
>
> Jim

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

[Flightgear-devel] Saitek Cyborg-Evo.xml broken

[Dave Perry]

Help!
Since my CH Yoke and Pedals don't work with the "new" joydev driver in 
Suse 9.1, I need to use my Saitek Cyborg Evo joystick.  Both js_demo and 
jstest show all it's axes and buttons working but ony the non DEFANGED 
functions work in FlightGear (that is aileron, elevator and rudder ... 
no buttons).

I had to edit three things in Cyborg-Evo.xml
1.  The name displayed by js_demo and jstest is "Saitek Cyborg USB 
Stick" so I changed the name in the xml file.
2.  Axis for hat left/right was 4 (not 6) in jstest.
3.  Axis for hat fore/aft was 5 (not 7) in jstest.

With these changes, only the non- functions work. 

Is this xml a work in progress or have I broken something else?
Some day I will learn not to "upgrade" a working very stable system!
Best regards,
Dave P.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

RE: ..Coffmann starters on Merlins: [Flightgear-devel] Re: Is 'SceneryLoading...' mandatory ?

[Vivian Meazza]

Regards,

Vivian


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:flightgear-devel-
> [EMAIL PROTECTED] On Behalf Of Arnt Karlsen
> Sent: 24 July 2004 21:33
> To: FlightGear developers discussions
> Subject: ..Coffmann starters on Merlins: [Flightgear-devel] Re: Is
> 'SceneryLoading...' mandatory ?
> 
> On Sat, 24 Jul 2004 19:58:30 +0100, Vivian wrote in message
> <[EMAIL PROTECTED]>:
> >
> > It starts exactly the way it says in the POH.
> >
> > Magneto switches to on, advance throttle a little, press start button,
> > keep pressed until engine fires.
> >
> > If it fails to fire, re-index the Coffman starter by pulling the
> > ringpull, then try again. You have 6 cartridges.
> 
> ..did the Packard Merlins also used it?

No - Packard Merlins had electric start.
 
> ..how many blades (or prop or crankshaft turns) per cartridge?
> Common cartridge-only rpm and decay turns and time to stop
> (on failed starts)?

Hmmm. Best I can do with the current simulator. Try it and see :-)

> ..on successful starts, how many blades 'till the 1'st one fires",
> then how many misses until smooth running idle?

See above. How long is a piece of string? Depends on many factors, but I
think you'll find that it sounds about right.

> ..it commonly starts on first, 2'nd or 3'rd etc fired?

Reputedly on 1st, provided primer pump used, which I haven't implemented
yet.

> ..can 1, 2, or 3 etc Coffmans start a flooded engine?  (Assuming
> no cround crew assistance but corrective action by the pilot.)

No info in Pilot's notes. No flooded engine procedure given, so I assume
that it was either a very rare occurrence, or so common that everyone knew
how to do it, so it wasn't worth explaining. Come to think about it, I'm not
sure how easy it would be for ground crew to turn over a 27 litre engine
(impossible?).
 
> ..approximates, obviously, ideally, someone has talked with
> WWII tech or pilot veterans with relevant Merlin experience.

Near enough for government work :-)

> ..btw, did anyone fix the boost b button bug?  (2-speed
> supercharger clutch barometer triggered at 18,000 ft or
> somesuch on RR in Spit mkix and Packards in P-51B
> onwards etc)

No, but I think we understand the problem. But there again, we haven't got
the propeller gearing fixed yet. And we haven't done the boost cut-out
control. The boost isn't right using legacy code either.

Regards,


Vivian 




___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

RE: [Flightgear-devel] Re: Is 'Scenery Loading...' mandatory ?

[Vivian Meazza]

Alex Romosan wrote

> Sent: 24 July 2004 20:51
> To: FlightGear developers discussions
> Subject: [Flightgear-devel] Re: Is 'Scenery Loading...' mandatory ?
> 
> "Vivian Meazza" <[EMAIL PROTECTED]> writes:
> 
> > It starts exactly the way it says in the POH.
> >
> > Magneto switches to on, advance throttle a little, press start button,
> keep
> > pressed until engine fires.
> 
> so, in terms of keyboard commands this should be { } (magneto switches
> on) and then press space bar?

Yup
> 
> > If it fails to fire, re-index the Coffman starter by pulling the
> ringpull,
> > then try again. You have 6 cartridges.
> 
> it does. so i press C and try space bar again. the propeller sputters
> a bit and that's it.

Yup. WFM using the downloaded version. Do you have the throttle advanced a
little, and are the magneto switches in the down position?
> 
> > To stop, pull the cut-off ring pull.
> 
> i'll deal with that once i manage to start the engine... :-)
> 

try using a mouse on the instrument panel


Regards,

Vivian



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Is 'Scenery Loading...' mandatory ?

[Jim Wilson]

Frederic Bouvier said:

> Is there a way to avoid the initial lock for scenery loading ?
> I understand this is a must have for users, but it slows 
> down development speed dramatically when you have to test the 
> apparence of a new building or landmark.
> 
> Another point: FPS counter is off by default now. It was on 
> before. Is it intended ?
> 
> -Fred
> 

Hi Fred,

Just look in main.cxx where it sets: 

fgSetBool("sim/sceneryloaded",false);

This line could probably just be removed (afik it'll default to false),  then
if you set it true in your .fgfsrc file it won't pause the FDM.  Otherwise you
could use second configuration property and use an if/else to set the above
flag true or false at initialization.

An even better solution for development might be a variation of "reset" that
dumps and reloads the scenery.  Especially if it left your view position the same.

Best,

Jim


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Re: Is 'Scenery Loading...' mandatory ?

[Jim Wilson]

Alex Romosan said:

> "Frederic Bouvier" <[EMAIL PROTECTED]> writes:
> 
> > Is there a way to avoid the initial lock for scenery loading ?
> > I understand this is a must have for users, but it slows 
> > down development speed dramatically when you have to test the 
> > apparence of a new building or landmark.
> 
> i think the fix for the scenery loading is not quite right. with it i
> get a very strange spitfire cockpit (i.e. i can see through the
> instrument panel and the body of the aircraft). looks like z-buffer
> ordering is not done properly (screen depth is 16bp, using the radeon
> freedesktop drivers). if i disable it, the cockpit looks normal again.
> if could only figure out how to start the damn plane...

That has got to be a bug elsewhere.  This only pauses the FDM.

Best,

Jim


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Re: --fog-fastest & --fog-disabled - the latter w/o update below horizon ?

[Boris Koenig]

Alex Romosan wrote:
Chris Metzler <[EMAIL PROTECTED]> writes:

Regarding the navaids discussion I'd like to know if airports
are currently exclusively bound to the scenery, actually I
was looking for some airports that FlightGear also finds, but
didn't see any rwys - if airports should really depend on specific
scenery to be installed, it might be worth to think about
separating airports from scenery - at least the basics like
runways etc ...or what else is the reason for not _seeing_
an airport which FlightGear actually knows of ?
Can you rephrase this?  I can't figure out what it is that you're
saying here.

the graphics part of the airports _is_ part of the scenery. FlightGear
looks up the latitude and longitude and the position and heading of
the runways (in runways.dat) but if the scenery is not there there
are no graphics to be loaded so you get positioned over the ocean.
Hey, thanks Alex - that's exactly what I wanted to know ...
So, there's no way to have the airports/runways etc. available
without installing the corresponding scenery ?
Hmm, bu**er :-/
How about also separating the scenery from the actual airports data ?
I will untar the archive and check if it's the same format as in
X-Plane, if it is it should be possible to display basic airports
even without having the necessary scenery installed.


Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] --fog-fastest & --fog-disabled - the latter w/o update below horizon ?

[Boris Koenig]

Chris Metzler wrote:
On Sat, 24 Jul 2004 21:32:25 +0200
Boris Koenig <[EMAIL PROTECTED]> wrote:
A couple of other things: I *did* search, but didn't find
a way to directly set the heading of an aircraft if you
want to position it in air - if it's there already, please
tell me where :-)
If it isn't it might be worth to be added ?

What did you search?
sorry, I was reffering to the "Set Position dialog" within FlightGear,
not any command line options, I do know that you can set these manually
or use directly the property tree, but I thought it might make sense
to directly include that option within the corresponding dialog.
And that's where I was looking for that option, because I thought
it would make sense to be there !?

Can you rephrase this?  I can't figure out what it is that you're
saying here.
lol, simple:
FlightGear knows of various airports that I can pick to start at,
but these airports aren't all *visible* within FlightGear, so -
even if I am sure that I am at the right coordinates I don't see
a specific airport or rather runway layout.
This happens also with standard airports that are selectable
from the corresponding dialog.
My assumption was hence, that the airports are currently bound to
the scenery, as I don't have much additional scenery installed.
That's why I thought that not all airports/runways might already be
available.
So the question is, whether that's true or if there's anything else
wrong with my base package.
I was a bit surprised to learn that, since I thought FlightGear uses 
X-Planes Navaids/Airports info - and X-Plane deals with scenery and
airports separately, so it doesn't matter if I have the necessary
scenery installed or not, because the airports, including the proper
runway aligment will always be available, even if that means that
KLAS 25 R becomes an island within the ocean ;-)

Just tell me if you need even another version of this :-)



Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

[Flightgear-devel] Re: --fog-fastest & --fog-disabled - the latter w/o update below horizon ?

[Alex Romosan]

Chris Metzler <[EMAIL PROTECTED]> writes:

>> Regarding the navaids discussion I'd like to know if airports
>> are currently exclusively bound to the scenery, actually I
>> was looking for some airports that FlightGear also finds, but
>> didn't see any rwys - if airports should really depend on specific
>> scenery to be installed, it might be worth to think about
>> separating airports from scenery - at least the basics like
>> runways etc ...or what else is the reason for not _seeing_
>> an airport which FlightGear actually knows of ?
>
> Can you rephrase this?  I can't figure out what it is that you're
> saying here.

the graphics part of the airports _is_ part of the scenery. FlightGear
looks up the latitude and longitude and the position and heading of
the runways (in runways.dat) but if the scenery is not there there
are no graphics to be loaded so you get positioned over the ocean.

--alex--

-- 
| I believe the moment is at hand when, by a paranoiac and active |
|  advance of the mind, it will be possible (simultaneously with  |
|  automatism and other passive states) to systematize confusion  |
|  and thus to help to discredit completely the world of reality. |

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] lights flaring on runways in FG

[Chris Metzler]

On Sat, 24 Jul 2004 12:04:53 -0400
Josh Babcock <[EMAIL PROTECTED]> wrote:
>Frederic Bouvier wrote:
>> 
>> Could you post screenshots ?
>> 
>> -Fred
> 
> If someone gives me an ftp site to put them on.

You may have already passed them to Ampere; but I have webspace I
use for just this purpose if you need it.  

Also, as an aside, I have a personal GPS for about the next month,
if you wanna start getting positions for things.

-c

-- 
Chris Metzler   [EMAIL PROTECTED]
(remove "snip-me." to email)

"As a child I understood how to give; I have forgotten this grace since I
have become civilized." - Chief Luther Standing Bear


pgpgjWTDUzD8G.pgp
Description: PGP signature
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] --fog-fastest & --fog-disabled - the latter w/o update below horizon ?

[Chris Metzler]

On Sat, 24 Jul 2004 21:32:25 +0200
Boris Koenig <[EMAIL PROTECTED]> wrote:
>
> A couple of other things: I *did* search, but didn't find
> a way to directly set the heading of an aircraft if you
> want to position it in air - if it's there already, please
> tell me where :-)
> 
> If it isn't it might be worth to be added ?

What did you search?

Place #1:

} stax:~-534> fgfs --help --verbose
}
} Usage: fgfs [ option ... ]
}
} General Options:
}   --help, -h   Show the most relevant command line options
}   --verbose, -vShow all command line options when
combined
}with --help or -h
}   --fg-root=path   Specify the root data path
}   --fg-scenery=pathSpecify the base scenery path;
}Defaults to $FG_ROOT/Scenery
}   --language=code  Select the language for this session
[ snip ]
}   --lon=degreesStarting longitude (west = -)
}   --lat=degreesStarting latitude (south = -)
}   --altitude=value Starting altitude
}(in feet unless --units-meters specified)
}   --heading=degreesSpecify heading (yaw) angle (Psi)
^^

Place #2:  in Docs/getstart.pdf, Chapter 4 "Takeoff:  How to start
the program", Section 4 "Command Line Parameters", we come to 4.4.5,
"Initial Position and Orientation", which gives the same info as above.
This can also be found in the HTML version of this document, at
Docs/InstallGuide/html/getstart.html (click on 4.4, "Command line
parameters").


> Regarding the navaids discussion I'd like to know if airports
> are currently exclusively bound to the scenery, actually I
> was looking for some airports that FlightGear also finds, but
> didn't see any rwys - if airports should really depend on specific
> scenery to be installed, it might be worth to think about
> separating airports from scenery - at least the basics like
> runways etc ...or what else is the reason for not _seeing_
> an airport which FlightGear actually knows of ?

Can you rephrase this?  I can't figure out what it is that you're
saying here.

-c

-- 
Chris Metzler   [EMAIL PROTECTED]
(remove "snip-me." to email)

"As a child I understood how to give; I have forgotten this grace since I
have become civilized." - Chief Luther Standing Bear


pgpXSqw8xqFYr.pgp
Description: PGP signature
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

..Coffmann starters on Merlins: [Flightgear-devel] Re: Is 'Scenery Loading...' mandatory ?

[Arnt Karlsen]

On Sat, 24 Jul 2004 19:58:30 +0100, Vivian wrote in message 
<[EMAIL PROTECTED]>:
> 
> It starts exactly the way it says in the POH.
> 
> Magneto switches to on, advance throttle a little, press start button,
> keep pressed until engine fires.
> 
> If it fails to fire, re-index the Coffman starter by pulling the
> ringpull, then try again. You have 6 cartridges.

..did the Packard Merlins also used it?

..how many blades (or prop or crankshaft turns) per cartridge?
Common cartridge-only rpm and decay turns and time to stop 
(on failed starts)?

..on successful starts, how many blades 'till the 1'st one fires", 
then how many misses until smooth running idle?

..it commonly starts on first, 2'nd or 3'rd etc fired?

..can 1, 2, or 3 etc Coffmans start a flooded engine?  (Assuming 
no cround crew assistance but corrective action by the pilot.)

..approximates, obviously, ideally, someone has talked with 
WWII tech or pilot veterans with relevant Merlin experience.

..btw, did anyone fix the boost b button bug?  (2-speed 
supercharger clutch barometer triggered at 18,000 ft or 
somesuch on RR in Spit mkix and Packards in P-51B
onwards etc)

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] FliteTuror (Was: Adding external nasal bindings & fgcommands)

[Boris Koenig]

Let's get back to this one :-)
Erik Hofman wrote:
Boris Koenig wrote:
I wouldn't have a problem, creating the authoring part of the
application as an external application - but THEN I would need
to be able to load FlightGear resources (aircraft/images/panels).

Ok. Lets start a *minimal* list of items that really are needed for this 
and skip the implementation part for now. This is what I think what 
would be needed (feel free to add your ideas).
Anything else (remember, this is the *absolute minimum*)?
Besides the things that I mentioned already in the original "short" ;-)
reply to your message, I think the two most important things would
currently be:
-   basic functionality to deal with XML files (using Nasal)
-   dynamic creation & population/modification of
controls/dialogs using Nasal
Also, some more customization of the current PUI XML-bindings might be
necessary, in order to be able to tailor dialogs/controls (i.e.
 transparency/movable flag) - Andy mentioned something like this already
- if you take a look at the  screenshot on the FliteTutor concept
webpage, you'll notice for example, that the combo box in the upper left
corner opens upwards, while it should -in this case- actually open
downwards (otherwise the menu contents aren't visible anymore).
Using PUI directly it's afaIk possible to specify such details -
hence it shouldn't be too complicated to add a corresponding option
to the XML<->PUI layer.
I would be willing to make the necessary modifications myself, also to
add things like basic font formatting - would these changes then be
accepted for the official CVS version ?
You know, that's the actual problem I was having, also regarding the
whole plugin stuff that I mentioned: making such modifications directly
to FlightGear sources would always require these things to be accepted
for FlightGear itself, while having a separate library taking care of
this stuff wouldn't require any direct access to FlightGear in most
cases, hence one wouldn't rely on a particular FlightGear release/build
to be able to use a new function, which is actually not even part of
FlightGear itself...
Regarding the standard FlightGear menubar, I think it might be useful
to optionally make it auto-hide/show - that way it would only be
displayed if the mouse is in the corresponding area, and fade out as
soon as the mouse leaves that area.
In the end, I don't mean to blow up Nasal, but rather use some scripts
as backend library to load & display a set of pages - but of course
this would still require some additions to the current command set.
But I don't think this would be too dramatic, on the other hand adding
a couple of new functions/bindings might also create new possibilites,
one might even start to create things like a FMC based on Nasal.
Hope this mail was short enough ;-)
-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

[Flightgear-devel] Re: Is 'Scenery Loading...' mandatory ?

[Alex Romosan]

"Vivian Meazza" <[EMAIL PROTECTED]> writes:

> It starts exactly the way it says in the POH.
>
> Magneto switches to on, advance throttle a little, press start button, keep
> pressed until engine fires.

so, in terms of keyboard commands this should be { } (magneto switches
on) and then press space bar?

> If it fails to fire, re-index the Coffman starter by pulling the ringpull,
> then try again. You have 6 cartridges.

it does. so i press C and try space bar again. the propeller sputters
a bit and that's it.

> To stop, pull the cut-off ring pull.

i'll deal with that once i manage to start the engine... :-)

--alex--

-- 
| I believe the moment is at hand when, by a paranoiac and active |
|  advance of the mind, it will be possible (simultaneously with  |
|  automatism and other passive states) to systematize confusion  |
|  and thus to help to discredit completely the world of reality. |

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

[Flightgear-devel] --fog-fastest & --fog-disabled - the latter w/o update below horizon ?

[Boris Koenig]

Hi !
I've noticed some weird behaviour using the two options mentioned in the 
subject: as soon as I totally disable the fog the area below the horizon
 remains black and isn't updated during flight either.

For illustration purposes I've created two screenshots, one using
--fog-fastest:
http://flitetutor.sourceforge.net/mlist/fgfs-screen-fog-fastest.png
and the other one using
--fog-disabled:
http://flitetutor.sourceforge.net/mlist/fgfs-screen-fog-disabled.png
So, practically I've a black area when using --fog-disabled - and don't
see any ground textures in that area either - while the latter are
partially visible with fog enabled.
A couple of other things: I *did* search, but didn't find
a way to directly set the heading of an aircraft if you
want to position it in air - if it's there already, please
tell me where :-)
If it isn't it might be worth to be added ?
Also, it might be useful if there's optionally
some "pause" info displayed when the game's paused.
Regarding the navaids discussion I'd like to know if airports
are currently exclusively bound to the scenery, actually I
was looking for some airports that FlightGear also finds, but
didn't see any rwys - if airports should really depend on specific
scenery to be installed, it might be worth to think about
separating airports from scenery - at least the basics like
runways etc ...or what else is the reason for not _seeing_
an airport which FlightGear actually knows of ?

-
Boris


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

RE: [Flightgear-devel] Re: Is 'Scenery Loading...' mandatory ?

[Vivian Meazza]

Alex Romosan wrote:

> Sent: 24 July 2004 19:35
> To: FlightGear developers discussions
> Subject: [Flightgear-devel] Re: Is 'Scenery Loading...' mandatory ?
> 
> "Frederic Bouvier" <[EMAIL PROTECTED]> writes:
> 
> > Is there a way to avoid the initial lock for scenery loading ?
> > I understand this is a must have for users, but it slows
> > down development speed dramatically when you have to test the
> > apparence of a new building or landmark.
> 
> i think the fix for the scenery loading is not quite right. with it i
> get a very strange spitfire cockpit (i.e. i can see through the
> instrument panel and the body of the aircraft). looks like z-buffer
> ordering is not done properly (screen depth is 16bp, using the radeon
> freedesktop drivers). if i disable it, the cockpit looks normal again.
> if could only figure out how to start the damn plane...
> 
> btw, the attached patch backs out of the "scenery loading" hack.

It starts exactly the way it says in the POH.

Magneto switches to on, advance throttle a little, press start button, keep
pressed until engine fires.

If it fails to fire, re-index the Coffman starter by pulling the ringpull,
then try again. You have 6 cartridges.

To stop, pull the cut-off ring pull.

Regards,

Vivian





___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

RE: [Flightgear-devel] Tried the Spitfire

[Vivian Meazza]

Ampere K. Hardraade wrote:

> Sent: 24 July 2004 18:58
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Tried the Spitfire
> 
> Can't you make it so that the engine feeds off the upper tank before it
> feeds
> on the lower tank?
> 
> Regards,
> Ampere
> 
> On July 24, 2004 01:42 pm, Vivian Meazza wrote:
> > I'm just working on the fuel gauge for the Spitfire, when I ralised that
> I
> > haven't modeled the fuel system correctly. At present both tanks feed
> into
> > the engine. What should happen is that the upper tank feeds the lower
> tank
> > which feeds the engine. Is there any built-in way of doing this?
> >
> > Advice would be most welcome, otherwise I guess it's some fairly complex
> > NASAL?
> >
> > Regards,
> >
> > Vivian
> 

That is of course equivalent, and might well be the way to implement it in
practice. How?

Regards,

Vivian



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

[Flightgear-devel] Re: Is 'Scenery Loading...' mandatory ?

[Alex Romosan]

"Frederic Bouvier" <[EMAIL PROTECTED]> writes:

> Is there a way to avoid the initial lock for scenery loading ?
> I understand this is a must have for users, but it slows 
> down development speed dramatically when you have to test the 
> apparence of a new building or landmark.

i think the fix for the scenery loading is not quite right. with it i
get a very strange spitfire cockpit (i.e. i can see through the
instrument panel and the body of the aircraft). looks like z-buffer
ordering is not done properly (screen depth is 16bp, using the radeon
freedesktop drivers). if i disable it, the cockpit looks normal again.
if could only figure out how to start the damn plane...

btw, the attached patch backs out of the "scenery loading" hack.

Index: main.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v
retrieving revision 1.173
diff -u -r1.173 main.cxx
--- main.cxx	23 Jul 2004 07:33:24 -	1.173
+++ main.cxx	24 Jul 2004 18:27:09 -
@@ -1209,13 +1209,13 @@
 if ( global_multi_loop > 0) {
 // first run the flight model each frame until it is intialized
 // then continue running each frame only after initial scenery load is complete.
-if (!cur_fdm_state->get_inited() || fgGetBool("sim/sceneryloaded")) {
+//if (!cur_fdm_state->get_inited() || fgGetBool("sim/sceneryloaded")) {
 fgUpdateTimeDepCalcs();
-} else {
-// only during scenery load
-NewGUI * gui = (NewGUI *)globals->get_subsystem("gui");
-gui->showDialog("scenery_loading");
-}
+//} else {
+//// only during scenery load
+//NewGUI * gui = (NewGUI *)globals->get_subsystem("gui");
+//gui->showDialog("scenery_loading");
+//}
 } else {
 SG_LOG( SG_ALL, SG_DEBUG, 
 "Elapsed time is zero ... we're zinging" );
@@ -1339,12 +1339,12 @@
 
 // END Tile Manager udpates
 
-if (!fgGetBool("sim/sceneryloaded") && globals->get_tile_mgr()->all_queues_empty() && cur_fdm_state->get_inited()) {
-fgSetBool("sim/sceneryloaded",true);
+//if (!fgGetBool("sim/sceneryloaded") && globals->get_tile_mgr()->all_queues_empty() && cur_fdm_state->get_inited()) {
+//fgSetBool("sim/sceneryloaded",true);
 // probably not efficient way to popup msg,  but is done only during scenery load
-NewGUI * gui = (NewGUI *)globals->get_subsystem("gui");
-gui->closeDialog("scenery_loading");
-}
+//NewGUI * gui = (NewGUI *)globals->get_subsystem("gui");
+//gui->closeDialog("scenery_loading");
+//}
 
 if (fgGetBool("/sim/rendering/specular-highlight")) {
 glLightModeli(GL_LIGHT_MODEL_COLOR_CONTROL, GL_SEPARATE_SPECULAR_COLOR);

--alex--

-- 
| I believe the moment is at hand when, by a paranoiac and active |
|  advance of the mind, it will be possible (simultaneously with  |
|  automatism and other passive states) to systematize confusion  |
|  and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Tried the Spitfire

[Ampere K. Hardraade]

Can't you make it so that the engine feeds off the upper tank before it feeds 
on the lower tank?

Regards,
Ampere

On July 24, 2004 01:42 pm, Vivian Meazza wrote:
> I'm just working on the fuel gauge for the Spitfire, when I ralised that I
> haven't modeled the fuel system correctly. At present both tanks feed into
> the engine. What should happen is that the upper tank feeds the lower tank
> which feeds the engine. Is there any built-in way of doing this?
>
> Advice would be most welcome, otherwise I guess it's some fairly complex
> NASAL?
>
> Regards,
>
> Vivian

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

RE: [Flightgear-devel] Tried the Spitfire

[Vivian Meazza]

Vivian Meazza wrote:

> Sent: 23 July 2004 20:15
> To: 'FlightGear developers discussions'
> Subject: RE: [Flightgear-devel] Tried the Spitfire
> 
> 
> 
> Jim Wilson wrote:
> 
> 
> > Sent: 23 July 2004 16:01
> > To: [EMAIL PROTECTED]
> > Subject: [Flightgear-devel] Tried the Spitfire
> >
> > Very nice!  Ok if I borrow the pilot dude for the p51 cockpit?
> 
> Please do - but note that he's wearing RAF blue serge trousers (pants :-
> )),
> and 1940's pattern life jacket (vest) and the wrong flying helmet/goggles.
> I
> expect some smarty pants will notice. I'm going to animate him shortly.
> 
> > Now, should it come up running like the other A/C?  My personal
> preference
> > is
> > to not, but I think in the past folks have prefered aircraft already
> > started.
> 
> Tough one, because when I get the propeller sorted there should be the
> possibility that the aircraft will nose over if started on full throttle.
> 
> > FWIW (after release) I think a preset "e.g. --auto-start" that defaulted
> > to
> > true, and was overridden as true automatically for mid air starts, but
> > otherwise could be set false by the user so aircraft never come up
> running
> > on
> > the ground would be nice.  Along this line it should be possible to have
> > aircraft running after reset as well if --auto-start was enabled.
> 
> I like it - it's the way that Flight2 does it. Personally, I like to start
> with the engine shut down. It forces pre-start checks, and makes the whole
> thing more realistic. I was also following the example of the Bo105.
> 

I'm just working on the fuel gauge for the Spitfire, when I ralised that I
haven't modeled the fuel system correctly. At present both tanks feed into
the engine. What should happen is that the upper tank feeds the lower tank
which feeds the engine. Is there any built-in way of doing this?

Advice would be most welcome, otherwise I guess it's some fairly complex
NASAL?

Regards,

Vivian



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] compilation of current cvs version fails

[Oliver C.]

On Saturday 24 July 2004 17:41, Curtis L. Olson wrote:
> I'd start by recompiling and reinstalling all of simgear ... if you've
> upgraded your compilers recently, code compiled with  the new C++
> compiler may not be able to link against code compiled with an older
> version.
>
> Regards,
>
> Curt.
>

Thank you very much, that worked. :)
I forgot to do a "make clean" in my SimGear CVS directory. 

Best Regards,
 Oliver C.

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] lights flaring on runways in FG

[Ampere K. Hardraade]

Send them to me in an attachment.

Regards,
Ampere

On July 24, 2004 12:04 pm, Josh Babcock wrote:
> If someone gives me an ftp site to put them on.

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Error message from the latest CVS

[Ampere K. Hardraade]

I believe so.  I am using the 0.9.5-pre-2 base package .

Regards,
Ampere

On July 24, 2004 03:29 am, Erik Hofman wrote:
> Ampere K. Hardraade wrote:
> > Dialog scenery_loading not defined
> >
> > The message only appears when one is in KSFO.  As for other airports, the
> > message doesn't appear; neither does the scenery.  All there is is an
> > ocean.
>
> Is you base package in sync with FlightGear?
> Both FlightGear and the base package where modified for this feature.
>
> Erik
>
> ___
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Took advantage of Erik's...

[Ampere K. Hardraade]

No.  What I want to do is tell each of these animation file where the livery 
resides.  I want to be able to tell all of them with in one single file, 
instead of having to create a new xml file for every animation file.

Regards,
Ampere

On July 24, 2004 03:37 am, Erik Hofman wrote:
> I believe this is what you want, isn't it?

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] lights flaring on runways in FG

[Josh Babcock]

Lee Elliott wrote:
Are you able to fly at night i.e. when the sun is below the horizon?  If I try 
flying in these conditions FG starts but crashes once I get a few hundred 
feet in the air and I think this is also due to the ATI drivers.
Yeah, that's the problem I get.  Once the sun is below the horizon, I have about 
one hundred seconds until it segfaults.  With the old ATI driver, this would 
hang X, but the latest one survives fgfs segfaulting.  The end of the stack 
trace always looks roughly the same too:

read(14, 0xa57f244, 8)  = -1 EAGAIN (Resource temporarily 
unavailable)
getpid()= 4368
ioctl(6, 0x4008642a, 0xb4e8)= 0
getpid()= 4368
getpid()= 4368
ioctl(6, 0x4008642a, 0xbfffec18)= 0
ioctl(6, 0x4008642a, 0xbfffead8)= 0
getpid()= 4368
getpid()= 4368
ioctl(6, 0x4008642a, 0xb668)= 0
getpid()= 4368
ioctl(5, FIONREAD, [0]) = 0
gettimeofday({1090465804, 754367}, {240, 0}) = 0
time(NULL)  = 1090465804
time(NULL)  = 1090465804
gettimeofday({1090465804, 754995}, {240, 0}) = 0
gettimeofday({1090465804, 755221}, {240, 0}) = 0
select(1024, [12 13], [13], NULL, {0, 0}) = 0 (Timeout)
time(NULL)  = 1090465804
read(14, 0xa57f244, 8)  = -1 EAGAIN (Resource temporarily 
unavailable)
getpid()= 4368
ioctl(6, 0x4008642a, 0xb4e8)= 0
getpid()= 4368
getpid()= 4368
ioctl(6, 0x4008642a, 0xbfffec18)= 0
ioctl(6, 0x4008642a, 0xbfffead8)= 0
getpid()= 4368
getpid()= 4368
ioctl(6, 0x4008642a, 0xb668)= 0
getpid()= 4368
ioctl(5, FIONREAD, [0]) = 0
gettimeofday({1090465804, 793631}, {240, 0}) = 0
time(NULL)  = 1090465804
time(NULL)  = 1090465804
gettimeofday({1090465804, 794071}, {240, 0}) = 0
gettimeofday({1090465804, 794347}, {240, 0}) = 0
gettimeofday({1090465804, 794391}, {240, 0}) = 0
time(NULL)  = 1090465804
read(14, 0xa57f244, 8)  = -1 EAGAIN (Resource temporarily 
unavailable)
getpid()= 4368
ioctl(6, 0x4008642a, 0xb4e8)= 0
getpid()= 4368
getpid()= 4368
ioctl(6, 0x4008642a, 0xbfffec18)= 0
ioctl(6, 0x4008642a, 0xbfffead8)= 0
getpid()= 4368
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

Josh
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] lights flaring on runways in FG

[Josh Babcock]

Frederic Bouvier wrote:
I get the same ground poly problems that you seem to be getting with your
new
ATI driver, except I've been getting them for some time now.
It actually only seems to be the airfield polys that are affected but
you'll
often see it with airfields that are a long way away, to the extent that
you
can't see the airfield itself but only the displaced polys as they sick up
through the haze, sometimes to many tens of thousand of feet.

Could you post screenshots ?
-Fred

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
If someone gives me an ftp site to put them on.
Josh
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] compilation of current cvs version fails

[Curtis L. Olson]

I'd start by recompiling and reinstalling all of simgear ... if you've 
upgraded your compilers recently, code compiled with  the new C++ 
compiler may not be able to link against code compiled with an older 
version.

Regards,
Curt.
Oliver C. wrote:
Hello,
Today i tried to compile the current cvs version of flightgear
and get the following error messages:
make[2]: Entering directory 
`/home/oliver/x/src/cvs/flightgear/source/src/Main'
g++ -DPKGLIBDIR=\"/usr/local/share/FlightGear\" -g -O2 -D_REENTRANT  
-L/usr/X11R6/lib -L/usr/local//lib -o fgfs  
bootstrap.o ../../src/Main/libMain.a ../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.a ../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_in/libBuilt_in.a ../../src/Controls/libControls.a ../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a ../../src/FDM/ExternalNet/libExternalNet.a ../../src/FDM/ExternalPipe/libExternalPipe.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/YASim/libYASim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a ../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/GUI/libGUI.a ../../src/Autopilot/libAutopilot.a ../../src/Input/libInput.a ../../src/Instrumentation/libInstrumentation.a ../../src/Model/libModel.a ../../src/AIModel/libAIModel.a ../../src/Network/libNetwork.a ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a ../../src/Scripting/libScripting.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/MultiPlayer/libMultiPlayer.a ../../src/Replay/libReplay.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a ../../src/Traffic/libTraffic.a ../../src/Environment/libEnvironment.a 
-lsgclouds3d -lsgroute -lsgsky -lsgsound -lsgephem -lsgmaterial -lsgtgdb 
-lsgmodel -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgprops 
-lsgdebug -lsgmagvar -lsgmisc -lsgnasal -lsgxml -lsgsound -lsgserial 
-lsgstructure -lsgenvironment -lsgthreads -lpthread  -lplibpu -lplibfnt 
-lplibjs -lplibnet -lplibssg -lplibsg -lplibul  -lz -lglut -lGLU -lGL -lXmu 
-lXt -lSM -lICE -lXi -lXext -lX11 -ldl -lm  -lopenal -ldl -lm
/usr/local//lib/libsgclouds3d.a(camutils.o)(.text+0x634): In function 
`CamMinMaxBoxOverlap(Camera const*, Vec3 const*, float const (*) [4], 
Vec3 const&, Vec3 const&)':
/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:165: 
undefined reference to `EdgeMinMaxBoxIsect(float const*, float const*, float 
const*, float const*, float*, float*)'
/usr/local//lib/libsgclouds3d.a(camutils.o)
(.text+0x676):/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:166: 
undefined reference to `EdgeMinMaxBoxIsect(float const*, float const*, float 
const*, float const*, float*, float*)'
/usr/local//lib/libsgclouds3d.a(camutils.o)
(.text+0x6b4):/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:167: 
undefined reference to `EdgeMinMaxBoxIsect(float const*, float const*, float 
const*, float const*, float*, float*)'
/usr/local//lib/libsgclouds3d.a(camutils.o)
(.text+0x6f2):/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:168: 
undefined reference to `EdgeMinMaxBoxIsect(float const*, float const*, float 
const*, float const*, float*, float*)'
/usr/local//lib/libsgclouds3d.a(camutils.o)
(.text+0x71f):/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:169: 
undefined reference to `EdgeMinMaxBoxIsect(float const*, float const*, float 
const*, float const*, float*, float*)'
/usr/local//lib/libsgclouds3d.a(camutils.o)
(.text+0x74f):/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:170: 
more undefined references to `EdgeMinMaxBoxIsect(float const*, float const*, 
float const*, float const*, float*, float*)' follow
/usr/local//lib/libsgclouds3d.a(camutils.o)(.text+0x8ac): In function 
`CamMinMaxBoxOverlap(Camera const*, Vec3 const*, float const (*) [4], 
Vec3 const&, Vec3 const&)':
/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:180: 
undefined reference to `GetMinMaxBoxVerts(float const*, float const*, float 
(*) [3])'
collect2: ld returned 1 exit status
make[2]: *** [fgfs] Error 1
make[2]: Leaving directory `/home/oliver/x/src/cvs/flightgear/source/src/Main'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/oliver/x/src/cvs/flightgear/source/src'
make: *** [all-recursive] Error 1


Any ideas to fix this?
I tried this on Slackware 10.0 with the current cvs version of SimGear, OpenAL 
and Plib.

Best Regards,
Oliver C.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
 


--
Curtis Olsonhttp://www.flightgear.org/~curt 
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightg

[Flightgear-devel] OT: Laptop! - Frame Rate

[Chris Horler]

Hi,

Got my Laptop, installed Linux, installed the latest ATI driver (although only 
running SuSe's 9.1 updated kernel - 2.6.5)

I'm running fgl_glxgears (probably not an unbiased test given it's ATIs code I 
would guess).  I'm getting 490fps - looks good.  I'm going to investigate 
exactly what ATI provide now.  I started off with their packages this 
morning, had to do a few mods to get it compiling... then noticed that SuSe 
are providing a customised version that runs out of the box... now using 
that.

I'll let you know fg frames rates in the short term future.

Regards,

Chris.

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

[Flightgear-devel] compilation of current cvs version fails

[Oliver C.]

Hello,

Today i tried to compile the current cvs version of flightgear
and get the following error messages:

make[2]: Entering directory 
`/home/oliver/x/src/cvs/flightgear/source/src/Main'
g++ -DPKGLIBDIR=\"/usr/local/share/FlightGear\" -g -O2 -D_REENTRANT  
-L/usr/X11R6/lib -L/usr/local//lib -o fgfs  
bootstrap.o ../../src/Main/libMain.a ../../src/Aircraft/libAircraft.a 
../../src/ATC/libATC.a ../../src/Cockpit/libCockpit.a 
../../src/Cockpit/built_in/libBuilt_in.a ../../src/Controls/libControls.a 
../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a 
../../src/FDM/ExternalNet/libExternalNet.a 
../../src/FDM/ExternalPipe/libExternalPipe.a ../../src/FDM/JSBSim/libJSBSim.a 
../../src/FDM/YASim/libYASim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a 
../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a 
../../src/GUI/libGUI.a ../../src/Autopilot/libAutopilot.a ../../src/Input/libInput.a 
../../src/Instrumentation/libInstrumentation.a ../../src/Model/libModel.a 
../../src/AIModel/libAIModel.a ../../src/Network/libNetwork.a 
../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a 
../../src/Scripting/libScripting.a ../../src/Sound/libSound.a 
../../src/Airports/libAirports.a ../../src/MultiPlayer/libMultiPlayer.a 
../../src/Replay/libReplay.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a 
../../src/Traffic/libTraffic.a ../../src/Environment/libEnvironment.a 
-lsgclouds3d -lsgroute -lsgsky -lsgsound -lsgephem -lsgmaterial -lsgtgdb 
-lsgmodel -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgprops 
-lsgdebug -lsgmagvar -lsgmisc -lsgnasal -lsgxml -lsgsound -lsgserial 
-lsgstructure -lsgenvironment -lsgthreads -lpthread  -lplibpu -lplibfnt 
-lplibjs -lplibnet -lplibssg -lplibsg -lplibul  -lz -lglut -lGLU -lGL -lXmu 
-lXt -lSM -lICE -lXi -lXext -lX11 -ldl -lm  -lopenal -ldl -lm
/usr/local//lib/libsgclouds3d.a(camutils.o)(.text+0x634): In function 
`CamMinMaxBoxOverlap(Camera const*, Vec3 const*, float const (*) [4], 
Vec3 const&, Vec3 const&)':
/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:165: 
undefined reference to `EdgeMinMaxBoxIsect(float const*, float const*, float 
const*, float const*, float*, float*)'
/usr/local//lib/libsgclouds3d.a(camutils.o)
(.text+0x676):/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:166:
 
undefined reference to `EdgeMinMaxBoxIsect(float const*, float const*, float 
const*, float const*, float*, float*)'
/usr/local//lib/libsgclouds3d.a(camutils.o)
(.text+0x6b4):/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:167:
 
undefined reference to `EdgeMinMaxBoxIsect(float const*, float const*, float 
const*, float const*, float*, float*)'
/usr/local//lib/libsgclouds3d.a(camutils.o)
(.text+0x6f2):/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:168:
 
undefined reference to `EdgeMinMaxBoxIsect(float const*, float const*, float 
const*, float const*, float*, float*)'
/usr/local//lib/libsgclouds3d.a(camutils.o)
(.text+0x71f):/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:169:
 
undefined reference to `EdgeMinMaxBoxIsect(float const*, float const*, float 
const*, float const*, float*, float*)'
/usr/local//lib/libsgclouds3d.a(camutils.o)
(.text+0x74f):/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:170:
 
more undefined references to `EdgeMinMaxBoxIsect(float const*, float const*, 
float const*, float const*, float*, float*)' follow
/usr/local//lib/libsgclouds3d.a(camutils.o)(.text+0x8ac): In function 
`CamMinMaxBoxOverlap(Camera const*, Vec3 const*, float const (*) [4], 
Vec3 const&, Vec3 const&)':
/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:180: 
undefined reference to `GetMinMaxBoxVerts(float const*, float const*, float 
(*) [3])'
collect2: ld returned 1 exit status
make[2]: *** [fgfs] Error 1
make[2]: Leaving directory `/home/oliver/x/src/cvs/flightgear/source/src/Main'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/oliver/x/src/cvs/flightgear/source/src'
make: *** [all-recursive] Error 1



Any ideas to fix this?
I tried this on Slackware 10.0 with the current cvs version of SimGear, OpenAL 
and Plib.


Best Regards,
 Oliver C.


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.104, 1.105 main.cxx, 1.171, 1.172

[Arnt Karlsen]

On Fri, 23 Jul 2004 16:00:08 +0100, Al wrote in message 
<[EMAIL PROTECTED]>:

> On Friday 23 July 2004 15:23, Jim Wilson wrote:
> >
> > Sure enough, it's right there in Stroustrup.  The strange part is
> > never having noticed this before now.  What is it with these
> > developers at microsoft anyway? ;-)
> >
> 
> Since when have they had developers?

..define "developer", the SCO Group claims to have 
"4000 world wide".  ;-)

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] create craters and smoke effect

[Arnt Karlsen]

On Thu, 22 Jul 2004 21:27:02 -0400, Ampere wrote in message 
<[EMAIL PROTECTED]>:

> On July 22, 2004 02:13 pm, CHANDRASEKHAR ACHALLA wrote:
> > I need to
> > create a crater (hole) if a plane crashes 
> Plane crash doesn't create craters.  All there is is a black patch.

..depends on the "what is hit by what", and how.   ;-)

> > (or a missile )
> ...
> 
> > . I also need to  
> > simulate smoke and fire coming out of the crater.
> If you also want the aircraft to break apart, you can try using the
> MD11.  I have designed it so that many parts are individual objects. 
> If anyone wants to create realistic plane crash scene for the MD11, he
> or she can give one object after another an independent trajectory.

..ooo, that means FG can be used to "reverse-engineer" 
a wreakage trail. 

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] create craters and smoke effect

[Arnt Karlsen]

On Thu, 22 Jul 2004 20:02:25 -, Jim wrote in message 
<[EMAIL PROTECTED]>:

> Andy Ross said:
> 
> > CHANDRASEKHAR ACHALLA wrote:
> > > I am doing a project for Boeing where I am trying to incorporate a
> > > few additional features they want into Flightgear. Initially I
> > > need to create a crater (hole) if a plane crashes (or a missile ).
> > 
> > Boing wants craters?  :)
> 
> That's it!  I'm flying on Aerobus airliners only from now on.

..it couldn't be their and not their own, they're modelling? ;-)

> 
> > 
> > Alternatively, I suppose you could alpha-blend a "2D" crater image
> > on top of the existing geometry; something along the lines of the
> > "bullet holes" that first person shooter games like to draw on
> > walls.  For a flight simulator where the viewpoint isn't likely to
> > be very near the crater, this might be sufficient.
> 
> Yes and much easier.  You could even just make a model that was mostly
> flat but had a crater lip with burnt dirt texture and all that and
> just plop it on the ground in the right spot.

..crater size and depht depends on impact energy etc in RL, so you're
having your FG crater act accordingly? 

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] lights flaring on runways in FG

[Frederic Bouvier]

> I get the same ground poly problems that you seem to be getting with your
new
> ATI driver, except I've been getting them for some time now.
>
> It actually only seems to be the airfield polys that are affected but
you'll
> often see it with airfields that are a long way away, to the extent that
you
> can't see the airfield itself but only the displaced polys as they sick up
> through the haze, sometimes to many tens of thousand of feet.

Could you post screenshots ?

-Fred



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] lights flaring on runways in FG

[Lee Elliott]

On Saturday 24 July 2004 15:35, Lee Elliott wrote:
> On Saturday 24 July 2004 14:38, Josh Babcock wrote:
> > Peter Larson wrote:
> > > Not sure this is the right forum, I'm getting coloured apostraphe
> > > shapes around 200 pixels high on the screen. They appear to be related
> > > to runway lights. They also appear while the sim is in the air.
> > > I'm running Windows XP Pro with a Radeon 9200SE video card and Gigabyte
> > > GA-7VT600 motherboard. Drivers all loaded within the last week.
> > > Any ideas?
> > > Regards
> > > Peter
> > >
> > >
> > > ---
> > > Outgoing mail is certified Virus Free.
> > > Checked by AVG anti-virus system (http://www.grisoft.com).
> > > Version: 6.0.718 / Virus Database: 474 - Release Date: 9/07/2004
> > >
> > >
> > > ___
> > > Flightgear-devel mailing list
> > > [EMAIL PROTECTED]
> > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> >
> > I also have this problem, and have been having it for several months,
> > using many different CVS versions and several different fglrx versions. 
> > You can make it go away by turning off enhanced runway lighting.
> >
> > Do you also get segfault s after flying at night for a few minutes?  I
> > have this problem as well, though it started later (I think), but not by
> > much. I have no workaround for this one.  I have a few straces that all
> > end the same way laying around from this one, if anyone is interested in
> > looking at them.
> >
> > Also, with the latest ATI driver, I started seeing random ground vertexes
> > shifted around, sometimes leaving entire ground polys up in the air, and
> > many holes in the terrain.  These come and go as I move about and are
> > most common over airports.  I haven't gone back to an old driver to
> > confirm that this is in fact the driver, and not a coincidence of
> > updating the driver and fgfs source code at the same time, though I'm
> > pretty sure it was the driver update that started it.
> >
> > display: :0.0  screen: 0
> > OpenGL vendor string: ATI Technologies Inc.
> > OpenGL renderer string: RADEON 8500 DDR Generic
> > OpenGL version string: 1.3 (X4.3.0-3.9.0)
> >
> > Linux tower 2.4.22 #24 Fri Nov 14 19:34:40 EST 2003 i686 athlon i386
> > GNU/Linux
> >
> > Josh
>
> I get the same ground poly problems that you seem to be getting with your
> new ATI driver, except I've been getting them for some time now.
>
> It actually only seems to be the airfield polys that are affected but
> you'll often see it with airfields that are a long way away, to the extent
> that you can't see the airfield itself but only the displaced polys as they
> sick up through the haze, sometimes to many tens of thousand of feet.
>
> Are you able to fly at night i.e. when the sun is below the horizon?  If I
> try flying in these conditions FG starts but crashes once I get a few
> hundred feet in the air and I think this is also due to the ATI drivers.
>
> LeeE

Oops! - I see you already have the night problem too - dunno why I missed 
that.

LeeE

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] lights flaring on runways in FG

[Lee Elliott]

On Saturday 24 July 2004 14:38, Josh Babcock wrote:
> Peter Larson wrote:
> > Not sure this is the right forum, I'm getting coloured apostraphe shapes
> > around 200 pixels high on the screen. They appear to be related to runway
> > lights. They also appear while the sim is in the air.
> > I'm running Windows XP Pro with a Radeon 9200SE video card and Gigabyte
> > GA-7VT600 motherboard. Drivers all loaded within the last week.
> > Any ideas?
> > Regards
> > Peter
> >
> >
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.718 / Virus Database: 474 - Release Date: 9/07/2004
> >
> >
> > ___
> > Flightgear-devel mailing list
> > [EMAIL PROTECTED]
> > http://mail.flightgear.org/mailman/listinfo/flightgear-devel
>
> I also have this problem, and have been having it for several months, using
> many different CVS versions and several different fglrx versions.  You can
> make it go away by turning off enhanced runway lighting.
>
> Do you also get segfault s after flying at night for a few minutes?  I have
> this problem as well, though it started later (I think), but not by much. 
> I have no workaround for this one.  I have a few straces that all end the
> same way laying around from this one, if anyone is interested in looking at
> them.
>
> Also, with the latest ATI driver, I started seeing random ground vertexes
> shifted around, sometimes leaving entire ground polys up in the air, and
> many holes in the terrain.  These come and go as I move about and are most
> common over airports.  I haven't gone back to an old driver to confirm that
> this is in fact the driver, and not a coincidence of updating the driver
> and fgfs source code at the same time, though I'm pretty sure it was the
> driver update that started it.
>
> display: :0.0  screen: 0
> OpenGL vendor string: ATI Technologies Inc.
> OpenGL renderer string: RADEON 8500 DDR Generic
> OpenGL version string: 1.3 (X4.3.0-3.9.0)
>
> Linux tower 2.4.22 #24 Fri Nov 14 19:34:40 EST 2003 i686 athlon i386
> GNU/Linux
>
> Josh

I get the same ground poly problems that you seem to be getting with your new 
ATI driver, except I've been getting them for some time now.

It actually only seems to be the airfield polys that are affected but you'll 
often see it with airfields that are a long way away, to the extent that you 
can't see the airfield itself but only the displaced polys as they sick up 
through the haze, sometimes to many tens of thousand of feet.

Are you able to fly at night i.e. when the sun is below the horizon?  If I try 
flying in these conditions FG starts but crashes once I get a few hundred 
feet in the air and I think this is also due to the ATI drivers.

LeeE

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] lights flaring on runways in FG

[Josh Babcock]

Peter Larson wrote:
Not sure this is the right forum, I'm getting coloured apostraphe shapes
around 200 pixels high on the screen. They appear to be related to runway
lights. They also appear while the sim is in the air.
I'm running Windows XP Pro with a Radeon 9200SE video card and Gigabyte
GA-7VT600 motherboard. Drivers all loaded within the last week.
Any ideas?
Regards
Peter
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.718 / Virus Database: 474 - Release Date: 9/07/2004
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
I also have this problem, and have been having it for several months, using many 
different CVS versions and several different fglrx versions.  You can make it go 
away by turning off enhanced runway lighting.

Do you also get segfault s after flying at night for a few minutes?  I have this 
problem as well, though it started later (I think), but not by much.  I have no 
workaround for this one.  I have a few straces that all end the same way laying 
around from this one, if anyone is interested in looking at them.

Also, with the latest ATI driver, I started seeing random ground vertexes 
shifted around, sometimes leaving entire ground polys up in the air, and many 
holes in the terrain.  These come and go as I move about and are most common 
over airports.  I haven't gone back to an old driver to confirm that this is in 
fact the driver, and not a coincidence of updating the driver and fgfs source 
code at the same time, though I'm pretty sure it was the driver update that 
started it.

display: :0.0  screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: RADEON 8500 DDR Generic
OpenGL version string: 1.3 (X4.3.0-3.9.0)
Linux tower 2.4.22 #24 Fri Nov 14 19:34:40 EST 2003 i686 athlon i386 GNU/Linux
Josh
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Flight plan missing files

[Frederic Bouvier]

Durk Talsma wrote:

> On Saturday 24 July 2004 10:13, Frederic Bouvier wrote:
> > There is a caught exception ( so it is harmless ) in
> > the XML reader because files are not in the base
> > package. Those files are :
> >
> > Data/AI/FlightPlans/KSFO-KSEA.xml
> > Data/AI/FlightPlans/KSEA-KSFO.xml
> >
> > Are the names generated randomly or are they really missing ?
> >
>
> Neither, actually. For now, this is by design. The AIFlightplan
constructor
> that the traffic manager calls tries first to open a pre-exsisting
> flightplan. If that doesn't work, however, it reverts to a fallback
procedure
> that creates a flightplan dynamically.
>
> I would like to keep that functionality, although I'm not sure if using
the
> exception mechanism is the best way to do this. I'm interested in your
folks'
> opinions.

My opinion is that exceptions are good if they are caught.
It is just that it appeared few days ago that missing files
were throwing uncaught exceptions and I was wondering if
all mandatory files were included before the release.

-Fred



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Flight plan missing files

[Durk Talsma]

On Saturday 24 July 2004 10:13, Frederic Bouvier wrote:
> There is a caught exception ( so it is harmless ) in
> the XML reader because files are not in the base
> package. Those files are :
>
> Data/AI/FlightPlans/KSFO-KSEA.xml
> Data/AI/FlightPlans/KSEA-KSFO.xml
>
> Are the names generated randomly or are they really missing ?
>

Neither, actually. For now, this is by design. The AIFlightplan constructor 
that the traffic manager calls tries first to open a pre-exsisting 
flightplan. If that doesn't work, however, it reverts to a fallback procedure 
that creates a flightplan dynamically. 

I would like to keep that functionality, although I'm not sure if using the 
exception mechanism is the best way to do this. I'm interested in your folks' 
opinions.

Cheers,
Durk


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Fw: Scenery Designer

[Frederic Bouvier]

Peter Larson wrote:

> Boris,
> thanks. It appears to be the Crease command. I created a box, removed the
> crease and it imported OK (now I have to work through how to save the
> scenery so that it gets picked up by the Sim!). As I said, I'm new to this
> (as in just the last 4 days) and have no experience with plib.
> Is there a list anywhere of the AC3d commands that plib doesn't support?

This is the only one that is new to AC3d v4.

If you have more specific question concerning fgsd, ask them on the
fgsd mailing list. Are you able to send me privately a small model
with the crease command so that I am able to see what is going on
in fgsd ?

Thanks,
-Fred



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Is 'Scenery Loading...' mandatory ?

[Frederic Bouvier]

> Another point: FPS counter is off by default now. It was on 
> before. Is it intended ?

Oh, I see it is in the rendering option dialog ( I was going 
to add it ;-) so it is probably better like that.

-Fred



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

[Flightgear-devel] Flight plan missing files

[Frederic Bouvier]

There is a caught exception ( so it is harmless ) in
the XML reader because files are not in the base 
package. Those files are :

Data/AI/FlightPlans/KSFO-KSEA.xml
Data/AI/FlightPlans/KSEA-KSFO.xml

Are the names generated randomly or are they really missing ?

-Fred



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

[Flightgear-devel] Is 'Scenery Loading...' mandatory ?

[Frederic Bouvier]

Is there a way to avoid the initial lock for scenery loading ?
I understand this is a must have for users, but it slows 
down development speed dramatically when you have to test the 
apparence of a new building or landmark.

Another point: FPS counter is off by default now. It was on 
before. Is it intended ?

-Fred



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Took advantage of Erik's...

[Erik Hofman]

Ampere K. Hardraade wrote:
I'm sorry, but I still don't get it.
Take a look at FlightGear/data/Aircraft/f16/Models/f16.xml:


 f16.ac
 
  0.15
  0.3
 

 
  RudderPedals
  Aircraft/f16/Models/rudder_pedals.xml
  
   -5.05
   0.0
   0.14
  
 
 
  Throttle
  Aircraft/f16/Models/throttle.xml
  
   -4.25
   -0.435
   0.185
  
 

 
  ICP
  Aircraft/f16/Models/icp.ac
  
   -4.635
   0.0
...
You can see it is possible to include another animation file in the main 
animation file just by pointing to the second order animation file 
(rudder pedals and throttle in this case) instead of pointing to the 
geometry file directly.

I believe this is what you want, isn't it?
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Error message from the latest CVS

[Erik Hofman]

Ampere K. Hardraade wrote:
Dialog scenery_loading not defined
The message only appears when one is in KSFO.  As for other airports, the 
message doesn't appear; neither does the scenery.  All there is is an ocean.
Is you base package in sync with FlightGear?
Both FlightGear and the base package where modified for this feature.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel