[Flightgear-devel] SimGear compile dying in MSVC6
Hi Any assistance would be gratefully accepted. Debug info: Compiling... iochannel.cxx lowlevel.cxx c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(80) : error C2059: syntax error : 'bad suffix on number' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(80) : error C2146: syntax error : missing ')' before identifier 'L' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(80) : error C2059: syntax error : ')' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(80) : error C2059: syntax error : 'bad suffix on number' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(81) : error C2059: syntax error : 'bad suffix on number' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(81) : error C2146: syntax error : missing ')' before identifier 'L' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(81) : error C2059: syntax error : ')' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(81) : error C2059: syntax error : 'bad suffix on number' sg_binobj.cxx c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(80) : error C2059: syntax error : 'bad suffix on number' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(80) : error C2146: syntax error : missing ')' before identifier 'L' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(80) : error C2059: syntax error : ')' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(80) : error C2059: syntax error : 'bad suffix on number' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(81) : error C2059: syntax error : 'bad suffix on number' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(81) : error C2146: syntax error : missing ')' before identifier 'L' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(81) : error C2059: syntax error : ')' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(81) : error C2059: syntax error : 'bad suffix on number' sg_file.cxx c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(80) : error C2059: syntax error : 'bad suffix on number' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(80) : error C2146: syntax error : missing ')' before identifier 'L' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(80) : error C2059: syntax error : ')' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(80) : error C2059: syntax error : 'bad suffix on number' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(81) : error C2059: syntax error : 'bad suffix on number' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(81) : error C2146: syntax error : missing ')' before identifier 'L' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(81) : error C2059: syntax error : ')' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(81) : error C2059: syntax error : 'bad suffix on number' sg_serial.cxx sg_socket.cxx sg_socket_udp.cxx Generating Code... Error executing cl.exe. SimGear.lib - 24 error(s), 1 warning(s) Cheers - -- Sam Ingarfield Student, Western Australia ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear compile dying in MSVC6
Ok... I myself have been having problems with compiling FG with MSVC 7.1, but I've been told this much. Its way to hard to compile with MSVC6. But ofcourse, I submit to the judgement of the masters. They know way better. On 11/14/05, Sam Ingarfield - VK6HSI [EMAIL PROTECTED] wrote: Hi Any assistance would be gratefully accepted. Debug info: Compiling... iochannel.cxx lowlevel.cxx c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(80) : error C2059: syntax error : 'bad suffix on number' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(80) : error C2146: syntax error : missing ')' before identifier 'L' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(80) : error C2059: syntax error : ')' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(80) : error C2059: syntax error : 'bad suffix on number' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(81) : error C2059: syntax error : 'bad suffix on number' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(81) : error C2146: syntax error : missing ')' before identifier 'L' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(81) : error C2059: syntax error : ')' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(81) : error C2059: syntax error : 'bad suffix on number' sg_binobj.cxx c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(80) : error C2059: syntax error : 'bad suffix on number' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(80) : error C2146: syntax error : missing ')' before identifier 'L' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(80) : error C2059: syntax error : ')' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(80) : error C2059: syntax error : 'bad suffix on number' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(81) : error C2059: syntax error : 'bad suffix on number' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(81) : error C2146: syntax error : missing ')' before identifier 'L' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(81) : error C2059: syntax error : ')' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(81) : error C2059: syntax error : 'bad suffix on number' sg_file.cxx c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(80) : error C2059: syntax error : 'bad suffix on number' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(80) : error C2146: syntax error : missing ')' before identifier 'L' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(80) : error C2059: syntax error : ')' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(80) : error C2059: syntax error : 'bad suffix on number' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(81) : error C2059: syntax error : 'bad suffix on number' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(81) : error C2146: syntax error : missing ')' before identifier 'L' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(81) : error C2059: syntax error : ')' c:\documents and settings\sam ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(81) : error C2059: syntax error : 'bad suffix on number' sg_serial.cxx sg_socket.cxx sg_socket_udp.cxx Generating Code... Error executing cl.exe. SimGear.lib - 24 error(s), 1 warning(s) Cheers - -- Sam Ingarfield Student, Western Australia ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Ear Candy: intro.mp3
Kevin Jones wrote: Regarding the file /data/Sounds/intro.mp3: FlightGear doesn't use OpenAL for MP3 playback. In fact, it isn't even supported. Does that mean that the command line options --disable-intro-music and --enable-intro-music have no effect on any platform or should there be a different intro-music that I'm still not hearing on Win32? FlightGear is using start /m file on Windows, so if you've registered an MP3 player it should play the intro music. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Ear Candy: intro.mp3
Regarding the file /data/Sounds/intro.mp3: FlightGear doesn't use OpenAL for MP3 playback. In fact, it isn't even supported. Does that mean that the command line options --disable-intro-music and --enable-intro-music have no effect on any platform or should there be a different intro-music that I'm still not hearing on Win32? Kevin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting Started Guide - Terrain/Objects
Buchanan, Stuart wrote: OK, I'll suggest /var/share/FlightGear/WorldScenery/[Terrain|Objects] for *nix, and FG_ROOT\Scenery\[Terrain|Objects] for Windows. I'm sure you meant /usr/share/FlightGear/... and not /var. Just to clarify, Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting Started Guide - Terrain/Objects
Stefan Seifert wrote: I'm sure you meant /usr/share/FlightGear/... and not /var. Makes more sense to me. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting Started Guide - Terrain/Objects
Stefan Seifert wrote: Buchanan, Stuart wrote: OK, I'll suggest /var/share/FlightGear/WorldScenery/[Terrain|Objects] for *nix, and FG_ROOT\Scenery\[Terrain|Objects] for Windows. I'm sure you meant /usr/share/FlightGear/... and not /var. Hehe, I've started a similar discussion twice in the past when I was seeking for an appropriate phrase to put into the manual. The consensus was that we didn't manage to find a consensus :-) Herewith I suggest $FG_ROOT\Scenery\[Terrain|Objects]\ for Windows and $FG_ROOT/Scenery/[Terrain|Objects]/ for Unix, so everyone is free to place their Scenery by choosing an appropriate place for $FG_ROOT. Regards, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: freeglut on SuSE 10
On Sunday 13 November 2005 20:15, Steve Knoblock wrote: I installed the downgrade of freeglut, but I still get a missing header error. I think this header is in the freeglut-devel but did not download that module. I cannot seem to access the 9.3 RPMs in the Yast repositories. Can someone point me in the right direction where to get these files? If you are building software with a compile-time dependency on a package, you will need the -devel RPM too. I'm astonished you haven't yet come across RPMFind.net... http://www.rpmfind.net/linux/rpm2html/search.php?query=freeglut-develsubmit=Search+...system=susearch= This is getting tiresome. Of course we'd all rather this problem hadn't been introduced in freeglut; but at the same time, it shouldn't be difficult to work around. In your case, manually install the two freeglut-2.2 RPMs, or just compile FG with --enable-sdl (assuming you have libsdl and associated headers installed). Let us know how you get on, or better, if you're still stuck, ask for real-time help on the IRC channel. There has been a steady stream of such, I dare say another one wouldn't hurt... Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] XCode project files
Please do commit them, I've had hand-rolled projects for all three for some time, but they're out of sync. If I find any issues, I'll let you know. Is it worth creating a developer directory under FlightGear CVS to contain things like these xcode project files and developer instructions for cygwin here http://www.opensubscriber.com/message/ flightgear-users@flightgear.org/2485584.html mentioned on the flightgear-user list or Norm's cygwin openal work (or at least a link to the current versions)? Maybe developer could have os-specific directories like macosx, cygwin, etc or just put everything in developer directory. These aren't utils and probably don't belong in the utils directory... but this would keep them in a standard place accessible to everyone from the source tree. It seems like we see similar problems that people are maintaining by themselves (projects (build files) for xcode and for MS visual C/C++ come to mind) thanks! Ima ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting Started Guide - Terrain/Objects
On Mon, 14 Nov 2005, Stefan Seifert wrote: Buchanan, Stuart wrote: OK, I'll suggest /var/share/FlightGear/WorldScenery/[Terrain|Objects] for *nix, and FG_ROOT\Scenery\[Terrain|Objects] for Windows. I'm sure you meant /usr/share/FlightGear/... and not /var. I thought /var because of the indeterministic size --- some folks will terrasync only a small local area, some will more... ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
* Vassilii Khachaturov -- Monday 14 November 2005 12:50: http://members.aon.at/mfranz/flightgear/flightgear-howto.html I'd only suggest to have the world scenery under smth like /var/share/FlightGear/WorldScenery (maybe share/games) rather than in the FG_ROOT, to make it more up-to-date with the current FHS. Let me clear this up: the fgfs data package is in a defined place: $FG_ROOT. Therefore it's only logical to make other fgfs ressources like world scenery available under $FG_ROOT(/WorldScenery/?). That way different utilities can easily access them. Of course it's up to the admin if $FG_ROOT/WorldScenery/ is a real dir or just a link to /var/share/FlightGear or elsewhere. If the admin maintains the data and (not so) regularly uploads a whole set, then this will be a regular dir. If he appoints a FlightGear admin, then this will probably be a regular dir owned by that admin. And if he grants users the right to use terrasync, it will be a link to /var/share/FlightGear/WorldScenery/, or elsewhere. (Of course, regular users won't be allowed to write to /usr/local.) All IMHO, of course :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting Started Guide - Terrain/Objects
Vassilii Khachaturov wrote: On Mon, 14 Nov 2005, Stefan Seifert wrote: Buchanan, Stuart wrote: OK, I'll suggest /var/share/FlightGear/WorldScenery/[Terrain|Objects] for *nix, and FG_ROOT\Scenery\[Terrain|Objects] for Windows. I'm sure you meant /usr/share/FlightGear/... and not /var. I thought /var because of the indeterministic size --- some folks will terrasync only a small local area, some will more... terrasync is another story, which is no problem through giving FlightGear two scenery paths. Additionally no one should run terrasync as root anyway, so it can't write to /var/share/FlightGear. terrasync users should have their own scenery directory in their homes or anywhere their user is able to write. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] XCode project files
On 11/14/05, Ima Sudonim [EMAIL PROTECTED] wrote: Please do commit them, I've had hand-rolled projects for all three for some time, but they're out of sync. If I find any issues, I'll let you know. Is it worth creating a developer directory under FlightGear CVS to contain things like these xcode project files and developer instructions for cygwin here http://www.opensubscriber.com/message/ flightgear-users@flightgear.org/2485584.html mentioned on the flightgear-user list or Norm's cygwin openal work (or at least a link to the current versions)? Maybe developer could have os-specific directories like macosx, cygwin, etc or just put everything in developer directory. These aren't utils and probably don't belong in the utils directory... but this would keep them in a standard place accessible to everyone from the source tree. It seems like we see similar problems that people are maintaining by themselves (projects (build files) for xcode and for MS visual C/C++ come to mind) thanks! Ima This would require someone to maintain the project files. I plan on leaving the FlightGear project soon after the 0.9.9 release so wouldn't be able to. It just drains too much time. It was a good experience though with making the mac version more user friendly. I'll still commit the Xcode projects to macflightgear CVS later today and then we'll see what happens. https://sourceforge.net/cvs/?group_id=126825 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear compile dying in MSVC6
bass pumped wrote: Ok... I myself have been having problems with compiling FG with MSVC 7.1, but I've been told this much. Its way to hard to compile with MSVC6. But ofcourse, I submit to the judgement of the masters. They know way better. Yes, the general consensus I've heard in the past is that MSVC6 is simply too old and buggy to compile a project like flightgear which is designed for more modern compilers (and by modern I mean compilers that adhere somewhat well to the established C++ standards.) So it seems like your best choices for windows are MSVC7 or cygwin/mingwin if you want to go the open-source (free) route. Curt. -- 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] XCode project files
This would require someone to maintain the project files. I plan on leaving the FlightGear project soon after the 0.9.9 release so wouldn't be able to. Arthur, If the project files were in cvs, then you personally wouldn't have to maintain them. Whoever needed to use them would see about updating them so that others could use their work (in a perfect world). 8-) I think it would avoid duplication of work -- i.e., multiple people each doing their own xcode file and make the work done like yours easier to find. At a minimum, maybe there could be a document pointing to the cygwin doc and your macflightgear project on sourceforge? Personally, I think in the source tree is much easier to find... Sorry to hear you're leaving after 0.9.9. Thanks for all the work you've put into flightgear! Take care! Ima ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
* Curtis L. Olson -- Monday 14 November 2005 15:12: Let's stick with .../.../Scenery/[Terrain|Objects] on all platforms please. Individuals are welcome to call it whatever they want on their system and use the --fg-scenery= option to point to their favoritely named directory. Maybe I missed something, but as far as I've understood this thread is not about renaming $FG_ROOT/Scenery/. It's only about whether to suggest a standard in the user documentation for where to install additional scenery, especially when using terrasync. Dumping terrasync fetched data into $FG_ROOT/Scenery/ is a Really Bad Idea[TM]. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: openAL compilation problem
Hi WIN32 developers, I too have had BIG PROBLEMS with compiling OpenAL CVS with MSVC7.1 - maybe this will eventually be cleared up by the OpenAL developer group ... maybe NOT ;=(( Part of the problem, is that for no particular good reason that I see, in WIN32 they, the OpenAL group, decided to implement these as DLLs, rather than Static libraries, as they are in other environments ... Meantime, to get FlightGear LINKED, I downloaded, and installed the OpenAL (WIN32) SDK 1.1 binaries, and used those for the SimGear/FlightGear COMPILE and LINK ... This presented a small problem, in that, in this SDK, which will install in C:\Program Files\OpenAL 1.1 SDK\ by default, the 3 headers needed, al.h, alc.h, alut.h have been placed in an 'include' directory, whereas SimGear expects them to be in an 'AL' directory ... it uses #include AL/al.h and AL/alut.h ... Ok, so I created an AL directory, in the SDK folder, and copied them into there ... simple ... That nearly works ... unfortunately alut.h also includes al.h by just using #include al.h You could probably modify this to al.h, then MSVC would do a 'local' search ... al.h only searches 'include' directories ... This meant I had to provide BOTH 'additional include' folders, namely 'C:\Program Files\OpenAL 1.1 SDK' and 'C:\Program Files\OpenAL 1.1 SDK\AL' to the SimGear compile ... but, Bob's your uncle ... I got a CLEAN LINK of SG and FG ... A little more can be read about this on my page - http://geoffmclane.com/fg/fgfs-018.htm Down at the bottom, under 'Some other details:' I have given the additional dependencies, and directories of FG AND SG that I used ... Regards, Geoff. _ View 1000s of pictures, profiles and more now at Lavalife http://lavalife.com.au ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
Melchior FRANZ wrote:
* Curtis L. Olson -- Monday 14 November 2005 15:12:
Let's stick with .../.../Scenery/[Terrain|Objects] on all platforms
please. Individuals are welcome to call it whatever they want on their
system and use the --fg-scenery= option to point to their favoritely
named directory.
Maybe I missed something, but as far as I've understood this thread
is not about renaming $FG_ROOT/Scenery/. It's only about whether to
suggest a standard in the user documentation for where to install
additional scenery, especially when using terrasync. Dumping terrasync
fetched data into $FG_ROOT/Scenery/ is a Really Bad Idea[TM].
Not to get overly pedantic, but someone suggested
.../.../WorldScenery/{Terrain|Objects} for *nix platforms, and the
person doing the documentation work said ok, so my response was a plea
to keep things consistent across platforms and just use
$FG_ROOT/data/Scenery as the root of the scenery tree.
Regards,
Curt.
--
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
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Compiling with cygwin
A little OT, I would ALSO like to help in WIN32 with cygwin builds, and have begun to try cygwin, but hit problems with my first try, with PLIB ... After ./autogen.sh and ./configure (boy, that seems a SLOW process), when I then run the make, it exits with - $ make Makefile:328: *** missing separator (did you mean TAB instead of 8 spaces?). Stop. Geoff [EMAIL PROTECTED] ~/FG099/PLIB I don't know! Did I ;=)) Of course, I can MANUALLY fix the Makefile line(s), but I should NOT have to do that!!! Maybe some cygwin WIN32 developer could open up a direct email with me, and give me some quick pointers ;=)) Regards, Geoff. _ Search the Web for cheap flights http://search.ninemsn.com.au/results.aspx?rf=1q=cheap+flightsFORM=HM ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: SimGear compile dying in MSVC6
Hi Sam, Although I have personally abandoned MSVC6 in favour of MSVC7.1, ALL should be possible with MSVC6 - again, my pages - http://geoffmclane.com/fg has lots of information on compiling with MSVC6 ... trials and tribulations ... Maybe I too will try it again, but AFTER I experiment with cygwin, my next trial ... ;=)) but I know of another recent person that has compiled, and run FG using MSVC6 ... he too had problems with openAL, but got through PLIB, SG and FG ;=)) Best of luck ... Geoff. _ View 1000s of pictures, profiles and more now at Lavalife http://lavalife.com.au ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting Started Guide - Terrain/Objects
On Monday 14 November 2005 15:01, Stefan Seifert wrote: Vassilii Khachaturov wrote: On Mon, 14 Nov 2005, Stefan Seifert wrote: Buchanan, Stuart wrote: OK, I'll suggest /var/share/FlightGear/WorldScenery/[Terrain|Objects] for *nix, and FG_ROOT\Scenery\[Terrain|Objects] for Windows. I'm sure you meant /usr/share/FlightGear/... and not /var. I thought /var because of the indeterministic size --- some folks will terrasync only a small local area, some will more... terrasync is another story, which is no problem through giving FlightGear two scenery paths. Additionally no one should run terrasync as root anyway, so it can't write to /var/share/FlightGear. terrasync users should have their own scenery directory in their homes or anywhere their user is able to write. Nine I agree. User data (like from terrasync) belong to ~./local/share/FlightGear or ~./flightgear/ When using the latter one, we could also start to put the .fgfsrc config file into ~./flightgear/ The preferenced.xml file should also belong there, because it is user specific and the user should allways be able to edit it. A system wide global installation should put the scenery into /usr/share/FlightGear/scenery or /usr/local/share/FlightGear/scenery (for a distribution independent installation) That's what FHS proposes/dictate. If we want to keep consistency like Curt proposes, then we should put everything into /usr/local/games/FlightGear/ The reason is, in /usr/local/games we can have our own directory for everything (data, scripts, binarys etc.,). In /usr/local/games/ there is no need to spread everything around over the system. BTW, an alternative to /usr/local/games would be /opt/ Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
--- Curtis L. Olson [EMAIL PROTECTED] wrote:
Melchior FRANZ wrote:
Maybe I missed something, but as far as I've understood this thread
is not about renaming $FG_ROOT/Scenery/.
Well ... it could be :)
My aim is to write a section in the Gettings Started Guide so that a new
user can set up their directories and FG_SCENERY variable to the correct
values. This doesn't have to be the same setup as everyone uses (after
all, that's why we have FG_SCENERY)
It's only about whether to
suggest a standard in the user documentation for where to install
additional scenery, especially when using terrasync. Dumping terrasync
fetched data into $FG_ROOT/Scenery/ is a Really Bad Idea[TM].
I'm groping in the dark here as I'm not familiar with terrasync. Am I
correct in thinking that someone using terrasync should have their
terrasync data in a different directory from their directly-downloaded
10x10 scenery?
If so, is the convention to name the directories as follows:
$FG_ROOT/data/Scenery - standard SF bay scenery included in base package
$FG_ROOT/Scenery - scenery downloaded in 10x10 chunks
$FG_ROOT/WorldScenery - scenery downloaded by terrasync
or is WorldScenery just a different convention for $FG_ROOT/Scenery?
Not to get overly pedantic, but someone suggested
.../.../WorldScenery/{Terrain|Objects} for *nix platforms, and the
person doing the documentation work said ok, so my response was a plea
to keep things consistent across platforms and just use
$FG_ROOT/data/Scenery as the root of the scenery tree.
Now I'm getting even more confused. I thought $FG_ROOT/data/Scenery was
just to contain the base package scenery for the SF Bay area.
Maybe this is a can of worms I don't have enough understanding to want to
open ...
-Stuart
___
Yahoo! Model Search 2005 - Find the next catwalk superstars -
http://uk.news.yahoo.com/hot/model-search/
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] XCode project files
Please do commit them, I've had hand-rolled projects for all three for some time, but they're out of sync. If I find any issues, I'll let you know. James OK, they are available now. I quickly wrote ReadMe's for them. https://sourceforge.net/cvs/?group_id=126825 To checkout: cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/macflightgear co -P flightgear cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/macflightgear co -P SimGear cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/macflightgear co -P PLIB I will also commit the new macstart source soon. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
On Monday 14 November 2005 16:06, Buchanan, Stuart wrote: I'm groping in the dark here as I'm not familiar with terrasync. Am I correct in thinking that someone using terrasync should have their terrasync data in a different directory from their directly-downloaded 10x10 scenery? If so, is the convention to name the directories as follows: $FG_ROOT/data/Scenery - standard SF bay scenery included in base package $FG_ROOT/Scenery - scenery downloaded in 10x10 chunks $FG_ROOT/WorldScenery - scenery downloaded by terrasync or is WorldScenery just a different convention for $FG_ROOT/Scenery? I suggest to remove the SF bay scenery in the corresponding 10x10 scenery file. This allows us to place the SF bay, which comes allready with the base package, in the main scenery folder like all the other 10x10 chunks. And when someone installs the corresponding scenery tile w130n30.tar.gz it won't overwrite the SF bay. What's your opinion about that? Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
* Buchanan, Stuart -- Monday 14 November 2005 16:06: Am I correct in thinking that someone using terrasync should have their terrasync data in a different directory from their directly-downloaded 10x10 scenery? No. On the contrary. If so, is the convention to name the directories as follows: $FG_ROOT/data/Scenery - standard SF bay scenery included in base package This dir doesn't exist. There's no such thing as $FG_ROOT/data/. $FG_ROOT/Scenery - scenery downloaded in 10x10 chunks That's the official scenery directory, containing the bay area, that is: a subset of w130n30. But installing additional scenery there is ugly, if possible at all. Not only do normal users not necessarily have write permission there, it's also always a bad idea to mix official data (from CVS or fgfs packages) with extra data. You'd constantly get cvs merge conflicts and cvs updating would be slower. Upgrading would become more difficult than it had to. $FG_ROOT/WorldScenery - scenery downloaded by terrasync or is WorldScenery just a different convention for $FG_ROOT/Scenery? No. It's no convention at all. Just a possible place to put additional scenery. You would then set your FG_SCENERY like this: export FG_SCENERY=$FG_ROOT/Scenery:$FG_ROOT/WorldScenery This would always take the base package terrain where it's available, and locally added scenery (terrasync or other downloaded archives) else. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
Melchior FRANZ wrote: This dir doesn't exist. There's no such thing as $FG_ROOT/data/. Of course there is. :-) $FG_ROOT/source/ $FG_ROOT/data/ $FG_ROOT/data/Aircraft/ $FG_ROOT/data/Scenery/ This is the prefered structure ... Regards, Curt. -- 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
Buchanan, Stuart wrote:
--- Curtis L. Olson [EMAIL PROTECTED] wrote:
Melchior FRANZ wrote:
If so, is the convention to name the directories as follows:
$FG_ROOT/data/Scenery - standard SF bay scenery included in base package
$FG_ROOT/Scenery - scenery downloaded in 10x10 chunks
$FG_ROOT/WorldScenery - scenery downloaded by terrasync
[...]
Not to get overly pedantic, but someone suggested
.../.../WorldScenery/{Terrain|Objects} for *nix platforms, and the
person doing the documentation work said ok, so my response was a plea
to keep things consistent across platforms and just use
$FG_ROOT/data/Scenery as the root of the scenery tree.
Now I'm getting even more confused. I thought $FG_ROOT/data/Scenery was
just to contain the base package scenery for the SF Bay area.
There's indeed some confusion in here.
$FG_ROOT actually points to the data/-Directory, this means, $FG_ROOT
contains ATC/, Aircraft/ , Models/ , Scenery/ and so on. As
far as I remember Melchior's intention was to express this. I think
Curt's statement accidentally differed from what he wanted to say - as
he is definitely involved in the creation of the $FG_ROOT-contruct :-)
Maybe this is a can of worms I don't have enough understanding to want to
open ...
This _is_ a can of worms but I certainly don't mind talking about it
from time to time. In fact people tend to use different directories
based on their experience and the operating system they use. Adding to
that, those people who know almost only one flavour/distribution of
Unix usually choose a different directory than those who have platform
interoperability in mind :-)
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
* Curtis L. Olson -- Monday 14 November 2005 16:34: Melchior FRANZ wrote: This dir doesn't exist. There's no such thing as $FG_ROOT/data/. Of course there is. :-) Sheesh. I resign. :-} $FG_ROOT/source/ $FG_ROOT/data/ $FG_ROOT/data/Aircraft/ $FG_ROOT/data/Scenery/ This is the prefered structure ... Not by me. Sourcecode doesn't really belong into /usr/local/share/, and even less into the shared FlightGear data. But you are the chief. And I keep my installation sane. :-P m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
Curtis L. Olson wrote: Melchior FRANZ wrote: This dir doesn't exist. There's no such thing as $FG_ROOT/data/. Of course there is. :-) $FG_ROOT/source/ $FG_ROOT/data/ $FG_ROOT/data/Aircraft/ $FG_ROOT/data/Scenery/ Curt, this does not necessarily work. Apparently you have been misunderstood by several people for a long time. This makes the topic really funny :-) Looking at the facts, 'fgfs' actually does find the aircraft model, when data/ resides _below_ $FG_ROOT, but it does _not_ find the Scenery, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
--- Martin Spott [EMAIL PROTECTED] wrote:
Buchanan, Stuart wrote:
--- Curtis L. Olson [EMAIL PROTECTED] wrote:
Melchior FRANZ wrote:
If so, is the convention to name the directories as follows:
$FG_ROOT/data/Scenery - standard SF bay scenery included in base
package
$FG_ROOT/Scenery - scenery downloaded in 10x10 chunks
$FG_ROOT/WorldScenery - scenery downloaded by terrasync
[...]
Not to get overly pedantic, but someone suggested
.../.../WorldScenery/{Terrain|Objects} for *nix platforms, and the
person doing the documentation work said ok, so my response was a
plea
to keep things consistent across platforms and just use
$FG_ROOT/data/Scenery as the root of the scenery tree.
Now I'm getting even more confused. I thought $FG_ROOT/data/Scenery
was
just to contain the base package scenery for the SF Bay area.
There's indeed some confusion in here.
$FG_ROOT actually points to the data/-Directory, this means, $FG_ROOT
contains ATC/, Aircraft/ , Models/ , Scenery/ and so on. As
far as I remember Melchior's intention was to express this. I think
Curt's statement accidentally differed from what he wanted to say - as
he is definitely involved in the creation of the $FG_ROOT-contruct :-)
Yup, I think I got confused between FG_HOME (deprecated?) and FG_ROOT.
Maybe this is a can of worms I don't have enough understanding to want
to
open ...
This _is_ a can of worms but I certainly don't mind talking about it
from time to time. In fact people tend to use different directories
based on their experience and the operating system they use. Adding to
that, those people who know almost only one flavour/distribution of
Unix usually choose a different directory than those who have platform
interoperability in mind :-)
OK, so I think I'd like to suggest that for the Getting Started Guide we
suggest for Windows
whatever_path_to_FG/data/Scenery
whatever_path_to_FG/Scenery
and for *nix
$FG_ROOT/Scenery
/usr/share/FlightGear/Scenery
I'm expecting that *nix users will be familiar enough with their file
system to change it as they see fit, but I'd like to be more prescriptive
for Windows users who are _generally_ not going to be as happy messing
with $FG_SCENERY on their
Apologies for the confusion that has clouded already muddy water.
-Stuart
___
To help you stay safe and secure online, we've developed the all new Yahoo!
Security Centre. http://uk.security.yahoo.com
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
Melchior FRANZ wrote: * Curtis L. Olson -- Monday 14 November 2005 16:34: Melchior FRANZ wrote: This dir doesn't exist. There's no such thing as $FG_ROOT/data/. Of course there is. :-) Sheesh. I resign. :-} $FG_ROOT/source/ $FG_ROOT/data/ $FG_ROOT/data/Aircraft/ $FG_ROOT/data/Scenery/ This is the prefered structure ... Not by me. Sourcecode doesn't really belong into /usr/local/share/, and even less into the shared FlightGear data. But you are the chief. And I keep my installation sane. :-P This is a hopeless conversation because everyone wants to do it different and there are so many possibilities. If you are a normal user on a normal unix system you aren't going to be able write to /usr/local so that's not even part of the discussion. And a user might want multiple versions of FG on their system so they could set up ~/Projects/FG-v0.9.8/source/ ~/Projects/FG-v0.9.8/data/ ~/Projects/FG-v0.9.8/bin/ ~/Projects/FG-v0.9.8/lib ~/Projects/FG-v0.9.8/include ~/Projects/FG-v0.9.8/AddOnScenery ... and ... ~/Projects/FG-v0.9.9/source/ ~/Projects/FG-v0.9.9/data/ ~/Projects/FG-v0.9.9/bin/ ~/Projects/FG-v0.9.9/lib ~/Projects/FG-v0.9.9/include ~/Projects/FG-v0.9.9/AddOnScenery ... and ... ~/Projects/FG-CVS/source/ ~/Projects/FG-CVS/data/ ~/Projects/FG-CVS/bin/ ~/Projects/FG-CVS/lib ~/Projects/FG-CVS/include ~/Projects/FG-v0.9.9/AddOnScenery Ok, so now the system administrator comes by and you want to install this at a system level so everyone can have access ... it's not common convention to install the source code. Instead but you might want to have multiple versions of FG installed so you could setup an $FG_ROOT for each version. But this discussion will go in endless circles because everyone who cares has their own opinions about how it should be done ... Fortunately people who care usually know what they are doing and why so they can set it up however they like. But this discussion I believe started out so we could define what should be in the documentation so my only point was that $FG_ROOT officially contains the data/ directory. (And for backwards compatibility, the code still supports the old way where $FG_ROOT is the data directory.) Curt. -- 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
Martin Spott wrote: Curt, this does not necessarily work. Apparently you have been misunderstood by several people for a long time. This makes the topic really funny :-) Looking at the facts, 'fgfs' actually does find the aircraft model, when data/ resides _below_ $FG_ROOT, but it does _not_ find the Scenery, Well unless I have some thing else going on locally that I'm not aware of, this works out ok for me ... (?) Curt. -- 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
Buchanan, Stuart wrote: OK, so I think I'd like to suggest that for the Getting Started Guide we suggest for Windows whatever_path_to_FG/data/Scenery whatever_path_to_FG/Scenery and for *nix $FG_ROOT/Scenery /usr/share/FlightGear/Scenery I'm expecting that *nix users will be familiar enough with their file system to change it as they see fit, but I'd like to be more prescriptive for Windows users who are _generally_ not going to be as happy messing with $FG_SCENERY on their Apologies for the confusion that has clouded already muddy water. Stuart, We can suggest different default locations of $FG_ROOT for different systems, but below $FG_ROOT we should use the same structure for all platforms. Curt. -- 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
* Curtis L. Olson -- Monday 14 November 2005 16:54: This is a hopeless conversation because everyone wants to do it different and there are so many possibilities. We are talking about different things. You talk about the organization of source and data in your home directory. I talk about correct installation of fgfs on a multiuser system, with system wide FG_ROOT. Of course, FG_ROOT is not in a user's home dir then. And, of course, it doesn't contain the source. The source is in my home directory, is not accessible by other users, and does neither follow the organization that I described in the thread, nor what you consider preferred. Also, I wouldn't want to discuss the organization of my home dir in the fgfs documentation. That's secret! :-] m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
Melchior FRANZ wrote: * Curtis L. Olson -- Monday 14 November 2005 16:54: This is a hopeless conversation because everyone wants to do it different and there are so many possibilities. We are talking about different things. You talk about the organization of source and data in your home directory. I believe I referenced both situations ... but discussed the home directory situation first as justification for the overall structure. I talk about correct installation of fgfs on a multiuser system, with system wide FG_ROOT. Of course, FG_ROOT is not in a user's home dir then. And, of course, it doesn't contain the source. The source is in my home directory, is not accessible by other users, and does neither follow the organization that I described in the thread, nor what you consider preferred. Also, I wouldn't want to discuss the organization of my home dir in the fgfs documentation. That's secret! :-] Ok, I will drop 10 and punt. Curt. -- 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
On Monday 14 November 2005 16:58, Curtis L. Olson wrote: We can suggest different default locations of $FG_ROOT for different systems, but below $FG_ROOT we should use the same structure for all platforms. Curt. Then we should definitely officially use /usr/local/games/flightgear/ or /opt/flightgear/ as $FG_ROOT on unix systems. The ones who want have it the other way can change it on their own with the --prefix= command line option, but officially it should be clear for things like a binary installer or tools that want have access to the data in flightgear without the need of asking the user all the time where the flightgear data is. To make use of /usr/local/games/flightgear/ or /opt/flightgear/ by default we should change the configure script accordingly. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: SimGear compile dying in MSVC6
Hi Sam, Curt wrote : simply too old and buggy While I might agree with the AGE, circa 1998, 7 years might be the life expectancy of a compiler ;=)) I do not think I could characterise it as 'buggy' ... quirky, kinky, and as I used below, 'blind' ... or simply lacking in SOME newer C++, albeit now 'standard', features ... Getting quite frustrated with getting any further with my new-for-me cygwin build, I decided to light up my crusty, trusty?, MSVC6 once again, and check out this small problem ... It is simple!. The suffix LL is NOT supported by MSVC6, but IS supported by MSVC7 ;=() Do a search for 'Suffix L' in your HELP (last was Oct 2001), and select 'C++ Integer Constants' to read more on this ... You will note the ONLY 64-bit integer-suffix listed is i64 ... In my MSVC7.1 help, same page, it shows i64 AND LL! Using HEAVY switch compile code, you could change the little block of code, to a whole block of code as follows - #ifdef _MSC_VER #if _MSC_VER = 1200 // msvc++ 6.0 x = ((x 8) 0x00FF00FF00FF00FFi64) | ((x 8) 0xFF00FF00FF00FF00i64); x = ((x 16) 0xi64) | ((x 16) 0xi64); #else // !#if _MSC_VER = 1200 // msvc++ 7.0 x = ((x 8) 0x00FF00FF00FF00FFLL) | ((x 8) 0xFF00FF00FF00FF00LL); x = ((x 16) 0xLL) | ((x 16) 0xLL); #endif // #if 6.0 or greater, 7.0 #else // !#ifdef _MSC_VER x = ((x 8) 0x00FF00FF00FF00FFLL) | ((x 8) 0xFF00FF00FF00FF00LL); x = ((x 16) 0xLL) | ((x 16) 0xLL); #endif // #ifdef _MSC_VER y/n Of course you could just change the two lines - x = ((x 8) 0x00FF00FF00FF00FFLL) | ((x 8) 0xFF00FF00FF00FF00LL); x = ((x 16) 0xLL) | ((x 16) 0xLL); to x = ((x 8) 0x00FF00FF00FF00FFi64) | ((x 8) 0xFF00FF00FF00FF00i64); x = ((x 16) 0xi64) | ((x 16) 0xi64); I tried various #define-s and typedef-s to fix this, but did not find one that WORKED ... maybe you can ... which can then be added to the _MSC_VER switch at the top of the file ... This is a LOCAL change you will have to MAKE ... I think I can assure you, at least I believe, such messy switch coding will NOT be added to the base code, just to support, a now old, known to be quite 'blind' C++ compiler, namely MSVC6 ;=)) Also, I should TRY to add this to my MSVC6 web pages of woes ... Have fun ... Regards, Geoff. PS: Thanks Kevin, for the offline email pointer - http://www.flightgear.org/Docs/Tutorials/fg_cygwin/fgfs_cygwin.pdf I will read this, and yes, I am using the latest CVS, as always, and not a 'stable' tar ball ... but do not see how this 'makefile' problem could be that ;=)) EOF _ MyCareer.com.au: Visit the NEW Salary Survey http://www.mycareer.com.au/salary-survey/?s_cid=203697 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] cloud bug in pre3
Here's an interesting one: When flying thru a cloud layer, that layer either disappears or becomes a solid cloud bank, which is fine when the viewpoint is from the cockpit. However, if the viewpoint is from the tower, or perhaps by extension, from another plane in multi-player mode (I can't check this), this becomes undesirable behavior. The entire world around the viewpoint becomes either zero visability or clear, for as long as your plane is in that layer. Cirrus, overcast, broken = total fog Scattered, few = disappear/clear Stewart ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
Oliver C. wrote: To make use of /usr/local/games/flightgear/ or /opt/flightgear/ by default we should change the configure script accordingly. As FlightGear is a self contained package (including binaries, libs and data) it belongs to /opt/flightgear according to the FHS. Which would also prevent us from living under .../games ;) Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
Oliver C. wrote: Then we should definitely officially use /usr/local/games/flightgear/ or /opt/flightgear/ as $FG_ROOT on unix systems. I don't understand why the hell people should want to use /usr/local/games/ for FlightGear ? Just curious, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Josh Babcock wrote: Ima Sudonim wrote: Probably accurately displaying the borders of parks and forested areas could help with VFR, no? (this is not to imply that the borders are not accurate, I don't know but it might be worth looking into) Again, a function of how accurate the VMAP data is. I think it's already pretty good, actually. Several people did comparisons between VMAP0 data and reality and it looks like VMAP0 is not very accurate at all in this area. I expect that we an offer a guide to the community in the not so distant future that explains how people can improve the landcover data and submit these improvements. Please keep in mind that carefully altering landcover data might comsume a noticeable amount of time On the other hand you will be compensated by very nice visual effects, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
On Monday 14 November 2005 18:05, Martin Spott wrote: Oliver C. wrote: Then we should definitely officially use /usr/local/games/flightgear/ or /opt/flightgear/ as $FG_ROOT on unix systems. I don't understand why the hell people should want to use /usr/local/games/ for FlightGear ? That's easy to answer: Because flying with Flightgear makes a lot of fun. :) Seriously, i can live with both directories. /opt/flightgear is fine too. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
Martin Spott wrote: Oliver C. wrote: Then we should definitely officially use /usr/local/games/flightgear/ or /opt/flightgear/ as $FG_ROOT on unix systems. I don't understand why the hell people should want to use /usr/local/games/ for FlightGear ? The slackware package puts the binaries in /usr/bin and the data files under /usr/share/FlightGear I *could* put the doc files in /usr/doc/Flightgear-$VERSION but since there are various references to them under FG_ROOT that's where I left them. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [BUG] environemnt_ctrl.cxx: exception triggers SGThread assert()
* Harald JOHNSEN -- Saturday 12 November 2005 17:09: Melchior FRANZ wrote: I've just implemented the check for stale METAR reports (to stop fetching after 10 stale reports). This triggers an assert in SGThread: It's perhaps because of the PTHREAD_CREATE_DETACHED attribute of the thread. Yes, that's very likely the case, according to the man-pages. So, how should the fix look like? - do not create the thread with PTHREAD_CREATE_DETACHED, or - do not try to join threads m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
Oliver C. wrote: Seriously, i can live with both directories. /opt/flightgear is fine too. Great - should we focus on this one for documentation purpose ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Martin Spott wrote: Several people did comparisons between VMAP0 data and reality and it looks like VMAP0 is not very accurate at all in this area. I expect that we an offer a guide to the community in the not so distant future that explains how people can improve the landcover data and submit these improvements. Please keep in mind that carefully altering landcover data might comsume a noticeable amount of time On the other hand you will be compensated by very nice visual effects, Also be very careful what you're using for source material - it's very easy to get caught up in copyright issues. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [BUG] environemnt_ctrl.cxx: exception triggers SGThread assert()
Melchior FRANZ wrote: * Harald JOHNSEN -- Saturday 12 November 2005 17:09: Melchior FRANZ wrote: I've just implemented the check for stale METAR reports (to stop fetching after 10 stale reports). This triggers an assert in SGThread: It's perhaps because of the PTHREAD_CREATE_DETACHED attribute of the thread. Yes, that's very likely the case, according to the man-pages. So, how should the fix look like? - do not create the thread with PTHREAD_CREATE_DETACHED, or - do not try to join threads If it's causing any troubles I would remove the first three lined of SGThread::start() since we've done without it for many years. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
* Oliver C. -- Monday 14 November 2005 18:46: [/usr/local/games/FlightGear or /opt/flightgear] Seriously, i can live with both directories. /opt/flightgear is fine too. Both are wrong, according to the FHS, and to common sense. The right path is /usr/local/share/ ... and guess what? It's already the default. So, nothing to see here -- move along. (Data sharable across platforms belong into a share/ directory -- /usr/share or /usr/local/share, depending on who installs it. There's not much room for personal preferences here. FlightGear isn't only used on home computers. :-) But before the next suggests to install in /etc/cool/games/ I better leave this thread. :- m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Hi, Martin Spott schrieb: Several people did comparisons between VMAP0 data and reality and it looks like VMAP0 is not very accurate at all in this area. I expect that we an offer a guide to the community in the not so distant future that explains how people can improve the landcover data and submit these improvements. Erm, yes...working on the GRASS-HowTo for Scenery Designers ;-) Didn't get far yet... Regarding the quality on VMAP0, I can't tell for the whole world, but at least in the South Germany area I have found bogus freeways and lots of important details are missing, such as landmark intersections for reporting points, whole towns and cities, etc. My hometown wasn't in there!!! ;-) With the standard scenery I couldn't find my way around my very home area...which should mean something ;-) With the altered scenery I do. Please keep in mind that carefully altering landcover data might comsume a noticeable amount of time On the other hand you will be compensated by very nice visual effects, Oh yes! :-) Cheers, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] cloud bug in pre3
Stewart Andreason wrote: Here's an interesting one: When flying thru a cloud layer, that layer either disappears or becomes a solid cloud bank, which is fine when the viewpoint is from the cockpit. However, if the viewpoint is from the tower, or perhaps by extension, from another plane in multi-player mode (I can't check this), this becomes undesirable behavior. The entire world around the viewpoint becomes either zero visability or clear, for as long as your plane is in that layer. Cirrus, overcast, broken = total fog Scattered, few = disappear/clear Stewart ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d You are right and it's an old bug, we are using the plane altitude to determine how to draw the cloud layers, while we should be using the *viewer* altitude. from render.cxx : thesky-preDraw( *cur_fdm_state-get_Altitude()* * SG_FEET_TO_METER, fog_exp2_density ); Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [BUG] environemnt_ctrl.cxx: exception triggers SGThread assert()
* Erik Hofman -- Monday 14 November 2005 18:47: If it's causing any troubles I would remove the first three lined of SGThread::start() since we've done without it for many years. It is causing troubles: the pthread_join manpage says: The joined thread th must be in the joinable state: it must not have been detached using pthread_detach(3) or the PTHREAD_CREATE_DETACHED attribute to pthread_create(3). And environment_ctrl.cxx *is* trying to join such an unjoinable thread, and makes fgfs abort. Fortunately, I'm quite clueless about threads and don't have to decide what to do. :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
Buchanan, Stuart wrote: --- Martin Spott [EMAIL PROTECTED] wrote: OK, so I think I'd like to suggest that for the Getting Started Guide we suggest for Windows whatever_path_to_FG/data/Scenery whatever_path_to_FG/Scenery and for *nix $FG_ROOT/Scenery /usr/share/FlightGear/Scenery But why do we have 2 dirs ? The Scenery directory of the base package is a subset of the world scenery so everything should be at the same place (in the world scenery dir), or am I wrong ? Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
--- Melchior FRANZ [EMAIL PROTECTED] wrote: Both are wrong, according to the FHS, and to common sense. The right path is /usr/local/share/ ... and guess what? It's already the default. So, What is FHS? So for consistency in the docs (and ignoring power users like the people who inhabit this list) we'd recommend $FG_ROOT/Scenery $FG_ROOT/WorldScenery where $FG_ROOT is the FG data directory, and can be anywhere anyone wishes (though I intend to reccommend c:\FlightGear for windows to avoid any whitespace issues) -Stuart ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Getting Started Guide - Terrain/Objects
Hi All, As with 0.9.9 we'll be using the FG scenery DB objects, will the default scenery directory topology be something this Scenery/Terrain/w010n50 Scenery/Objects/w010n50 ? Assuming this is the case - a) Should this be what is mentioned in the Getting Started Guide as the way scenery is installed (I'm happy to make the update) b) Should the binary installers create the Terrain and Objects subdirectories (someone else will have to do this one) From a documentation point of view, I don't want to have to explain two different approaches and the issues with a Terrain subdirectory that can arise, so it would be nice only to have one standard. -Stuart ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] error:Unknown exception in the main loop
I've seen a couple of Failed to open file messages w/o a file, and decided to hunt for that one. It looks like this is only thrown from within simgear, but always with a path. Closer examination reveals that easyxml.cxx throws it, and uses the same pattern as JSB and I had recently agreed to be problematic --- dynamically creating things on the stack and throwing them! Either I managed to persuade JSB in a wrong C++ fact (I'm not 100% sure about it), or each and every throw throughout simgear and flightgear must be reviewed and such usages rewritten. One might argue that this is smth that only aids in error recovery in already screwed up situations, but some exceptions might be thrown to indicate non-globally-fatal situations --- i.e., without looking at every such place we can't be sure. Bad news --- I've verified, and indeed this is a wrong way to throw a tmp object out of a stack frame. It's fine as long as the catch handler is in the same function. If all that the catch handler does is catch smth by reference and never access the instance, it is fine, but 1) the throw is still unsafe 2) in this case, all that the exception object is used for is just signal the type of exception by its C++ type, and thus it makes more sense to have one static object of that class for this very purpose, to save the ctor/dtor hassle. Bottom line: sg/fg contains a lot of unsafe and unportable code (i.e., some compilers will have it crash earlier than the others), and a patch is needed. I'll try to work on this in this coming weekend, time permitting. It's a lot of code to verify -- find . -name '*.[ch]*' | xargs cat | grep -c throw gave me 66 on sg and 43 on fg. It's a pity no exceptions like these had been thrown during the valgrind runs some folks were running. Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting Started Guide - Terrain/Objects
Hi All, As with 0.9.9 we'll be using the FG scenery DB objects, will the default scenery directory topology be something this Scenery/Terrain/w010n50 Scenery/Objects/w010n50 ? I suggest encouraging 2 directories --- 1 for the static scenery coming with FG, and the other one for the Terrasync DB/Jon's database/ whatever else external source. Melchior has it summed up pretty nicely at http://members.aon.at/mfranz/flightgear/flightgear-howto.html I'd only suggest to have the world scenery under smth like /var/share/FlightGear/WorldScenery (maybe share/games) rather than in the FG_ROOT, to make it more up-to-date with the current FHS. Assuming this is the case - a) Should this be what is mentioned in the Getting Started Guide as the way scenery is installed (I'm happy to make the update) b) Should the binary installers create the Terrain and Objects subdirectories (someone else will have to do this one) The binary installers could also have an option of launching a local terrasync service in a dedicated account with write permission into the world scenery Terrain subdir. From a documentation point of view, I don't want to have to explain two different approaches and the issues with a Terrain subdirectory that can arise, so it would be nice only to have one standard. In some place the difference would have to be explained because of the people that make the upgrade, wouldn't it? Thank you very much for the docu. updates! V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] XCode project files
On 12 Nov 2005, at 14:30, Arthur Wiebe wrote:I've been using Xcode 2.2 for some time now building Flightgear and everything else. Preview builds until now of course.By the way Xcode projects you can use to build PLIB, Simgear, and FlightGear are available now. I've polished them up so they should be ready. If you're interested I'll commit them to the macflightgear cvs.Please do commit them, I've had hand-rolled projects for all three for some time, but they're out of sync. If I find any issues, I'll let you know.James -- You whine like a mule. You are still alive! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting Started Guide - Terrain/Objects
--- Vassilii Khachaturov [EMAIL PROTECTED] wrote: Scenery/Terrain/w010n50 Scenery/Objects/w010n50 ? I suggest encouraging 2 directories --- 1 for the static scenery coming with FG, and the other one for the Terrasync DB/Jon's database/ whatever else external source. Melchior has it summed up pretty nicely at http://members.aon.at/mfranz/flightgear/flightgear-howto.html I'd only suggest to have the world scenery under smth like /var/share/FlightGear/WorldScenery (maybe share/games) rather than in the FG_ROOT, to make it more up-to-date with the current FHS. OK, I'll suggest /var/share/FlightGear/WorldScenery/[Terrain|Objects] for *nix, and FG_ROOT\Scenery\[Terrain|Objects] for Windows. The binary installers could also have an option of launching a local terrasync service in a dedicated account with write permission into the world scenery Terrain subdir. From a documentation point of view, I don't want to have to explaintwo different approaches and the issues with a Terrain subdirectory that can arise, so it would be nice only to have one standard. In some place the difference would have to be explained because of the people that make the upgrade, wouldn't it? I'm guessing that most users upgrading won't be re-reading the Getting Started Guide, so this will be a lower priority. Thank you very much for the docu. updates! It's a pleasure. I find it a nice managable contribution to make. Plus I think good documentation is very valuable. -Stuart ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting Started Guide - Terrain/Objects
Additionally no one should run terrasync as root anyway, so it can't write to /var/share/FlightGear. terrasync users should have their own scenery directory in their homes or anywhere their user is able to write. Nine I agree. User data (like from terrasync) belong to ~./local/share/FlightGear or ~./flightgear/ When using the latter one, we could also start to put the .fgfsrc config file into ~./flightgear/ I thought about a dedicated account for terrasync (non-root), with right permissions only to the /var/share/FlightGear/Scenery/Terrain (or WorldScenery/Terrain). ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting Started Guide - Terrain/Objects
Vassilii Khachaturov wrote: I thought about a dedicated account for terrasync (non-root), with right permissions only to the /var/share/FlightGear/Scenery/Terrain (or WorldScenery/Terrain). Terragear is sufficiently crude and unrefined and user unfriendly that I think we should leave it out of the getting started guide. We are going to send unsuspecting users down a wild goose chase and they'll be disappointed. We can mention it and forward them to more information, but I think we are asking for a lot of trouble if we try to document it in the getting started guide. For instance, it requires rsync to be installed on your system. Probably ok for most modern linux/freebsd systems, but a big problem for the typical windows user ... and even sun/sgi probably don't have it installed by default. Curt. -- 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
On Monday 14 November 2005 19:07, Buchanan, Stuart wrote: --- Melchior FRANZ [EMAIL PROTECTED] wrote: Both are wrong, according to the FHS, and to common sense. The right path is /usr/local/share/ ... and guess what? It's already the default. So, What is FHS? It's the unix Filesystem Hierarchy Standard http://www.pathname.com/fhs/ where $FG_ROOT is the FG data directory, and can be anywhere anyone wishes (though I intend to reccommend c:\FlightGear for windows to avoid any whitespace issues) On windows the Flightgear folder definitely belongs into C:\programs\FlightGear That's the default place for all Windows applications. The folder C:\programs can be accessed via a windows system variable, and this is the right way to do it, because this is required for localized purposes. For example on a German Windows installation the name for C:\programs\ is C:\Programme\ Thus the system variable should be used, instead of a direct access to the folder name. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
On Monday 14 November 2005 18:47, Melchior FRANZ wrote: * Oliver C. -- Monday 14 November 2005 18:46: [/usr/local/games/FlightGear or /opt/flightgear] Seriously, i can live with both directories. /opt/flightgear is fine too. Both are wrong, according to the FHS, and to common sense. The right path is /usr/local/share/ ... and guess what? It's already the default. So, nothing to see here -- move along. Ok, i can live with /usr/local/share (for flighgear data) too. :) Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting Started Guide - Terrain/Objects
Terragear is sufficiently crude and unrefined and user unfriendly that I think we should leave it out of the getting started guide. We are going to send unsuspecting users down a wild goose chase and they'll be disappointed. We can mention it and forward them to more information, but I think we are asking for a lot of trouble if we try to document it in the getting started guide. For instance, it requires rsync to be OK. This means that we should suggest $FG_ROOT/... based layout (but with different scenery dirs between the base package and the user-installed additional scenery --- unless we keep the scenery download page SFO tile to be the most up-to-date so that the SFO scenery is no longer nukable), and just have a terrasync pointer. Everything else (per-FHS-distro-flavoured dispersion of things under /opt's /share's /var's etc, suid terrasync etc) actually belongs in another document (not yet written, and needed with a much smaller priority, if at all) documenting the best current practices of fg packagers, so that Debian/Gentoo/RH/win32/... packages have the same shared know-how. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [BUG] environemnt_ctrl.cxx: exception triggers SGThread assert()
Unfortunately, reverting the recent changes (that caused the thread to be created with detached state) wasn't enough to fix the problem. The strange thing is, that the return value that triggers assert() is 35, or EAGAIN (Linux). This makes no sense. It's neither described on the pthread_join manpage, nor is it used in any implementation that I found on the net. Also, if I take it literally and try again in an endless loop, I get endless 35 codes. Maybe I've got a broken libpthread or something. Could someone try to reproduce it? $ fgfs --aircraft=ufo --prop:/environment/params/metar-max-age-min=1 --log-level=warn Then fly to another airport, say KOAK and wait. After one minute fgfs starts to fetch METAR reports for KOAK, but they are most likely older than one minute, so it fetches the next, and next, until it throws an exception after ten failed attempts. And this causes an abortion here: Error fetching live weather data: More than 10 stale METAR messages in a row. Stop fetching data permanently. fgfs: /usr/local/include/simgear/threads/SGThread.hxx:150: void \ SGThread::join(): Assertion `status == 0' failed. /home/m/bin/fgfs: line 239: 18187 Aborted (core dumped) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [BUG] environemnt_ctrl.cxx: exception triggers SGThread assert()
* Melchior FRANZ -- Monday 14 November 2005 22:29: $ fgfs --aircraft=ufo --prop:/environment/params/metar-max-age-min=1 --log-level=warn I forgot --enable-real-weather-fetch. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Ralf Gerlich schrieb: Erm, yes...working on the GRASS-HowTo for Scenery Designers ;-) Didn't get far yet... Cheers, Ralf Yes, would be a nice christmas present! :-) :-) I stared work with FGSD and made some smaller corrections but it is not possible to correct a bigger area with that tool in the present state (what does not mean that it is bad, it only needs further development and documentation). As always in life, it is a question whether you have the right tools to make a good job and enjoy it! Thank you in advance, Ralf, for finishing your GRASS-HowTo! Regards Georg ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
On Mon, 14 Nov 2005 16:42:24 +0100, Oliver wrote in message [EMAIL PROTECTED]: I suggest to remove the SF bay scenery in the corresponding 10x10 scenery file. This allows us to place the SF bay, which comes allready with the base package, in the main scenery folder like all the other 10x10 chunks. ..good idea, and can it be combined with locally made stuff too? And when someone installs the corresponding scenery tile w130n30.tar.gz it won't overwrite the SF bay. ..why do (or don't?) we want this file overwritten? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: freeglut on SuSE 10
Let us know how you get on, or better, if you're still stuck, ask for real-time help on the IRC channel. There has been a steady stream of such, I I've got Flight Gear 0.9.8 running. I can't thank you enough! I downloaded both RPMs from rpmfind, which I may have seen in passing during a google search, but wanted to stay safe with the official sites. It's a great site. I was getting quite a runaround chasing the SuSE docs, repositories and yast. I will try installing the CVS version soon or the prerelease. I may show up on IRC in time. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Missing Data/ directory in pre3 base package
Hi all, It seems the Data/ directory is missing in the pre3 package, which basically contains only Data/AI/ at the moment, and hence explains a few people not able to use the nimitz carrier (Data/AI/nimitz_demo.xml), and fgfs will simply terminate with a very vague message saying terminate called after throwing an instance of 'sg_io_exception' (reported by azuron on IRC). Pigeon. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
