Re: [Flightgear-devel] Fun with the FAA DOF.
Jon Stockill a écrit : Frederic Bouvier wrote: That's really nice ! But if all these models are placed automagically, what would happen to model that represent the real buildings ? I mean : if I create the Empire State Building and put it in fgfsdb, would there be a hole around it or would it be in collision with its generic clone ? It already happens at SFO with the radio towers and they need to be removed manually. Assuming there's a unique ID in the DOF (I've not seen the file yet) I'll maintain an exclusions list, so that when an updated DOF is imported such buildings can be ignored because we have a better version available. http://frbouvi.free.fr/flightsim/fgfs-sfo-generic-buildings.jpg -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] GLSL shaders for flightgear
- Original Message - From: "Josh Babcock" <[EMAIL PROTECTED]> To: "FlightGear developers discussions" Sent: Thursday, February 17, 2005 3:13 PM Subject: Re: [Flightgear-devel] GLSL shaders for flightgear > Ampere K. Hardraade wrote: > > On February 17, 2005 11:03 am, Dave Culp wrote: > > > >>>http://fgfs.narod.ru/fgfs-006.jpg > >>>Roman > >> > >>I had a really slow download from there so I'm mirroring it here: > >> > >>http://home.comcast.net/~davidculp2/3207.0.fgfs-006.jpg > >> > >>This should work better, at least over on this side of the Atlantic. > >> > >> > >>Dave > > > > It looks nice, but I think the lights should be larger and sharper as they > > become closer. > > > > Ampere > > > > ___ > > Flightgear-devel mailing list > > Flightgear-devel@flightgear.org > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > 2f585eeea02e2c79d7b1d8c4963bae2d > > > > Yes, very nice. Another thing you might take a look at is preventing the > sprites from intersecting with the ground. When they do, they get cut off > forming a sharp demarcation on the bottom. Perhaps they could be made smaller > and moved closer to the viewpoint in the scene graph. Good Idea Josh I'll lift them above the surface in shader based on distance > > Josh > > ___ > 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] GLSL shaders for flightgear
- Original Message - From: "Ampere K. Hardraade" <[EMAIL PROTECTED]> To: "FlightGear developers discussions" Sent: Thursday, February 17, 2005 1:22 PM Subject: Re: [Flightgear-devel] GLSL shaders for flightgear > On February 17, 2005 11:03 am, Dave Culp wrote: > > > http://fgfs.narod.ru/fgfs-006.jpg > > > Roman > > > > I had a really slow download from there so I'm mirroring it here: > > > > http://home.comcast.net/~davidculp2/3207.0.fgfs-006.jpg > > > > This should work better, at least over on this side of the Atlantic. > > > > > > Dave > It looks nice, but I think the lights should be larger and sharper as they > become closer. You can do it in shader code size a variable and calculated based on distance and initial size. > > Ampere > > ___ > 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] FlightGear version 9.2 Help Request
Thanks so much for your help, this works like a charm for FlightGear 0.9.2. Geoffrey Frost -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Paul Surgeon Sent: Wednesday, February 16, 2005 11:11 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] FlightGear version 9.2 Help Request On Wednesday, 16 February 2005 20:05, Geoffrey Frost wrote: > Can I just replace the radio-medium.xml file with a .3ds model and get the > same results? > > Geoffrey Frost No, the xml files are used to change attributes of models (animations, visual range, scale, etc) Here is a quick rundown on how to add a shared model to the current version of FlightGear - I'm not sure if this is applicable to 0.9.2 since I never ran that version and wouldn't have remembered anyway. :) Step 1 : Create a directory under the FlightGear data/Models directory. I'm going to use data/Models/MyModels as an example. Step 2 : Inside the data/Models/MyModels drirectory create an xml file called foomodel.xml with the following contents : foomodel.3ds range 0 25000 Step 3 : Create an 3ds model called foomodel.3ds and save it into the data/Models/MyModels directory. Notice that the xml file references the 3ds model file and tells FG that it must be visible from 0 meters up to 25 km. Step 4 : Start FG and fly (or use UFO model and move) to the location where you want to place the model. Open up the property browser in FG and write down the lat, lon and altitude where you want to place the model. (File->Browse Internal Properties->Position) Step 5 : In CVS there is a perl program called calc-tile.pl that works out what stg file a geodetic coordinate falls in. You can get it here if you don't feel like playing with CVS and don't have the CVS branch installed : http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/*checkout*/FlightGear/ scripts/perl/scenery/calc-tile.pl?rev=HEAD&cvsroot=FlightGear-0.9&content-ty pe=text/x-perl Run the perl script in a terminal window passing it the longitude and latitude that you wrote down in step 4. You'll probably have to install perl first if you run on a MS OS's. Example : [EMAIL PROTECTED] scenery]$ ./calc-tile.pl -55.5 30.3 Longitude: -55.5 Latitude: 30.3 Tile: 2039314 Path: "w060n30/w056n30/2039314.stg" Step 6 : Open the corresponding stg file in your scenery directory (in my case SceneryDir/w060n30/w056n30/2039314.stg) Step 7 : Add the following lines to the stg file replacing the parameters with your own : OBJECT_SHARED Models/MyModels/foomodel.xml -55.5 30.3 1000.0 0.00 The format is : OBJECT_SHARED Step 8 : Start FG and fly to where you added the model and it should be there. Hope that helps Paul ___ 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] ADF Fine-Tuning
Nick Coleman wrote: I'm in the process of fine-tuning the behaviour of the ADF (src/Instrumentation/adf.cxx), maintained by David M. One aspect of calculating the transmission range is the difference in elevation between the aircraft and the transmitter (aircraft at 10,000' get better reception than aircraft at 2,000'). Not necessarily true for the ADF. The normal Nav and Comm radios work in the (roughly) 108 to 136 MHz range, having a wavelength a bit under 3 meters. A typical ADF like the KR-86 covers 200 to 1799 kHz, with wavelengths from 167 m to 1500 m. Propagation conditions are much different in these 2 cases. Currently, if the transmitter is higher than the aircraft, the elevation is capped at 200ft. Does anyone know why? (It has the effect of precluding transmitters on a hilltop from having a longer range than one on the flat.) Actually a hill or mountain is usually a poor choice for a medium or low frequency (MF or LF) transmitter. At the longer wavelengths, it is commonly impractical or uneconomic to build an antenna on the order of 1/4 to 1/2 wavelength high. For a shorter antenna, the quality of the surrounding ground becomes more important to efficiency. A hill or mountain often exists because of underlying rock, and rock is generally a poor conductor, hence poor efficiency. A good site, particularly for the lower frequencies, is a salt marsh, which offers naturally better conductivity. Also, I'd like to model the interference from a mountain range between the transmitter and the aircraft. My plan is to find if there is terrain higher than aircraft altitude in a line drawn from current position to transmitter position. I know nothing about OpenGL so any clues on how to do this are gratefully accepted. (I imagine that this effect could eventually be ported across to the VOR code too.) To interfere with the signal propagation, an object generally needs to be large relative to the wavelength. This lets small hills and large buildings block VHF signals, hence the "line-of-sight" behavior. At the longer wavelengths of MF, it takes a pretty decent hill to have much effect, while in the LF range where many NDBs are placed, a pretty good sized mountain range is needed to have much effect. Finally, I plan to model night-time increased range, which is easy enough. Day to night propagation changes can increase range, but can also decrease it where the ground wave and sky wave interact to cause severe fading and a generally unreliable signal. Any comments welcome, even "You're wasting your time, no-one uses the ADF anymore." ;) Go for it, but be cautioned that the problem is more complex than it initially seems. The FAA recently announced plans to remove a long list of NDB approaches where GPS or other facilities make the NDBs redundant. Not mentioned is the likelihood that such unused NDBs will disappear. Other countries may still have need of ADF equipment for quite a while. Nick ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d -- Bill Earnest [EMAIL PROTECTED] Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear booth at Scale 3X
Gotta love those credits at the end of the movie segment... I would like to also thank all who contributed to the show with their equipment, time, and support. It was a lot of work and a lot of fun and something I could not have accomplished alone. Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: fgrun WIN32 double quoted path bug
Hi Fred, Yes, it is hard to notice, since this will work - --fg-scener"y=c:\my pa"th and only in the very, very unlikely case of say a path like 'my path a' would fail with - --fg-scener"y=c:\my path" a the space being 'outside' the quotes ... I think the win32 C/C++ runtime parser, that splits the command line into the char **argv, array, removes the double quotes ... I guess ... because FG does not complain of a bad option ... except in the 'exceptional' case ... Also, thank you and Norman, for the pthreads pointer ... which, I had thought was part of cygwin ... I have now CVS's this source, and when I get time, ;=)) will include this in my 'arsenal' ... then maybe I can get some of my TerraGear components to 'fork' ... rather than using my current 'work-around-s' ... One other small fgrun 'feature' I found, is that, if I back up to page[0], there is a delay while it re-loads apt.dat.gz, when I go 'forward' again ... have not yet looked at why ... but it is not a real problem ... and I am a few days behind in cvs terms ... To Jorge, yes, but not ONLY to run another FG ... ;=)) A thought-only, at this stage, is to say change aircraft, or FDM, and pass the new configuration back to the running FG ... the 'launcher' becomes 'controller', or dynamic re-configure-er, in some way ... way into future? ;=(( Or for fgrun to now launch Atlas ... or ... ??? But this is more about the win32 only line - WaitForSingleObject( pi.hProcess, INFINITE ); in the run_win32.cxx implementation, and does not influence, or change the run_posix.cxx port ... which uses waitpid( pid, &status, 0 ); on 'parent' fork, and execv( path.c_str(), pt ); on the 'child' ... and thus 'depends' on what these functions do ... I can see, say a preference item, like - [x] Modal Dialog, while FlightGear is running ... perhaps only appears in the win32 port ... the default can be on ... thus not changing fgrun's present action, but gives more 'options', to different users ... Or, even add a [Close], or [Hide] button, to the modal window ... then the preference(s) could be on that dialog, like - (o) Wait until FlightGear exits, or ( ) Do not show this modal dialog again. or ( ) Show this dialog for [30 ] seconds only. In the fltk window win32 implementation, I detected some exit problems, if I just 'big-red-X-ed' the modal dialog ... which got me 'looking' at some of this in the first place ... it seems 'wrong' not to provide some 'polite-exit' to this modal situation ... aside from when FG exits ... My particular case was, now that FG was running, I simply wanted to check, review, my command options ... like FG is 'beeping', didn't I select disable sound? ... etc ... not stare at a locked modal dialog situation ... Enjoy ... Geoff. _ Update your mobile with a hot polyphonic ringtone: http://fun.mobiledownloads.com.au/191191/index.wl?page=191191polyphonicringtone ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Segfault from todays CVS
Most likely connected to the ground-cache updates - as it only seems to affect yasim aircraft. (gdb) run --aircraft=hunter --airport=RCSS Starting program: /usr/bin/fgfs --aircraft=hunter --airport=RCSS [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 1938)] Failed to find runway 28R at airport RCSS [New Thread 32769 (LWP 1939)] [New Thread 16386 (LWP 1940)] [New Thread 32771 (LWP 1941)] [New Thread 49156 (LWP 1942)] Altitude = 18 Temp at alt (C) = 16 Temp sea level (C) = 16.0353 Altitude = 18 Dewpoint at alt (C) = 15 Dewpoint at sea level (C) = 15 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 1938)] 0x0ce8b760 in ?? () (gdb) bt #0 0x0ce8b760 in ?? () #1 0x40142974 in __dynamic_cast (from=0xce8b760, to=0x8548f9c , require_public=139557448, address=0x0, sub=0xbfffee80, subptr=0xbfffee8b) at ../../gcc-2.95.3/gcc/cp/tinfo2.cc:282 #2 0x081241cc in FGGroundCache::get_agl () #3 0x08121ac5 in FGInterface::get_agl_m () #4 0x081b21bb in yasim::FGGround::getGroundPlane () at netChannel.h:85 #5 0x081c1e6c in yasim::Model::updateGround () at Thruster.cpp:5 #6 0x081b140e in YASim::copyToYASim () at netChannel.h:85 #7 0x081b1048 in YASim::update () at netChannel.h:85 #8 0x08051d32 in fgUpdateTimeDepCalcs () #9 0x08052734 in fgMainLoop () #10 0x08086ec5 in GLUTidle () #11 0x4009b1c0 in idleWait () from /usr/local/lib/libglut.so.3 #12 0x4009b8bb in glutMainLoop () from /usr/local/lib/libglut.so.3 #13 0x08054d15 in fgMainInit () #14 0x0805175d in main () -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] GLSL shaders for flightgear
Ampere K. Hardraade wrote: On February 17, 2005 11:03 am, Dave Culp wrote: http://fgfs.narod.ru/fgfs-006.jpg Roman I had a really slow download from there so I'm mirroring it here: http://home.comcast.net/~davidculp2/3207.0.fgfs-006.jpg This should work better, at least over on this side of the Atlantic. Dave It looks nice, but I think the lights should be larger and sharper as they become closer. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Yes, very nice. Another thing you might take a look at is preventing the sprites from intersecting with the ground. When they do, they get cut off forming a sharp demarcation on the bottom. Perhaps they could be made smaller and moved closer to the viewpoint in the scene graph. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FlightGear booth at Scale 3X
As has been noted previously on our mailing lists, the FlightGear project had a booth this past weekend at the Southern California Linux Expo in Los Angeles, California. http://www.socallinuxexpo.org/ John Wojnaroski is building a 747 simulator (I use the present tense here because these things are never finished) :-) and he was willing to bring it to the show and show it off. Jim Brennan and I met at John's house on Thursday evening to help make some last minute software/hardware improvements to the simulator. Then we disassembled it and transported it to the show on Friday. I say a special thanks to Durk Talsma who put in some extra effort getting his traffic manager code ready to run in time for the show, and also to Jon Berndt who did some last minute 747 dynamics tweaks for us. For those that are interested, we have a more in depth description of John's 747 project here: http://www.flightgear.org/Projects/747-JW/ The quick project summary is that John has combined FlightGear, OpenGC, some of his own software, designed some of his own hardware, wrote a linux device driver for it, built the cockpit frame, and rolled it all together to form the complete cockpit. FlightGear is only one component of a much larger project. Alex Perry posted his pictures of our booth here: http://www.pamurray.com/fgfs/scale05/ I have posted a couple of my own pictures (and one movie) here: http://www.flightgear.org/tmp/Scale3X/ The included movie (3.5Mb) was done on a windows machine and is probably formated in a windows specific format. If anyone can convert it to a more portable format, I'd be happy to post that. I'm limited by my available software and my own lack of video editing experience here. I would like to thank John Wojnarowski for building a very impressive FlightGear/Linux based 747 simulator. I would also like to thank Jim Brennan for traveling down to LA to help with transporting the sim, providing LCD displays, as well as other miscellaneous bits and pieces (and for buying me lunch.) :-) Alex and Trish Perry spent a large amount of time helping out at the booth. Alex took a break from our booth on Saturday to a very nice talk on embedded linux. Finally, thanks to all the FlightGear developers who have contributed in large and small ways to make FlightGear (and projects like John's simulator) possible. Best 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] GLSL shaders for flightgear
On February 17, 2005 11:03 am, Dave Culp wrote: > > http://fgfs.narod.ru/fgfs-006.jpg > > Roman > > I had a really slow download from there so I'm mirroring it here: > > http://home.comcast.net/~davidculp2/3207.0.fgfs-006.jpg > > This should work better, at least over on this side of the Atlantic. > > > Dave It looks nice, but I think the lights should be larger and sharper as they become closer. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug: FG 0.9.8 won't start over land in Britain...
On Donnerstag 17 Februar 2005 16:28, Frederic Bouvier wrote: > Quoting Steve Hosgood : > > On Thu, 2005-02-17 at 15:09, Steve Hosgood wrote: > > Sounds bizarre, but this is quite reproduceable: if you *don't* have the > > w010n50 scenery tile loaded and use the command-line params --lat=51.6 > > --lon=-4.0 to start FlightGear, then it starts up just fine. > > There is a numerical problem at startup. Try --lat=51.6 --lon=-4.001 What numerical problem? Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug: FG 0.9.8 won't start over land in Britain...
On Thu, 2005-02-17 at 16:17, Frederic Bouvier wrote: > The tile boundary is not at integral degrees. They can be at .125, .250, .375, > .5, .625, .75 and .875 ( every 1/8 of a degree ) > Ah, it applies at that level does it? I suppose that's logical. OK, may I propose: /* KLUDGE: FIXME: avoid hang when starting on a tile boundary */ if (startup_long*8.0 == floor(startup_long*8.0)) startup_long += 0.0001; if (startup_lat*8.0 == floor(startup_lat*8.0)) startup_lat += 0.0001; Rule #1 of user interface design: don't expose the users to quirks of the implementation. In this case the above hack can be removed if/when anyone ever fixes the underlying tile-boundary problem, but until then it keeps the phone lines quiet at the help desk (!) and serves as a useful comment in the code to the effect that there's a bug to fix. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug: FG 0.9.8 won't start over land in Britain...
Quoting Steve Hosgood : > Might I propose the FGFS gods avoid causing pointless grief for newbies > and insert a fragment of code in the command-line parsing to the effect > of: > > /* KLUDGE: FIXME: avoid hang when starting on a tile boundary */ > if (startup_long == floor(startup_long)) startup_long += 0.0001; > if (startup_lat == floor(startup_lat)) startup_lat += 0.0001; > > (or whatever). The tile boundary is not at integral degrees. They can be at .125, .250, .375, .5, .625, .75 and .875 ( every 1/8 of a degree ) -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug: FG 0.9.8 won't start over land in Britain...
On Thu, 2005-02-17 at 15:28, Frederic Bouvier wrote: > There is a numerical problem at startup. Try --lat=51.6 --lon=-4.001 > > -Fred AAAGH! So simple, and I never tried such a thing! Dammit, I grovelled through the -devel and -users archives for quite a while to see if this was already known (it seemed so glaring a problem). Sorry to waste your time, folks and thank you for the prompt response. Steve. PS: Might I propose the FGFS gods avoid causing pointless grief for newbies and insert a fragment of code in the command-line parsing to the effect of: /* KLUDGE: FIXME: avoid hang when starting on a tile boundary */ if (startup_long == floor(startup_long)) startup_long += 0.0001; if (startup_lat == floor(startup_lat)) startup_lat += 0.0001; (or whatever). ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] GLSL shaders for flightgear
> http://fgfs.narod.ru/fgfs-006.jpg > Roman I had a really slow download from there so I'm mirroring it here: http://home.comcast.net/~davidculp2/3207.0.fgfs-006.jpg This should work better, at least over on this side of the Atlantic. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] GLSL shaders for flightgear
Hi guys! Now I translate my nvidia vertex and fragment programs to GLSL. bad news: fps drops around 10% good news: have ATI compartability here is screenshot: http://fgfs.narod.ru/fgfs-006.jpg so what I've done runway lights - point sprites with calculated visibility on vertex shader based on direction and fog taxyway lights - same based on distance and fog also point size is calculated on vertex shader. ground lights - the same as taxi but it's simple points - not point sprites. terrain - spot lights from aircraft, normal mapping + phong light +fog work in progress -clouds, VASI and HDR rendering. If someone needs a code feel free to ask. All tested on linux 66.96 nvidia +FX5950ultra PS: normal texture looks ugly but it's simple demo. Bye Roman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug: FG 0.9.8 won't start over land in Britain...
On Thu, 2005-02-17 at 15:13, Steve Hosgood wrote: > PS: Lat 51.6, Long 10.1 is over the Atlantic Ocean just west of Ireland. > It is of course also outside the named scenery tile. I've not tried a > start location over the sea *inside* the tile. I'll get back to y'all on > that one > Sorry: poorly edited prototype message! As I'd said earlier, it does start under those conditions. What I don't know is what happens when you start over the sea, but with land in sight. So far my tests have been over land (fails) or well out to sea (works). Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Bug: FG 0.9.8 won't start over land in Britain...
* Steve Hosgood -- Thursday 17 February 2005 16:13: [--lat=51.6 --lon=-4.0] > However, if you *do* have that scenery tile loaded, fgfs just hangs, > displaying the splash screen. That's a well known "feature". Just try to avoid lat/lon on tile borders. This should work: --lat=51.6 --lon=-4.0001 m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug: FG 0.9.8 won't start over land in Britain...
Quoting Steve Hosgood : > On Thu, 2005-02-17 at 15:09, Steve Hosgood wrote: > Sounds bizarre, but this is quite reproduceable: if you *don't* have the > w010n50 scenery tile loaded and use the command-line params --lat=51.6 > --lon=-4.0 to start FlightGear, then it starts up just fine. There is a numerical problem at startup. Try --lat=51.6 --lon=-4.001 -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Bug: FG 0.9.8 won't start over land in Britain...
On Thu, 2005-02-17 at 15:09, Steve Hosgood wrote: Sounds bizarre, but this is quite reproduceable: if you *don't* have the w010n50 scenery tile loaded and use the command-line params --lat=51.6 --lon=-4.0 to start FlightGear, then it starts up just fine. However, if you *do* have that scenery tile loaded, fgfs just hangs, displaying the splash screen. This is with stock 0.9.8 FlightGear compiled by me on Fedora core 2 and with Nvidia's standard binary driver. It did it with 0.9.6 too, can't remember about 0.9.4 but I'm fairly sure things worked as expected with 0.9.2 There's more: Command-line params --lat=51.6 --lon=-10.1 *will* allow FlightGear to start, even with the w010n50 scenery tile present (you'll notice that that start location is ouside the scenry tile though). In fact, a start location that *is* inside the scenery tile, but over the sea will also work. After you've got running, you can change your longitude to -4.0 with "change internal parameters" and there you are, flying toward Swansea Airport in South Wales as you'd expect. This seems so obvious a glitch, yet no-one else seems to be reporting it! Steve Hosgood PS: Lat 51.6, Long 10.1 is over the Atlantic Ocean just west of Ireland. It is of course also outside the named scenery tile. I've not tried a start location over the sea *inside* the tile. I'll get back to y'all on that one ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear version 9.2 Help Request
On Wed, 16 Feb 2005 21:11:13 +0200 Paul Surgeon wrote: > > No, the xml files are used to change attributes of models (animations, > visual range, scale, etc) > > Here is a quick rundown on how to add a shared model to the current > version of FlightGear - I'm not sure if this is applicable to 0.9.2 > since I never ran that version and wouldn't have remembered anyway. :) [ snip ] > Step 2 : > Inside the data/Models/MyModels drirectory create an xml file called > foomodel.xml with the following contents : It's worth noting that you don't *have* to create an .xml file. The entry in the *.stg file can refer to a model file (e.g. foomodel.ac or foomodel.3ds) rather than an .xml file (e.g. foomodel.xml). You probably *want* to use an .xml file, with the .xml file containing the model filename, as noted here, because then you get all the additional bells and whistles possible through the .xml file. But you don't *have* to do it that way. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpcWJXRIfPb7.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] fgrun WIN32 double quoted path bug
Geoff Air writes: > > I use msvc7, in XP, cygwin not installed, so also do not > use pthreads ... FYI you do not need Cygwin to run with pthreads on Windows see http://sources.redhat.com/pthreads-win32/ Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
