Norman Vine wrote:
You mean gcc isn't supported on IRIX ??
Once I had GCC on IRIX and I spent numerous hours trying to build
FlightGear, dealing with dozends of ICE's. Now I use MIPSpro and I
admit that I don't want to go back,
Martin.
--
Unix _IS_ user friendly - it's just selective about
Chris Metzler ha scritto:
At one point, I used fgsd to do what I thought was some nice work in the
Washington, D.C. area as preparatory to laying out ground structures I
had done or was going to do. The course of the Potomac River is about
500m from its correct location in the FG scenery as is,
Andy Ross wrote:
A final note: who else knows that there are *two* parsers for the RGB
image file format linked into the FlightGear binary? One is this one
from plib; the other is in SimGear, and is used (as far as I can see)
only for the splash screen texture. They appear to be descended
I got it working now, I made a mistake in patching the module joydev.o
Now I have to adjust the xml files to get the 14 axes working.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Andy Ross wrote
Vivian Meazza wrote:
Only a minute eh? Under Cygwin cvs takes nearly 5 minutes - time for
a brew a coffee - and that's on a pretty powerful machine.
Time from execution to fade in of the cockpit display is about 10
seconds on my laptop (1.8GHz Athlon64). I started trying
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Andy Ross
Sent: 26 May 2005 17:33
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Re: FlightGear startup time
Richard Bytheway wrote:
Would it be possible to have a compiled
Robicd wrote:
Anyway, I think the best way is to develop a new set of world elements
description. The roads, the terrain boundaries, the terrain textures
need a very deep restyling in order to attract users around the world. I
am shure that just like Airplane's 3d models, the terrain
Airports and Navigation Data Total
Before2 min 40 sec3 min 50 sec
After 1 min 40 sec2 min 50 sec
It's still the most significant part of the load process - can we be even
more clever yet?
How about an
Regarding my problem with the scenery tar file --- I think it is a
cygwin bug with gzip.
I transferred the file to a dual boot machine with Linux Red Hat and was
able to quickly and easily decompress the files once I renamed the file
extensions to .tar.tgz (downloading the .tgz files to my
* Dave Culp -- Friday 27 May 2005 14:45:
How about an un-clever solution? Can we just divide the existing data up
into
regions,
You can do that already.
and let the user select which regions he wants before start up?
You can do that already.
$ FG_ROOT=/foo/bar/Germany fgfs
Corrubia, Stacie K wrote:
Regarding my problem with the scenery tar file --- I think it is a
cygwin bug with gzip.
I transferred the file to a dual boot machine with Linux Red Hat and was
able to quickly and easily decompress the files once I renamed the file
extensions to .tar.tgz
Norman Vine wrote:
On Thursday 26 May 2005 22:48, Andy Ross wrote:
Attached is a patch that pre-reads the directory contents ahead of
time (currently that is a list of length zero) to avoid having to hit
the kernel (twice!) for every airport.
Under Linux, this doesn't provide much
Melchior Franz wrote:
I'm sure he meant boeing.com (hey, Stacie was first!). Now with
Boeing and
Sikorsky on board, where is EADS/Airbus? Come on! We know you are here!
And
Fokker!? And *cough* Diamond *cough* ... ;-)
If this community keeps up the excellent work, I'm sure everyone will
jump
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Curtis L.
Olson
snip
i.e. you fire up Word to edit your 100Mb power point presentation.
snip
Yep, that sounds like a Windows user...
Richard
Melchior FRANZ wrote:
I'm sure he meant boeing.com (hey, Stacie was first!). Now with Boeing and
Sikorsky on board, where is EADS/Airbus? Come on! We know you are here! And
Fokker!? And *cough* Diamond *cough* ... ;-)
I get the sense (from little bits and pieces I've gleaned over time)
Alberico, James F wrote:
If this community keeps up the excellent work, I'm sure everyone will
jump aboard sooner or later!!
Gee Brain, what do you want to do tonight? The same thing we do every
night Pinky ...
http://www-public.rz.uni-duesseldorf.de/~fischeni/
:-)
Curt.
--
Curtis
Arnt Karlsen wrote:
On Tue, 24 May 2005 14:26:17 +0200, Melchior wrote in message
[EMAIL PROTECTED]:
* Norman Vine -- Tuesday 24 May 2005 14:05:
I guess I should mention the deficiencies of non MSoft OSs but
I will leave the *flames* for another time :-)
Yeah, don't bother.
Harald JOHNSEN wrote:
Another problem not related to pure performance is that the first
retrieval of metar data can block FG for a long time (perhaps one
minute) when the metar server is not accessible (or when there is any
network problem). The code does a lot of (useless) retries. Perhaps
bass pumped wrote:
Been reading that. What I need to do is to create a separate area in
the property tree to map user inputs and send the relevant ones (and
the current state vector of the aircraft) out for processing to a
different computer. The other computer would then return two modified
I just got back from a Mathworks matlab/simulink symposium in LA this
week. (Thank you John, Alex, and Trisha for all your efforts! And I
have to thank Mathworks who went all out to help us get John's 747 sim
down to the show and make it a success.)
And don't forget those great lunches and
Mike,
Have a look at docs-mini/README.IO for the specific command line syntax,
but yes, for task #1 you can setup FG to expect control inputs to come
in via an FGNetCtrls packet (which you can send from your remote java
application.) You can specify the rate at which FG checks for incoming
directly. We aren't trying to eventually replace JSBsim with a
proprietary flight dynamics model here so please, I don't want anyone to
worry. :-) coughJon/cough :-) My main goal for attending this show
was to show the flexibility and adaptability of FlightGear as an
engineering and rapid
Vivian Meazza wrote:
The results of this patch are very encouraging:
Airports and Navigation Data Total
Before2 min 40 sec3 min 50 sec
After 1 min 40 sec2 min 50 sec
It's still the most significant part of
I wrote:
Attached is a little perl script that
does that. Untested. Use it as someting like:
Oops.
Andy
fgapt.pl
Description: Perl program
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Andy Ross wrote:
The apt.dat.gz file is big, certainly. It has 165976 lines, only
91813 of which are actually used by the parser*.
* So in principle you can get another 2x speedup by pruning the file
from the raw X-Plane version. Attached is a little perl script that
does that.
Erik Hofman schrieb:
[SNIP]
I had that on the back of my mind for some time now and decided to
implement it today. Lines that are not needed for FlightGear are not
tokenized anymore which should provide at least some speedup again.
I've also changed the if tests from strings comparison to int
Ralf Gerlich wrote:
Unfortunately that seems to break skipping the blank lines which are in
the standard apt.dat-files. I get an Unknown line in file:-message
when the reader encounters the first blank line after the version line.
Odd, I don't see that, are you using Windows or MacOS?
Erik
Thanks Curt and Phil. After looking around in the view manager and trying
many different combinations of XML settings, I finally took the easy way out
and changed the airborne clip plane distance in renderer.cxx to 0.5, rather
than 10. That solves my problem, but don't know if anyone else
Ralf Gerlich wrote:
Unfortunately that seems to break skipping the blank lines which are in
the standard apt.dat-files. I get an Unknown line in file:-message
when the reader encounters the first blank line after the version line.
Obviously in.getline() includes the carriage return (checked
Erik Hofman schrieb:
Ralf Gerlich wrote:
Unfortunately that seems to break skipping the blank lines which are
in the standard apt.dat-files. I get an Unknown line in
file:-message when the reader encounters the first blank line after
the version line.
Odd, I don't see that, are you using
Erik Hofman schrieb:
These issues should be fixed now.
That was the second alternative I wanted to propose ;-)
Ralf
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Hello Curt, thanks for your resume !
Curtis L. Olson wrote:
I just got back from a Mathworks matlab/simulink symposium in LA this
week. (Thank you John, Alex, and Trisha for all your efforts! And I
have to thank Mathworks who went all out to help us get John's 747 sim
down to the show
I want to implement an acrobatic AI autopilot and was
debating a few different ways of tackling the problem. I was thinking of
either creating a spline based system or tuning the current autopilot to fit my
needs. In a spline based system, the user can sit in the cockpit as the
plane flies
On Thursday 26 May 2005 23:21, Frederic Bouvier wrote:
I found that there are more dynamic libraries under Linux than under
Windows, and that they are distribution dependant.
If you can compile something statically, I am ready to put it on
sourceforge for download.
-Fred
Ok, i tried first
Well, there's some progress. I have a cygwin build, and it's every
bit at slow as Vivian says it is. And I've kinda/sorta isolated the
problem. Here's a program:
// g++ -o aptdat aptdat.cc -I$FG/SimGear -L$FG/lib -lsgmisc -lz
#include simgear/misc/sgstream.hxx
#include
From: Dave Culp
Thanks Curt and Phil. After looking around in the view manager and trying
many different combinations of XML settings, I finally took the easy way out
and changed the airborne clip plane distance in renderer.cxx to 0.5, rather
than 10. That solves my problem, but don't
Martin Spott wrote:
Hello Curt, thanks for your resume !
Oops, did I misclick with this stupid laptop touch pad and attach my
resume by mistake?
That sounds interesting, but it's not completely clear to me what they
acutally did to achieve this ;-)
Did they create an interface within
Vance Souders wrote:
I want to implement an acrobatic AI autopilot and was debating a few
different ways of tackling the problem. I was thinking of either
creating a spline based system or tuning the current autopilot to fit
my needs. In a spline based system, the user can sit in the cockpit
Hello Everyone.
Has anyone attempted to modify the listings in nav.dat file and run
flightgear 0.9.8?
I am trying to edit the nav.dat file. My idea is to create waypoints for
the autopilot to follow by using the NAV 1 CD1 Course and NAV 1 Glide
Slope. Right now, there are a bunch of airports, GS,
Andy Ross wrote:
Well, there's some progress. I have a cygwin build, and it's every
bit at slow as Vivian says it is. And I've kinda/sorta isolated the
problem. Here's a program:
// g++ -o aptdat aptdat.cc -I$FG/SimGear -L$FG/lib -lsgmisc -lz
#include simgear/misc/sgstream.hxx
I wrote:
The bottom line is that this is a cygwin bug and we can't fix it,
sorry. Hopefully someone with more love for this platform than I
(I've done my time, heh) can forward this to them and get it fixed.
No, that's dumb. I may not like windows, but cygwin is one of the few
things that
On Friday 27 May 2005 21:01, Oliver C. wrote:
First, installing CGAL systemwide is a nightmare, so i decided against it
to do that.
Probably wisely. At least, I did the same...
After that i went back to compile fgsd.
But now i get the following compiler error:
The used gcc version is
Curtis L. Olson wrote:
Martin Spott wrote:
Hello Curt, thanks for your resume !
Oops, did I misclick with this stupid laptop touch pad and attach my
resume by mistake?
:-))
No, you didn't, I was just echoing the funny habit of a British
colleague in the way he translates the French word
On Saturday 28 May 2005 00:18, AJ MacLeod (email lists) wrote:
If you'd read the README you'd have seen a note to that effect; apparently
3.2 and 3.4 are OK, but 3.3 produce this error.
No, I didn't read the README either, until after I'd found this out the
hard way!
Thank you for the info.
I finally took the
easy way out and changed the airborne clip plane distance in renderer.cxx
to 0.5, rather than 10. That solves my problem, but don't know if
anyone else would like that move
The issue would only be related to the width of the Z buffer. I was
running a Voodoo card
I just did a quick test and it looks like the parking and rwyuse files are not
yet picked up by the patch. I'm likely to have a chance to look into this
tomorrow. I'm out of town for the rest of the day.
Cheers,
Durk
On Thursday 26 May 2005 22:48, Andy Ross wrote:
Unfortunately, because there
I wrote:
No, that's dumb. I may not like windows, but cygwin is one of the few
things that makes it bearable. :)
[...]
I'll try to dig up a cygwin mailing list to which to submit this.
Well, I submitted it. Alas, it didn't go well. You can follow the
flame war here:
47 matches
Mail list logo
