Re: [Flightgear-devel] YF-23/yasim: how to climb to 163000 ft
Melchior FRANZ wrote: $ fgfs --aircraft=YF-23 --airport=knuq --disable-real-weather-fetch - full throttle - climb to 8000 ft - 90 degree bank - pull stick fully back amazingly: you don't bleed off speed, but *accelerate* - at ~1630 kt (after that the speed decreases) 0 degree bank and 90 degree pitch up - climb to 163000 ft in no time If you really want to travel to other planets I suggest just pulling the throttle to zero when you reach the speed limit, while still rotating. This gives you the extra boost you need for interplanetary travel. Nine - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers
I once proposed a compatible ssg extension : http://frbouvi.free.fr/plib/nsssg.html I was able to use it with flightgear without code change except to support the new features ( like multi texturing and environment mapping ). The code still exist but stalled after it was ignored by the plib team and further developments ( like shaders ) were lost in a disk crash. Fred, is the code you refer to newer than the state-of-the art plib, or does it require an excessive merge? maybe you could fork plib into a simgear subdir and have a configure option to pick it up, if chosen? V. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Hang on exit when using SDL output
After some months of just hitting ctrl+c I finally tried to find out why FG hangs every time on exit just sitting there doing nothing. I did a backtrace on all threads and guessed, that sound may have something to do with it and it seems like I was right. I have (define devices '(sdl)) in my .openalrc. When I change it to anything else, the hang disappears and FG exits normally. I'm lucky to have changed my soundcard recently, so it still works perfectly with ALSA, so the hang is history for me. But thought it can't hurt to report it to the list, as I don't have the slightest idea how this could be solved. Could be that it's no FG bug at all, but something in OpenAL (using SuSE 10.1's openal-1.0.20051129-17) or SDL (SDL-1.2.9-19). The backtrace: (gdb) thread apply all bt Thread 7 (Thread -1466500192 (LWP 5846)): #0 0xe410 in __kernel_vsyscall () #1 0xb7efe7e6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x084081c6 in SGPthreadCond::wait (this=0xc37cc28, [EMAIL PROTECTED]) at /usr/local/FlightGear/include/simgear/threads/SGThread.hxx:332 #3 0x08424c82 in FGVoiceMgr::FGVoiceThread::wait_for_jobs (this=0xc37cc20) at voice.hxx:84 #4 0x084211d0 in FGVoiceMgr::FGVoiceThread::run (this=0xc37cc20) at voice.cxx:229 #5 0x08577276 in start_handler (arg=0xc37cc20) at SGThread.cxx:23 #6 0xb7efb34b in start_thread () from /lib/libpthread.so.0 #7 0xb797665e in clone () from /lib/libc.so.6 Thread 6 (Thread -1446536288 (LWP 5845)): #0 0xe410 in __kernel_vsyscall () #1 0xb796fd11 in ___newselect_nocancel () from /lib/libc.so.6 #2 0xb7eae8ff in SDL_Delay () from /usr/lib/libSDL-1.2.so.0 #3 0xb7b215a0 in sdl_blitbuffer () from /usr/lib/libopenal.so.0 #4 0x1057cef8 in ?? () #5 0xb7b2261c in _alcGetContext () from /usr/lib/libopenal.so.0 #6 0xb7b22864 in _alcDeviceWrite () from /usr/lib/libopenal.so.0 #7 0x0c37d1e0 in ?? () #8 0x1000 in ?? () #9 0xb7b35850 in ?? () from /usr/lib/libopenal.so.0 #10 0xb7b319b8 in ?? () from /usr/lib/libopenal.so.0 #11 0xb7b22826 in _alcDeviceWrite () from /usr/lib/libopenal.so.0 #12 0xb7b078ab in async_mixer_iterate () from /usr/lib/libopenal.so.0 #13 0xb7b07788 in async_mixer_iterate () from /usr/lib/libopenal.so.0 #14 0xb7b21a3a in Posix_ExitThread () from /usr/lib/libopenal.so.0 #15 0xb7b21a26 in Posix_ExitThread () from /usr/lib/libopenal.so.0 #16 0xb7efb34b in start_thread () from /lib/libpthread.so.0 #17 0xb797665e in clone () from /lib/libc.so.6 Thread 3 (Thread -1429750880 (LWP 5842)): #0 0xe410 in __kernel_vsyscall () #1 0xb7efe7e6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x084081c6 in SGPthreadCond::wait (this=0xc33a0c0, [EMAIL PROTECTED]) at /usr/local/FlightGear/include/simgear/threads/SGThread.hxx:332 #3 0x084917ce in SGBlockingQueuestd::string::pop (this=0xc33a07c) at /usr/local/FlightGear/include/simgear/threads/SGQueue.hxx:233 #4 0x0848c3c9 in FGMetarEnvironmentCtrl::MetarThread::run (this=0xc33ade0) at environment_ctrl.cxx:720 #5 0x08577276 in start_handler (arg=0xc33ade0) at SGThread.cxx:23 #6 0xb7efb34b in start_thread () from /lib/libpthread.so.0 #7 0xb797665e in clone () from /lib/libc.so.6 ---Type return to continue, or q return to quit--- Thread 2 (Thread -1252271200 (LWP 5841)): #0 0xe410 in __kernel_vsyscall () #1 0xb7efe7e6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x084081c6 in SGPthreadCond::wait (this=0xab609f0, [EMAIL PROTECTED]) at /usr/local/FlightGear/include/simgear/threads/SGThread.hxx:332 #3 0x0840822c in SGBlockingQueueFGTileEntry*::pop (this=0xab609ac) at /usr/local/FlightGear/include/simgear/threads/SGQueue.hxx:233 #4 0x08407766 in FGTileLoader::LoaderThread::run (this=0xaaf1850) at FGTileLoader.cxx:178 #5 0x08577276 in start_handler (arg=0xaaf1850) at SGThread.cxx:23 #6 0xb7efb34b in start_thread () from /lib/libpthread.so.0 #7 0xb797665e in clone () from /lib/libc.so.6 Thread 1 (Thread -1225910576 (LWP 5837)): #0 0xe410 in __kernel_vsyscall () #1 0xb7efc698 in pthread_join () from /lib/libpthread.so.0 #2 0xb7b21af9 in Posix_WaitThread () from /usr/lib/libopenal.so.0 #3 0xa9c79ba0 in ?? () #4 0x in ?? () Nine - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers
Vassilii Khachaturov wrote : I once proposed a compatible ssg extension : http://frbouvi.free.fr/plib/nsssg.html I was able to use it with flightgear without code change except to support the new features ( like multi texturing and environment mapping ). The code still exist but stalled after it was ignored by the plib team and further developments ( like shaders ) were lost in a disk crash. Fred, is the code you refer to newer than the state-of-the art plib, or does it require an excessive merge? maybe you could fork plib into a simgear subdir and have a configure option to pick it up, if chosen? This code was written in summer 2004 and left untouched since then. But I am afraid plib didn't changed that much too. Code is here : http://frbouvi.free.fr/plib/ -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers
On Saturday 29 July 2006 14:28, Frederic Bouvier wrote: Vassilii Khachaturov wrote : I once proposed a compatible ssg extension : http://frbouvi.free.fr/plib/nsssg.html I was able to use it with flightgear without code change except to support the new features ( like multi texturing and environment mapping ). The code still exist but stalled after it was ignored by the plib team and further developments ( like shaders ) were lost in a disk crash. Fred, is the code you refer to newer than the state-of-the art plib, or does it require an excessive merge? maybe you could fork plib into a simgear subdir and have a configure option to pick it up, if chosen? This code was written in summer 2004 and left untouched since then. But I am afraid plib didn't changed that much too. Code is here : http://frbouvi.free.fr/plib/ Hmm, I don't know if it is better to improove ssg and take it into our tree or if we should leave that work to somebody specialized to scenegraphs. Given the good work of Robert Osfield, Don Burns et. al. for osg. I tend to spend our work switching over to osg instead of redoing that ourself ... I have thought often about a thin scenegraph abstraction layer for some structural nodes. That could help us much when we need/want to switch to an other scenegraph. At least for a transition time we could have a ssg and an osg version in parallel without disturbing people willing to have the settled down and feature complete ssg build. Later such a layering could be beneficial if Redmond decides to cut OpenGL support completely like they tried several times in the past. ... I am curious what this years siggraph brings. I think of abstractions for Group/Transform nodes. Just to be able to plug together the scenegraph from flightgear's sources. Animations are scenegraph specific and shoudl be scenegraph specific. Animations will just need a pointer to a property. The aprioriate scenegraph callback objects/code can be entirely scenegraph specific and does not need to be abstracted. That code is only installed in the model scenegraph as a postprocessing step to model loading. What we will need is some cairo/glitz like 2d api to draw the HUD and do some MFD's. I believe that this is even more apprioriate for such rendering areas like issuing raw OpenGL commands. With such an abstraction we are open to map that to an immediate more rendering pass to a texture or if this is used to build up a part of the scenegraph in case we do not have RenderTexture available. ... btw: I fear that osg already has way better render to texture code that will find a kind of off screen buffer on almost every graphics card ... Also Camera nodes must be accessible from within flightgear. Whenever we need an other direct access to the scenegraph we can extend the abstraction layer. For those struggling with performance issues with abstraction layers, I can only tell that almost everything is done directly on the scenegraph. For example the performance critical cull and draw operations will not even know that there is an abstraction layer. Animations will be scenegraph specific and therefore not critical. Plugging together the scenegraph at load time will have some theoretical penalty that I doubt that it is measurable. Implementing that will be possible without branching and without the burden to do regular merges. It is designed from ground up to be able to do that. We can incrementally refactor what we have with ssg and provide the aprioriate abstractions that can definitely be used with osg and most probably be used with DirectX (Fred, you you have experience with DirectX?). As a first step I would like to refactor some code heading to that goal. You can alternatively call that cleanup, cleanup that is most likely sensible anyway. And such cleanup is the origin of that thread. Greetings Mathias - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Energy worm in hud
On Saturday 29 July 2006 00:18, Melchior FRANZ wrote: * Lee Elliott -- Saturday 29 July 2006 01:03: I saw that the test for ilcanclaw was re-introduced in hud_ladr.cxx and it seems to stop the energy worm from working No. It hasn't ever been changed there (Cockpit/hud_ladr.cxx). I only commented it out in the new HUD code in src/Instrumentation/HUD/HUD_ladder.cxx where it's still commented out. m. Strange - I must have used one of my locally modified files when I thought it was from cvs and then thought the test had been removed from the cvs version. LeeE - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Weekly CVS Changelog Summary: SimGear
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-27_00:15:20 (durk) /var/cvs/SimGear-0.3/source/simgear/scene/sky/oursun.cxx /var/cvs/SimGear-0.3/source/simgear/scene/sky/oursun.hxx /var/cvs/SimGear-0.3/source/simgear/scene/sky/sky.cxx /var/cvs/SimGear-0.3/source/simgear/scene/sky/sky.hxx Mark's dynamic sun color changes. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-27_11:34:32 (frohlich) /var/cvs/SimGear-0.3/source/simgear/scene/model/location.hxx Clean up scenery center handling. 2f585eeea02e2c79d7b1d8c4963bae2d - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Weekly CVS Changelog Summary: FlightGear source
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-23_03:14:03 (mfranz) /var/cvs/FlightGear-0.9/source/src/Instrumentation/HUD/HUD.hxx /var/cvs/FlightGear-0.9/source/src/Instrumentation/HUD/HUD_ladder.cxx - use Item::draw_circle() to draw circles (waypoint marker still to be done) - move variable declaration near their first use (c++ style rather than c) - rename (zenith|nadir|hat) to enable-(zenith|nadir|hat) and make them bool (for consistency reasons) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-23_11:41:18 (curt) /var/cvs/FlightGear-0.9/source/src/Instrumentation/HUD/HUD_ladder.cxx Re-implement the flight path marker (aka velocity vector) so it's position is computed from alpha and beta. Before the code U, V, W body velocities to compute alpha/beta. Why not just use the values directly. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-23_11:57:13 (mfranz) /var/cvs/FlightGear-0.9/source/src/Instrumentation/HUD/HUD_ladder.cxx cleanup (getBoolValue() returns false by default) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-23_12:47:23 (curt) /var/cvs/FlightGear-0.9/source/src/Instrumentation/HUD/HUD_ladder.cxx Switch sign of beta/drift. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-24_11:00:18 (mfranz) /var/cvs/FlightGear-0.9/source/src/Instrumentation/HUD/HUD.cxx /var/cvs/FlightGear-0.9/source/src/Instrumentation/HUD/HUD.hxx /var/cvs/FlightGear-0.9/source/src/Instrumentation/HUD/HUD_dial.cxx /var/cvs/FlightGear-0.9/source/src/Instrumentation/HUD/HUD_instrument.cxx /var/cvs/FlightGear-0.9/source/src/Instrumentation/HUD/HUD_label.cxx /var/cvs/FlightGear-0.9/source/src/Instrumentation/HUD/HUD_ladder.cxx /var/cvs/FlightGear-0.9/source/src/Instrumentation/HUD/HUD_tape.cxx - don't use 10 pt font size for width calculations, when in fact we use a 8 pt font (set 8 pt in preferences.xml, too) - fix vertical alignment of digits in label and ladder (temporary solution -- the whole font handling needs to be reviewd and fixed) - simplify nadir and zenith (they always want to be horizontally centered on the ladder lines, no?) - simplify and abstract label box drawing (no need for stippled side lines) - align text (more) correctly in label boxes =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-24_11:02:56 (mfranz) /var/cvs/FlightGear-0.9/source/src/Cockpit/hud.hxx make old HUD code work with 8 px font size =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-24_12:09:03 (mfranz) /var/cvs/FlightGear-0.9/source/src/Instrumentation/HUD/HUD.hxx /var/cvs/FlightGear-0.9/source/src/Instrumentation/HUD/HUD_label.cxx first stab at label box pointers. optiontop/option on a label makes such a box: _/\_ | Booo | |__| likewise with options bottom, left, right. The size can be set via option marker-offset (analogous to tape offsets), which describes the distance from the base to the peak. Default: 8 px =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-24_12:35:34 (mfranz) /var/cvs/FlightGear-0.9/source/src/Instrumentation/HUD/HUD.hxx no longer let top==left and bottom==right. This is necessary for label-box pointers, and may introduce bugs elsewhere. Not that I've notice any yet. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-24_12:46:08 (mfranz) /var/cvs/FlightGear-0.9/source/src/Instrumentation/HUD/HUD_label.cxx 8 is a bit too much for marker-offset default; use 5 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-24_12:52:20 (mfranz) /var/cvs/FlightGear-0.9/source/src/Instrumentation/HUD/HUD_tape.cxx I've heard that endless loops aren't overly popular. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-25_02:07:34 (mfranz) /var/cvs/FlightGear-0.9/source/src/Instrumentation/HUD/HUD.hxx /var/cvs/FlightGear-0.9/source/src/Instrumentation/HUD/HUD_label.cxx define label box pointer via pointer-width (width of base) and pointer-length =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-25_15:05:52 (mfranz) /var/cvs/FlightGear-0.9/source/src/Instrumentation/HUD/HUD_label.cxx finally fix the text-in-box alignment (= Rocket Science[TM]!) (This will be moved to HUD_instrument.cxx, where it will be available to all draw_text() users.) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-25_17:21:56 (mfranz) /var/cvs/FlightGear-0.9/source/src/Instrumentation/HUD/HUD.hxx /var/cvs/FlightGear-0.9/source/src/Instrumentation/HUD/HUD_label.cxx no more FONT_(LARGE|SMALL) (didn't work, anyway, and isn't needed) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-26_09:18:06 (curt) /var/cvs/FlightGear-0.9/source/src/FDM/flight.cxx Fix a class of problem that could lead to needless extra time jitter in the flight dynamics calculations. We run the FDM at 120hz and compute how many loops
[Flightgear-devel] Weekly CVS Changelog Summary: FlightGear data
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-24_11:01:41 (mfranz) /var/cvs/FlightGear-0.9/data/preferences.xml - set HUD font size to 8 px - remove trailing spaces/fix indentation =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-24_11:12:47 (mfranz) /var/cvs/FlightGear-0.9/data/Huds/f16.xml /var/cvs/FlightGear-0.9/data/Huds/Instruments/gload.xml /var/cvs/FlightGear-0.9/data/Huds/Instruments/ladder.xml /var/cvs/FlightGear-0.9/data/Huds/Instruments/latitude.xml /var/cvs/FlightGear-0.9/data/Huds/Instruments/longitude.xml /var/cvs/FlightGear-0.9/data/Huds/Sets/parameters.xml - finally center lon/lat correctly (I did it wrongly before, because that was the style of the old HUD, and it should be fully-compatible ...) - remove erroneous modulo from f16.xml. This isn't even read there. - enable nadir and zenith (they are just too pretty to ignore them :-) - various tweaks =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-24_12:37:49 (mfranz) /var/cvs/FlightGear-0.9/data/Huds/f16.xml fix label y coordinates =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-24_12:49:45 (curt) /var/cvs/FlightGear-0.9/data/Aircraft/YF-23/NTPS-set.xml An alternate HUD configuration for the YF-23 using the new HUD code. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-24_12:49:46 (curt) /var/cvs/FlightGear-0.9/data/Aircraft/YF-23/NTPS/Attic/NTPS-hud.xml /var/cvs/FlightGear-0.9/data/Aircraft/YF-23/NTPS/Attic/NTPS_target_task.xml An alternate HUD configuration for the YF-23 using the new HUD code. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-24_12:53:46 (curt) /var/cvs/FlightGear-0.9/data/Nasal/lead_target.nas /var/cvs/FlightGear-0.9/data/Nasal/Attic/track-target.nas /var/cvs/FlightGear-0.9/data/Nasal/track_target.nas Rename to avoid - in class name. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-24_13:19:14 (curt) /var/cvs/FlightGear-0.9/data/Aircraft/YF-23/NTPS/Attic/NTPS-hud.xml Update boxes a bit to use just committed cvs hud features. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-24_13:37:11 (curt) /var/cvs/FlightGear-0.9/data/AI/lead_aircraft.xml Initial revision. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-24_14:27:45 (curt) /var/cvs/FlightGear-0.9/data/Aircraft/ju52/README /var/cvs/FlightGear-0.9/data/Aircraft/ju52/dc3-sound.xml /var/cvs/FlightGear-0.9/data/Aircraft/ju52/ju52-set.xml /var/cvs/FlightGear-0.9/data/Aircraft/ju52/ju52.nas /var/cvs/FlightGear-0.9/data/Aircraft/ju52/ju52.xml /var/cvs/FlightGear-0.9/data/Aircraft/ju52/thumbnail.jpg Detlef Faber: Here is my Ju-52 3/m for inclusion in CVS, I've removed the LinuxTag Logo and added David Culps great parachuters. The Aircraft is licensed GPL v2. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-24_14:27:46 (curt) /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/2prop.rgb /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/afn2.ac /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/afn2.xml /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/alt-ger.ac /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/alt-ger.rgb /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/alt-ger.xml /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/alt-ger2.rgb /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/asi-ger.ac /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/asi-ger.rgb /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/asi-ger.xml /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/att-ger.ac /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/att-ger.rgb /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/att-ger.xml /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/compass-ger.ac /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/compass-ger.xml /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/compass.rgb /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/compass2.rgb /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/engine-ger.ac /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/engine-ger.xml Detlef Faber: Here is my Ju-52 3/m for inclusion in CVS, I've removed the LinuxTag Logo and added David Culps great parachuters. The Aircraft is licensed GPL v2. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-07-24_14:27:47 (curt) /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/fuellub.rgb /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/gear-ger.ac /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/ignition-ger.ac /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/ignswitch.rgb /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/ju52-1.rgb /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/ju52-2.rgb /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/ju52-4.rgb /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/ju52-5.rgb /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/ju52.ac /var/cvs/FlightGear-0.9/data/Aircraft/ju52/Models/ju52.xml
