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 from
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
http://mail.flightgear.org/mailman/listinfo/fligh
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
> -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 c
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 si
> 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 Window
* 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 --air
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 (downloadin
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 speedup
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
ju
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Curtis L.
> Olson
> i.e. you fire up Word to edit your 100Mb power point presentation.
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 Ol
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
i
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
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
p
> 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. :-) Jon :-) My main goal for attending this show
> was to show the flexibility and adaptability of FlightGear as an
> engineering and rapid prototy
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 par
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
http://mail.flightgear.org/mailman/lis
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. Untest
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 wou
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
2f585e
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 s
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 “fli
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 trie
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
#include
const int bufsz = 2048;
char buf[b
> 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
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 t
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 a
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, L
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
>#include
>co
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
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
>> 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 Voo
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:
http://cygwin.co
> Well, I submitted it. Alas, it didn't go well. You can follow the
> flame war here:
>
> http://cygwin.com/ml/cygwin/2005-05/threads.html#01305
I just read that... that guy certainly has a problem!!!
___
Flightgear-devel mailing list
Flightgear-d
47 matches
Mail list logo
