Re: [Flightgear-devel] Problem report related to strange splash screens and crashes with certain aircraft
Arthur Wiebe wrote: I think this report basically pins down two of my problems. First, where spash screens on startup showed up as strange color stipes. And second, where certain aircraft which define their own spash screen crash fgfs. I got this report when trying to load the c310 (pre3). Hopefully either one of you will find what's wrong or I'll look into it some more tomorrow. Looking at the code I don't see anything abvious. You might want to add a fw printf() statements in SGTexture::ImageGetRow to see whether the sizes are correct and the pointers are valid. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem report related to strange splash screens and crashes with certain aircraft
Hey Erik, I may sound like I know what I'm doing sometimes but I really don't. :)Nevertheless I'll add some printf statements and see what happens. I suppose it should be done in the ImageGetRow implementation. On 11/12/05, Erik Hofman [EMAIL PROTECTED] wrote: Arthur Wiebe wrote: I think this report basically pins down two of my problems. First, where spash screens on startup showed up as strange color stipes. And second, where certain aircraft which define their own spash screen crash fgfs. I got this report when trying to load the c310 (pre3). Hopefully either one of you will find what's wrong or I'll look into it some more tomorrow.Looking at the code I don't see anything abvious. You might want to add a fw printf() statements in SGTexture::ImageGetRowto see whether the sizes are correct and the pointers are valid.Erik___Flightgear-devel mailing list Flightgear-devel@flightgear.orghttp://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d-- Arthur/- http://sourceforge.net/users/artooro/- http://artooro.blogspot.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Problem report related to strange splash screens and crashes with certain aircraft
I think this report basically pins down two of my problems.First, where spash screens on startup showed up as strange color stipes. And second, where certain aircraft which define their own spash screen crash fgfs. I got this report when trying to load the c310 (pre3).Hopefully either one of you will find what's wrong or I'll look into it some more tomorrow.Date/Time: 2005-11-11 22:51:12.314 +OS Version: 10.4.3 (Build 8F46)Report Version: 3Command: fgfsPath: FlightGear.app/Contents/Resources/fgfsParent: FlightGear [271]Version: ??? (???)PID: 272Thread: 0Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x01db7000Thread 0 Crashed:0 0x8a60 __memcpy + 704 (cpu_capabilities.h:189)1 libSystem.B.dylib 0x9001a878 fread + 152 2 libz.1.dylib 0x9108d1b0 gzread + 3643 fgfs 0x00104dfc SGTexture::ImageGetRow(SGTexture::_ImageRec*, unsigned char*, int, int) + 2484 fgfs 0x0010601c SGTexture::read_rgb_texture(char const*) + 860 5 fgfs 0x0001bce4 fgSplashInit(char const*) + 17646 fgfs 0x7430 fgMainInit(int, char**) + 13487 fgfs 0x3328 main + 1848 fgfs 0x2acc _start + 344 9 fgfs 0x2970 start + 60Thread 0 crashed with PPC Thread State 64: srr0: 0x8a60 srr1: 0x0200f030 vrsave: 0xff00 cr: 0x24000220 xer: 0x0004 lr: 0x9001a878 ctr: 0x0040 r0: 0x r1: 0xb690 r2: 0x r3: 0x01db7000 r4: 0x0354ec40 r5: 0x1000 r6: 0x0010 r7: 0x0020 r8: 0x0030 r9: 0x r10: 0x0060 r11: 0x0080 r12: 0x01db7000 r13: 0x r14: 0x r15: 0x r16: 0x r17: 0x r18: 0x r19: 0x r20: 0x r21: 0x r22: 0x r23: 0x r24: 0x00016bf0 r25: 0x0001 r26: 0x00016bf0 r27: 0x01db7000 r28: 0xa000e790 r29: 0x6bf0 r30: 0x1000 r31: 0x9001a7f0Binary Images Description: 0x1000 - 0x754fff fgfs /Users/arthur/Projects/FlightGearOSX/build/FlightGear/FlightGear.app/Contents/Resources/fgfs0x184 - 0x18b2fff com.apple.GeForce2MXGLDriver 1.4.16 (4.1.6) /System/Library/Extensions/GeForce2MXGLDriver.bundle/Contents/MacOS/GeForce2MXGLDriver 0x18ba000 - 0x18d3fff GLDriver /System/Library/Frameworks/OpenGL.framework/Versions/A/Resources/GLDriver.bundle/GLDriver0x18d9000 - 0x18f4fff GLRendererFloat /System/Library/Frameworks/OpenGL.framework/Versions/A/Resources/GLRendererFloat.bundle/GLRendererFloat 0x1c05000 - 0x1d14fff GLEngine /System/Library/Frameworks/OpenGL.framework/Resources/GLEngine.bundle/GLEngine0x8fe0 - 0x8fe54fff dyld 44.2 /usr/lib/dyld0x9000 - 0x901b3fff libSystem.B.dylib /usr/lib/libSystem.B.dylib 0x9020b000 - 0x9020 libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib0x90211000 - 0x90264fff com.apple.CoreText 1.0.1 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText 0x90291000 - 0x90342fff ATS /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS0x90371000 - 0x906aefff com.apple.CoreGraphics 1.256.27 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics 0x9073a000 - 0x90813fff com.apple.CoreFoundation 6.4.4 (368.18) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation0x9085c000 - 0x9085cfff com.apple.CoreServices 10.4 (???) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 0x9085e000 - 0x90960fff libicucore.A.dylib /usr/lib/libicucore.A.dylib0x909ba000 - 0x90a3efff libobjc.A.dylib /usr/lib/libobjc.A.dylib0x90a68000 - 0x90ad6fff com.apple.framework.IOKit 1.4 (???) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 0x90aed000 - 0x90af libauto.dylib /usr/lib/libauto.dylib0x90b06000 - 0x90dddfff com.apple.CoreServices.CarbonCore 671.2 /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore 0x90e43000 - 0x90ec3fff com.apple.CoreServices.OSServices 4.1 /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices0x90f0d000 - 0x90f4efff com.apple.CFNetwork 10.4.3 (129.2) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork0x90f63000 - 0x90f7bfff com.apple.WebServices 1.1.2 (1.1.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/WebServicesCore.framework/Versions/A/WebServicesCore 0x90f8b000 - 0x9100cfff com.apple.SearchKit 1.0.4 /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit0x91052000 - 0x9107bfff
[Flightgear-devel] Problem with HUD
I am having a problem porting a hud display that I wrote for use in FG8.0 up to 9.8. It hangs at the instruction in drawHUD() : for_each(HUD_deque.being(), HUD_deque.end(), HUDdraw()); with a segfault. The problems seems to be that there are 18 labels in hudlabel.xml, all 18 of which pass the instruction, but the program carries HUD_deque.size() as 20! Looks like it is looking for superfluous information. Where does it set the deque size, and how could it be going wrong? Thank you, Rex du Pont [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] problem with signs program, convert: command not found
Melchior, The new signs program, it's great! However, I'm noticing a problem on a mac os x system that I reinstalled recently. I downloaded new scripts this morning, when I install them in data and run signs (either from data/local/signs or from a copy of signs copied to bin, I get a series of error messages like this: creating: cache/A/KJFK_John_F_Kennedy_Intl.rgb sh: line 1: convert: command not found I had this working before the reinstall of my system. My question is: is the convert command new? (if so, do you know where I can get source (or binary version for mac os x (10.4)))? I don't know why it worked previously, maybe I had a convert command installed on the old install of the os but I can't seem to find it now. Thanks for your help! BTW, the signs are VERY cool, and it's especially nice that they're so extensible easily. I did notice that when I scroll thru fgfs to get to the top down view that I only see red lines appearing (i.e., the tops of the signs) instead of the signs as the signs are still vertical. Can the script be changed to display signs horizontal when this top-down view is used (Hit 'v' six times to get to this view)? Thanks for giving us all a very cool feature! ... and thanks for all your work on FlightGear! Ima ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with steering plane o WinXP
On Friday 06 May 2005 02:12, Tymoteusz Puciek Paul wrote: Well i got problem with flight gear on win xp, (amd athlon xp 2600, 1,9ghz, 512 mb ram, ati radeon 9550, no joystick installed or plugged). When i start fly (after choosing plain, airport, setting that i use keyboard) the plain is going forward it self, and, usualy it rotate left or right (on helicoprtes he can even make more han 360 degre rotate without aking off ground.) it happends on all plains. When i start a plain, i need to manu all time to steer formward, other way adter some meters i'm out of starting road +_+ I don't know why this happend, and this make me less happy :( What aircraft have you tried? Could you try an automatic take-off in the B-52F? Select the B-52F and the default airport settings. When FG has started press Shift-P and then 's' to get the 'mini-panel'. Either use Ctrl-b on the keyboard or click on the 'BRAKES' indicator on the panel (to release the parking brake) and then click on 'TO' on the 'AP Mode' instrument. Does the B-52F start a take-off roll along the runway? LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Problem with steering plane o WinXP
Well i got problem with flight gear on win xp, (amd athlon xp 2600, 1,9ghz, 512 mb ram, ati radeon 9550, no joystick installed or plugged). When i start fly (after choosing plain, airport, setting that i use keyboard) the plain is going forward it self, and, usualy it rotate left or right (on helicoprtes he can even make more han 360 degre rotate without aking off ground.) it happends on all plains. When i start a plain, i need to manu all time to steer formward, other way adter some meters i'm out of starting road +_+ I don't know why this happend, and this make me less happy :( -- Contra spen vado ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Problem adding a new scenery
Hi, I've download a new scenery (e010n30.tgz) and put it unzipped and untarred in the scenery directory of the FG data root. e010n30 scenery contains the entire Sicily, but when I choose to place (via menu) the plain on the ground in LICJ 25 (Palermo airport, runway 25) I find myself in the middle of the sea. Where's the wrong step I did ? tnx darko -- Last night I dreamt that somebody loved me no hope - but no harm just another false alarm http://www.autistici.org/darko http://myapu.blog.excite.it ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem adding a new scenery
Quoting darko [EMAIL PROTECTED]: Hi, I've download a new scenery (e010n30.tgz) and put it unzipped and untarred in the scenery directory of the FG data root. e010n30 scenery contains the entire Sicily, but when I choose to place (via menu) the plain on the ground in LICJ 25 (Palermo airport, runway 25) I find myself in the middle of the sea. Where's the wrong step I did ? Melchior already sumarized the problem and the solution : http://baron.flightgear.org/pipermail/flightgear-users/2005-March/010794.html -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with airport ENSB
Am Dienstag 05 April 2005 20:26 schrieb Timo Saarinen: Hi, Trying to start the Flightgear 0.9.8 with Svalbard airport ENSB (78 15 N - 15 30 E) the aircraft ends up to sea. I have correctly downloaded the tile and extracted it to correct location (Scenery/Terrain/e010n70). The Svalbard island can be seen east from the airplane. The other airports seem to work fine. Sounds like the airport itself is missing. Is there a file 'ENSB.btg.gz' in Scenery/Terrain/e010n70/e015n78? Are the file permissions correct? Cheers, Thomas ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Problem with airport ENSB
Hi, Trying to start the Flightgear 0.9.8 with Svalbard airport ENSB (78 15 N - 15 30 E) the aircraft ends up to sea. I have correctly downloaded the tile and extracted it to correct location (Scenery/Terrain/e010n70). The Svalbard island can be seen east from the airplane. The other airports seem to work fine. -Timo ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Problem solved about particle system
Hi, at last I solved the billboarding problem about the particles. I've changed some settings into the ssgSimpleState object, used to add the texture to particles, and the size of the bounding sphere. Now, even with the data stored into the GL_MODELVIEW matrix the objects are always visible. So, I don't need to get the view position and orientation data to correctly rotate the objects. Thanks, Luca Navighi a 2 MEGA e i primi 3 mesi sono GRATIS. Scegli Libero Adsl Flat senza limiti su http://www.libero.it ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem solved about particle system
On Tuesday 25 January 2005 15:13, Luca Masera wrote: Hi, at last I solved the billboarding problem about the particles. I've changed some settings into the ssgSimpleState object, used to add the texture to particles, and the size of the bounding sphere. Now, even with the data stored into the GL_MODELVIEW matrix the objects are always visible. So, I don't need to get the view position and orientation data to correctly rotate the objects. Thanks, Luca Are there any screen shots yet Luca? LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with Beaver and sound
Frederic Bouvier wrote: I just discovered that FG is suggesting me to upgrade my sound driver after alGenSources failed :-( This is the first time and all the other aircraft I tried never did the same. I even remember flying successfully with it not far ago. This should be fixed in SimGear CVS now. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with Beaver and sound
Frederic Bouvier wrote: I just discovered that FG is suggesting me to upgrade my sound driver after alGenSources failed :-( This is the first time and all the other aircraft I tried never did the same. I even remember flying successfully with it not far ago. A quick glance with the debugger showed me that alGenSources failed the 33rd time it was called, so I guess my driver/hardware ( yes a realtek on brand new mainboard with brand new drivers ) is only able to cope with 32 sources. I also noticed that 20 sources are allocated for the same sample : Aircraft/dhc2/Sound/click.wav Question: is it normal that the same sample is being allocated multiple times ? Couldn't we use a reference counter and share the same buffer/source ? It seems that click.wav is bound to panel switches. I guess that a panel will lots of switches will saturate the sound driver just like too much texture will flood the graphic card. I looked at the code a bit and there is some facility to share a sample when the name tag is identical, however the dhc2 uses a different name for each item that can click, so this means that a new sound sample is created for each item that can click. OpenAL has buffers and sources. We should be able bind multiple sources to a single buffer, but you are saying that it's alGenSources() that is failing so that doesn't help us. The problem is that each alSource specifies it's location and a bunch of other parameters. The way our xml syntax is structured, you can't just combine sources because you will overwrite the previous sources location and any custom configuration it had. So it almost seems like we need to solve this on the sound configuration side. Build one sound, with one source, and one location, and then trigger it any number of ways ... with a large block of conditions ... that is less intuitive from the sound configuration perspective, but it might be what we need to do? Thoughts? 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] Problem with Beaver and sound
I just discovered that FG is suggesting me to upgrade my sound driver after alGenSources failed :-( This is the first time and all the other aircraft I tried never did the same. I even remember flying successfully with it not far ago. A quick glance with the debugger showed me that alGenSources failed the 33rd time it was called, so I guess my driver/hardware ( yes a realtek on brand new mainboard with brand new drivers ) is only able to cope with 32 sources. I also noticed that 20 sources are allocated for the same sample : Aircraft/dhc2/Sound/click.wav Question: is it normal that the same sample is being allocated multiple times ? Couldn't we use a reference counter and share the same buffer/source ? It seems that click.wav is bound to panel switches. I guess that a panel will lots of switches will saturate the sound driver just like too much texture will flood the graphic card. Regards, -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with windows FlightGear v0.9.6
Can you run fgfs with log level debug set, and report the results? (Advanced Debugging in the launcher) Giles Robertson -Original Message- From: Christian Mayer [mailto:[EMAIL PROTECTED] Sent: 15 October 2004 16:33 To: FGFS Subject: [Flightgear-devel] Problem with windows FlightGear v0.9.6 Hi, I've downloaded FGFS (fgsetup-0.9.6.exe) and installed it. When I run it, I see the splash screen and hear the peeping sound - and then the program stops with that error message: Fatal error: Failed to gen source. (received from ) Are there any hints of what I should do? Thanks, Christian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with windows FlightGear v0.9.6
On Fri, Oct 15, 2004 at 05:49:21PM +0100, Giles Robertson wrote: Can you run fgfs with log level debug set, and report the results? (Advanced Debugging in the launcher) I have the same problem, I think. However I cannot fetch the log output, as the text window closes immediately upon crashing. Is this file dumped to disk somewhere? Thing runs, loads everything, I see correct images appearing, and then it all closes down without leaving a single trace why. Jeroen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with windows FlightGear v0.9.6
Jeroen Hoppenbrouwers a écrit : On Fri, Oct 15, 2004 at 05:49:21PM +0100, Giles Robertson wrote: Can you run fgfs with log level debug set, and report the results? (Advanced Debugging in the launcher) I have the same problem, I think. However I cannot fetch the log output, as the text window closes immediately upon crashing. Is this file dumped to disk somewhere? Thing runs, loads everything, I see correct images appearing, and then it all closes down without leaving a single trace why. Win32 0.9.6 has a change in console handling. If you start fgfs.exe from a command line with the one provided by fgrun, it will be output in that console, not in a new that immediately disappear. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with windows FlightGear v0.9.6
Jeroen Hoppenbrouwers schrieb: On Fri, Oct 15, 2004 at 05:49:21PM +0100, Giles Robertson wrote: Can you run fgfs with log level debug set, and report the results? (Advanced Debugging in the launcher) OK, I've attached it. The most interesting part will be: ** Updating time Current Unix calendar time = 1097869095 warp = 0 Current GMT = 10/15/2004 19:38:15 Current Unix calendar time = 1097869095 warp = 0 Current GMT = 10/15/2004 19:38:15 Current Julian Date = 2.45329e+006 COURSE: GMT = 9/15/104 19:38:15 March 21 noon (GMT) = 1079866800 Time since 3/21/104 GMT = 208.36 days = 208 hours = 19.6375 lon = 0 lst = 21.5042 COURSE: GMT = 9/15/104 19:38:15 March 21 noon (GMT) = 1079866800 Time since 3/21/104 GMT = 208.36 days = 208 hours = 19.6375 lon = 122.357 lst = 13.347 Current lon=0.00 Sidereal Time = 21.2823 gst = 141.282 Current LOCAL Sidereal Time = 13.1251 (13.1251) (diff = -0.221905) After fgInitTimeOffset(): warp = 0 Panel visible = 1 Refreshing timestamps for -999.938 0.0625 updateLocal(-2.13554, 0.65648, F:/Programme/FlightGear/data/Timezone) interpolate(): lookup error, x to small = -10012 In memory sounds sample In memory sounds sample interpolate(): lookup error, x to small = -10009 In memory sounds sample Fatal error: Failed to gen source. (received from ) Deleting a sample ** Apart from the interpolation problem (which might be the cause of the trouble), I see that we've got a (non critical) Y2K-bug there: COURSE: GMT = 9/15/104 19:38:15 should be COURSE: GMT = 9/15/2004 19:38:15 (and a few lines below is the similar problem...) I have the same problem, I think. However I cannot fetch the log output, as the text window closes immediately upon crashing. Is this file dumped to disk somewhere? You can easily start the shell (Start-Run-cmd.exe on W2K/WXP or command.exe IIRC on W95,W98,WME) and run FGFS from there. The launcher shows you the necessary command line before it tries to run FGFS. CU, Christian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Monday 20 September 2004 08:39, Vivian Meazza wrote:
{snip...]
Lee,
Here's some pics off the effects I obtained:
http://myweb.tiscali.co.uk/vmeazza/FlightGear/zero_drag-full_g
ravity.jpg
http://myweb.tiscali.co.uk/vmeazza/FlightGear/zero_gravity-acc
elerating.jpg
http://myweb.tiscali.co.uk/vmeazza/FlightGear/zero_gravity-bom
bs_overtaking. jpg
http://myweb.tiscali.co.uk/vmeazza/FlightGear/zero_gravity-bra
king.jpg
I hope that you can achieve the same.
Regards
Vivian
Sadly, no. Those pics are pretty much what I was hoping to see
here but it's just not happening. This is very odd.
I could post a pic showing the a/c after braking, with the string
of bombs behind and the cluster around the nose (which would
show that it had moved, while releasing bombs and was now
stationary) but is there any point?
I'm a bit reluctant to do a full fresh cvs checkout because I'd
have to also get a new base package too, wouldn't I? Still on
dial-up here so I'd like to avoid having to do that if possible.
If I delete the source code directories from my local cvs and
then did an update, would it replace anything that was missing?
I guess I could try getting FG installed on one of my other
workstations and see if I get the same results.
I did try setting a more verbose log-level but didn't see
anything there either.
This is such a strange problem. Because there are no apparent
run-time errors it's difficult not to conclude that there's a
logic error in the code but the fact it works elsewhere rules
that out.
Feeling pretty stumped here:-/
LeeE
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
Lee Elliott wrote: Sent: Sunday, September 19, 2004 12:48 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Sunday 19 September 2004 10:42, Vivian Meazza wrote: Lee Elliott wrote: Sent: Saturday, September 18, 2004 11:28 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model ...snip .. Hmm... (part 2) Just tried firing the Spitfire cannon via the property browser and while I could hear the cannon firing I couldn't see anything leaving the a/c. Could a library version mismatch cause this? There must be a problem at this end because it works for you on your system but I'm at a bit of a loss to explain it - the compilations of SimGear FlightGear seem to go fine. I haven't updated plib for a while - could the problem lie there? LeeE PLIB is not involved. I've just rechecked the cvs version - works here. The tracer is visible in the upper sector of the gun sight, but you might have to zoom into the gunfight a little to see it. If your eyes are very good, it is also visible from behind the aircraft, but you have to know where to look. The tracer is only visible from behind. You could also try at night, the tracer are more visible. That's at 800 x 600; if you have a 21 screen, its no problem at all. Do you have the tracer files in ..data/models/geometry? Any luck with the other tests? V. Not had a chance today to try them yet - hopefully later this P.M. I'm using a 19 screen at 1600x1200 and run FG in a maximised window i.e. with title bar and edges. Lee, Here's some pics off the effects I obtained: http://myweb.tiscali.co.uk/vmeazza/FlightGear/zero_drag-full_gravity.jpg http://myweb.tiscali.co.uk/vmeazza/FlightGear/zero_gravity-accelerating.jpg http://myweb.tiscali.co.uk/vmeazza/FlightGear/zero_gravity-bombs_overtaking. jpg http://myweb.tiscali.co.uk/vmeazza/FlightGear/zero_gravity-braking.jpg I hope that you can achieve the same. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
Lee Elliott wrote: ---snip If it wasn't for the fact that the same model works for you I'd suspect I'd got something wrong in the set-up. How do I fire the cannon in the Spitfire? I can't see a key-mapping anywhere. I suppose I could fire it via the property browser but that just makes me feel even more strongly that there's something wrong my end. LeeE Hmm... (part 2) Just tried firing the Spitfire cannon via the property browser and while I could hear the cannon firing I couldn't see anything leaving the a/c. Could a library version mismatch cause this? There must be a problem at this end because it works for you on your system but I'm at a bit of a loss to explain it - the compilations of SimGear FlightGear seem to go fine. I haven't updated plib for a while - could the problem lie there? LeeE Just a thought - can anyone else confirm either behaviour? Well, I upgraded to cvs (simgear/flightgear about 23:00 UTC 2004-09-18). I'm not exactly sure what behaviour is expected, but when I trigger via property browser - I can hear the cannon firing - I can see (very)little red dots from within the cockpit seeming to leave the cannon - I can see (very)little red dots from outside seeming to leave the cannon - I stops after - hmm... 20-30secs? - maybe out-of-submodels :-))) (using plib-1.8.3) Horst ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
Hmm... (part 2) Just tried firing the Spitfire cannon via the property browser and while I could hear the cannon firing I couldn't see anything leaving the a/c. Could a library version mismatch cause this? There must be a problem at this end because it works for you on your system but I'm at a bit of a loss to explain it - the compilations of SimGear FlightGear seem to go fine. I haven't updated plib for a while - could the problem lie there? Do you tried with --enable-ai-models ? I was caught by this recently. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
Lee Elliott wrote: Sent: Saturday, September 18, 2004 11:28 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model ...snip .. Hmm... (part 2) Just tried firing the Spitfire cannon via the property browser and while I could hear the cannon firing I couldn't see anything leaving the a/c. Could a library version mismatch cause this? There must be a problem at this end because it works for you on your system but I'm at a bit of a loss to explain it - the compilations of SimGear FlightGear seem to go fine. I haven't updated plib for a while - could the problem lie there? LeeE PLIB is not involved. I've just rechecked the cvs version - works here. The tracer is visible in the upper sector of the gun sight, but you might have to zoom into the gunfight a little to see it. If your eyes are very good, it is also visible from behind the aircraft, but you have to know where to look. The tracer is only visible from behind. You could also try at night, the tracer are more visible. That's at 800 x 600; if you have a 21 screen, its no problem at all. Do you have the tracer files in ..data/models/geometry? Any luck with the other tests? V. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
Arnt Karlsen Sent: Saturday, September 18, 2004 11:41 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Sat, 18 Sep 2004 13:21:13 +0100, Vivian wrote in message [EMAIL PROTECTED]: ... snip ... I can do all of that, providing I can get at the location of the CofG to relate the offsets. but no accelerations except gravity, to get it right. Not strictly true. We also need to apply aerodynamic forces. Drag is already applied, and wind can be applied, but no other. Wind is that experienced by the parent, not the submodel. This approximation is OK for tracer, less so for bombs. ..eh, accellerations, no, forces, yes. Same thing: a body changes velocity (i.e. accelerates) as the result of an applied force. Newton's 2nd Law. Both bomber and bomb sees the same wind etc until release of child. In a bomb bay or in a gun, the wind exposure happens as these objects emerge outta these shielded hideouts. Not quite true. The parent is experiencing wind, so it is a good enough approximation to apply wind to the child from instantiation. Turbulent airflow around the bomb-bay doors etc. is quite another thing. Although I suspect that the tumbling that you see on films is more or less rotation of the bomb about its CofG. Any that is not can be modelled by applying a bit of randomness to the trajectory. ..If either (plane or bomb etc) object passes thru say wind shear, wing tip vortices, then the wind forces are _different_, even if they can be approximated as the same as the bomb drops thru that vortice in a millisecond. ..and don't forget gun recoil forces. Yes, and charge temperature, barrel temperature and wear, Coriolis effect, parturition effect ... . Don't think I'll bother for guns fired from an aircraft with an effective range of 400 yds. Gun childs also experience wind drift. ;-) We already apply wind drift, but the wind is that experienced by the parent, not the child. This approximation is OK for guns, but makes no allowance for the various winds experienced by bombs during their descent. ..also, when we get that far in the modelling; some dive bombers had release rigging that threw some, say centerline bombs, clear of the propeller, adding to the fun we dream up here. We can already do that - just apply an appropriate initial velocity, and instantiate at the right offsets. ..also keep in mind most bombs are hung by more than one points, so the hardpoint mechanism and the flight conditions, attitude, rates etc, act together deciding which points release first, second etc on each bomb. We can probably ignore that. ..true, but see below. ..this too, has a major impact on the initial ballistics, think bobbing bombs dropping from B-52's or B-17's, on dropping out of the bomb bay, some of this is sudden exposure to the airstream, some is un-even release, asymmetric or whatever. We could probably add some randomness to account for this, if you think it's a significant factor, given all the other approximations, chief amongst which could be that the submodel has no inertia, and so aligns instantly with its trajectory. Again, OK for tracer, but for bombs? ..this is a design philosophy decision; how close to reality _do_ we wanna go? My point is do as you like, but don't cut off future development by hardcoding stuff, leave open hooks as bait for future developers to go berserk on. ;-) I'm afraid that it's all pretty hard stuff in C++, but if anyone wants to have a go at some of the math or coding, I'd welcome any help. As realistic as the input data will allow. I'm sure Lee wont let up on me 'till his BB bomb is right. Regards V. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Sunday 19 September 2004 10:42, Vivian Meazza wrote: Lee Elliott wrote: Sent: Saturday, September 18, 2004 11:28 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model ...snip .. Hmm... (part 2) Just tried firing the Spitfire cannon via the property browser and while I could hear the cannon firing I couldn't see anything leaving the a/c. Could a library version mismatch cause this? There must be a problem at this end because it works for you on your system but I'm at a bit of a loss to explain it - the compilations of SimGear FlightGear seem to go fine. I haven't updated plib for a while - could the problem lie there? LeeE PLIB is not involved. I've just rechecked the cvs version - works here. The tracer is visible in the upper sector of the gun sight, but you might have to zoom into the gunfight a little to see it. If your eyes are very good, it is also visible from behind the aircraft, but you have to know where to look. The tracer is only visible from behind. You could also try at night, the tracer are more visible. That's at 800 x 600; if you have a 21 screen, its no problem at all. Do you have the tracer files in ..data/models/geometry? Any luck with the other tests? V. Not had a chance today to try them yet - hopefully later this P.M. I'm using a 19 screen at 1600x1200 and run FG in a maximised window i.e. with title bar and edges. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Sun, 19 Sep 2004 11:23:35 +0200, Horst wrote in message [EMAIL PROTECTED]: I can hear the cannon firing I can see (very)little red dots from within the cockpit seeming to leave the cannon I can see (very)little red dots from outside seeming to leave the cannon I stops after - hmm... 20-30secs? - maybe out-of-submodels:-))) ..1/3 to 1/2 a minute sounds about right to be out of ammo. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Sun, 19 Sep 2004 11:17:22 +0100, Vivian wrote in message [EMAIL PROTECTED]: Arnt Karlsen Sent: Saturday, September 18, 2004 11:41 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Sat, 18 Sep 2004 13:21:13 +0100, Vivian wrote in message [EMAIL PROTECTED]: ... snip ... I can do all of that, providing I can get at the location of the CofG to relate the offsets. but no accelerations except gravity, to get it right. Not strictly true. We also need to apply aerodynamic forces. Drag is already applied, and wind can be applied, but no other. Wind is that experienced by the parent, not the submodel. This approximation is OK for tracer, less so for bombs. ..eh, accellerations, no, forces, yes. Same thing: a body changes velocity (i.e. accelerates) as the result of an applied force. Newton's 2nd Law. ..ah, precisely what I meant. ;-) Both bomber and bomb sees the same wind etc until release of child. In a bomb bay or in a gun, the wind exposure happens as these objects emerge outta these shielded hideouts. Not quite true. The parent is experiencing wind, so it is a good enough approximation to apply wind to the child from instantiation. ..I guess we'll leave that as bait for the berserk coders for now. ,-) Turbulent airflow around the bomb-bay doors etc. is quite another thing. Although I suspect that the tumbling that you see on films is more or less rotation of the bomb about its CofG. Any that is not can be modelled by applying a bit of randomness to the trajectory. ..quite right, some of this is caused by the turbulence, some of it by the bomb release mechanism letting go of the bomb. Also, there are those refreshingly wild stories of guys having to enter the bomb bay to kick out bombs riding that turbulent airflow. ;-) ..If either (plane or bomb etc) object passes thru say wind shear, wing tip vortices, then the wind forces are _different_, even if they can be approximated as the same as the bomb drops thru that vortice in a millisecond. ..and don't forget gun recoil forces. Yes, and charge temperature, barrel temperature and wear, Coriolis effect, parturition effect ... . Don't think I'll bother for guns fired from an aircraft with an effective range of 400 yds. Gun childs also experience wind drift. ;-) We already apply wind drift, but the wind is that experienced by the parent, not the child. This approximation is OK for guns, but makes no allowance for the various winds experienced by bombs during their descent. ..also, when we get that far in the modelling; some dive bombers had release rigging that threw some, say centerline bombs, clear of the propeller, adding to the fun we dream up here. We can already do that - just apply an appropriate initial velocity, and instantiate at the right offsets. ..also keep in mind most bombs are hung by more than one points, so the hardpoint mechanism and the flight conditions, attitude, rates etc, act together deciding which points release first, second etc on each bomb. We can probably ignore that. ..true, but see below. ..this too, has a major impact on the initial ballistics, think bobbing bombs dropping from B-52's or B-17's, on dropping out of the bomb bay, some of this is sudden exposure to the airstream, some is un-even release, asymmetric or whatever. We could probably add some randomness to account for this, if you think it's a significant factor, given all the other approximations, chief amongst which could be that the submodel has no inertia, and so aligns instantly with its trajectory. Again, OK for tracer, but for bombs? ..this is a design philosophy decision; how close to reality _do_ we wanna go? My point is do as you like, but don't cut off future development by hardcoding stuff, leave open hooks as bait for future developers to go berserk on. ;-) I'm afraid that it's all pretty hard stuff in C++, but if anyone wants to have a go at some of the math or coding, I'd welcome any help. As realistic as the input data will allow. I'm sure Lee wont let up on me'till his BB bomb is right. .. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Saturday 18 September 2004 23:59, Vivian Meazza wrote: Lee Elliott wrote: Sent: Saturday, September 18, 2004 11:06 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Saturday 18 September 2004 19:05, Vivian Meazza wrote: I wrote Sent: Saturday, September 18, 2004 3:44 PM To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] Problem with ballistic sub-model ... Snip ... Hmm... Just re-updated from cvs - no significant changes. Copied over all the latest data, did a make clean in both SimGear and FlightGear before re-compiling but still get no change. This is odd. If it wasn't for the fact that the same model works for you I'd suspect I'd got something wrong in the set-up. How do I fire the cannon in the Spitfire? I can't see a key-mapping anywhere. I suppose I could fire it via the property browser but that just makes me feel even more strongly that there's something wrong my end. LeeE The Spitfire uses a trigger on your joystick - something like: button n=1 descTrigger/desc binding commandproperty-assign/command property/systems/submodels/trigger/property value type=booltrue/value /binding mod-up binding commandproperty-assign/command property/systems/submodels/trigger/property value type=boolfalse/value /binding /mod-up /button I would suggest that you use the property browser to test the Spitfire m/gs. If the cvs download was OK it is unlikely that there is something wrong with your system. Similarly, if the submodel aligns with the parent when taxi-ing at a reasonable speed, then, basically, it's working since it calculates the angles from speed N/E/D. Try these submodel settings: submodel nameredbeard/name modelAircraft/EE-Canberra/Models/RedBeard.xml/model trigger/controls/armament/red-beard-released/trigger speed0/speed repeattrue/repeat delay1.0/delay count-1/count x-offset0.0/x-offset y-offset-0.0/y-offset z-offset0.0/z-offset yaw-offset0/yaw-offset pitch-offset0.0/pitch-offset eda1.2/eda windfalse/wind buoyancy0/buoyancy /submodel And these: submodel nameredbeard/name modelAircraft/EE-Canberra/Models/RedBeard.xml/model trigger/controls/armament/red-beard-released/trigger speed0/speed repeattrue/repeat delay1.0/delay count-1/count x-offset0.0/x-offset y-offset-0.0/y-offset z-offset0.0/z-offset yaw-offset0/yaw-offset pitch-offset0.0/pitch-offset eda0/eda windfalse/wind buoyancy32/buoyancy /submodel And let me know what you see so that I can compare. Regards V. Hello Vivian, I tried the two settings above for the Canberra and tried the Spitfire again at dusk but I'm still getting the same results:( I get identical behaviour with the Canberra: I'm accelerating to about 10kt, cutting the throttle so I'm rolling down the runway, and then hitting the release. In both cases I leave a trail of stationary bombs floating behind me and when I hit the brakes I get a cluster of bombs at different pitches oriented around the origin (still the nose of the a/c atm) In the Spitfire I can still hear the guns firing until the ammo is out but I can't see any tracer at all, in either cockpit or external views. Once the ammo's all out I can re-set the count and the guns start firing again but still no visible tracer. This is really odd:-/ LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
..quite right, some of this is caused by the turbulence, some of it by the bomb release mechanism letting go of the bomb. Also, there are those refreshingly wild stories of guys having to enter the bomb bay to kick out bombs riding that turbulent airflow. ;-) Can we model the Dr. Strangelove effect? Giles ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
Giles Robertson Sent: Sunday, September 19, 2004 6:02 PM To: FlightGear developers discussions Subject: RE: [Flightgear-devel] Problem with ballistic sub-model ..quite right, some of this is caused by the turbulence, some of it by the bomb release mechanism letting go of the bomb. Also, there are those refreshingly wild stories of guys having to enter the bomb bay to kick out bombs riding that turbulent airflow. ;-) Can we model the Dr. Strangelove effect? Now let's see. What's the Cd of a human - 1.0 - 1.3? Area seated astride a booomb - 4 sq ft? Make allowance for silly hat - 2 sq ft? Yup, we can do that. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
Now let's see. What's the Cd of a human - 1.0 - 1.3? Area seated astride a booomb - 4 sq ft? Make allowance for silly hat - 2 sq ft? Yup, we can do that. I love it. You can have a special parameter for it: slim_pickens=1. :) G -- I'm not crazy, I'm plausibly off-nominal! Proud owner of 80-0007 http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
The Stetson is being spun, so there's actually a twisting effect there as well. Giles Robertson -Original Message- From: Gene Buckle [mailto:[EMAIL PROTECTED] Sent: 19 September 2004 22:42 To: FlightGear developers discussions Subject: RE: [Flightgear-devel] Problem with ballistic sub-model Now let's see. What's the Cd of a human - 1.0 - 1.3? Area seated astride a booomb - 4 sq ft? Make allowance for silly hat - 2 sq ft? Yup, we can do that. I love it. You can have a special parameter for it: slim_pickens=1. :) G -- I'm not crazy, I'm plausibly off-nominal! Proud owner of 80-0007 http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
Lee Elliott wrote: Sent: Friday, September 17, 2004 9:57 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Friday 17 September 2004 16:09, Vivian Meazza wrote: Arnt Karlsen wrote: Sent: Friday, September 17, 2004 10:03 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Fri, 17 Sep 2004 07:56:42 +0100, Vivian wrote in message [EMAIL PROTECTED]: Ampere K. Hardraade wrote Sent: Thursday, September 16, 2004 7:12 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On September 16, 2004 01:08 pm, Vivian Meazza wrote: There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level ..uh, in the real world, this is possible if not permissible, with fun consequences like one or more hard points releases jammed for at least a while etc. They shouldn't inherit accelerations. Quite right - they shouldn't. I was getting over enthusiastic there, and forgetting my Newtonian physics. ..don't worry, there is also Murphy law physics. ;-) Right, back to Newton :-). I think I've solved the problem. Mixing elevation up = positive with speed down = positive nearly made my brain blow a fuse I had to reverse a number of signs to get it right. I took the opportunity to add roll to the submodel so that droptanks will come off with the right orientation. I not yet added either the parent rotational speed to the submodel, or yaw, so if you release droptanks with significant roll rate or yaw angle on the aircraft the submodel will not be quite right. Straight and level, or nearly so, is fine. I've asked Erik to upload the modified files to CVS. It looks OK on the Hunter, but perhaps Lee could give the revised submodel a good test. Regards Vivian Hello Vivian, I just updated from cvs, including updates to the sub-model stuff and while the pitch of the sub-model seems fixed ok, I'm still not able to get the speed right. I tried reducing the eda setting to a very low value (0.001) and then 0 but the velocity of the sub-model always seems to be zero. As an experiment I tried setting some +ve speed values i.e. 10 1000 but still got a zero sub-model speed - I tested this by 'releasing' the bomb (bearing in mind I have repeat and unlimited models set for de-bugging purposes) while sitting on the runway. Instead of a stream of sub-models moving forward away from the stationary a/c they remain at the origin. If I then accelerate the a/c I leave a trail of sub-models behind me. There's an archive of the a/c at http://www.overthetop.freeserve.co.uk/EE-Canberra-20040916.tar.gz ...if you want to have a look. The release keyboard mapping has been commented out in the ~set.xml file. Like the model: up to your usual standard. (Well, all except the pilot's bone dome - wrong pattern :-)) It works. The operative word is 'accelerate'. As you accelerate you leave bombs behind: they are instantiated with the velocity at the time of release, but since the aircraft is accelerating it will be left behind. Try the following using your original values in submodel: Release a bomb while stationary: it turns and aligns with the velocity - note although the aircraft is stationary, there are still some small N/E/D velocities. I'm not sure why. Accelerate down the runway: the bombs gradually align with the aircraft as forward motion is added, but they are left behind. Brake: the bombs shoot ahead of the aircraft, with their proper velocity. All those left behind now go past. Great fun - like big fish swimming by. I've convinced myself, anyway - Newton's Laws of Motion at work (see Arnt's comments). Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Fri, 17 Sep 2004 16:09:12 +0100, Vivian wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: Sent: Friday, September 17, 2004 10:03 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Fri, 17 Sep 2004 07:56:42 +0100, Vivian wrote in message [EMAIL PROTECTED]: Ampere K. Hardraade wrote Sent: Thursday, September 16, 2004 7:12 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On September 16, 2004 01:08 pm, Vivian Meazza wrote: There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level ..uh, in the real world, this is possible if not permissible, with fun consequenses like one or more hard points releases jammed for at least a while etc. They shouldn't inherit accelerations. Quite right - they shouldn't. I was getting over enthusiastic there, and forgetting my Newtonian physics. ..don't worry, there is also Murphy law physics. ;-) Right, back to Newton :-). I think I've solved the problem. Mixing elevation up = positive with speed down = positive nearly made my brain blow a fuse .. ;-) I had to reverse a number of signs to get it right. I took the opportunity to add roll to the submodel so that droptanks will come off with the right orientation. I not yet added either the parent rotational speed to the submodel, or yaw, so if you release droptanks with significant roll rate or yaw angle on the aircraft the submodel will not be quite right. Straight and level, or nearly so, is fine. ..precisely, we will need roll rate, yaw, yaw rate, pitch rate etc, but no accellerations except gravity, to get it right. ..also, when we get that far in the modelling; some divebombers had release rigging that threw some, say centerline bombs, clear of the propeller, adding to the fun we dream up here. ..also keep in mind most bombs are hung by more than one points, so the hardpoint mechanism and the flight conditions, attitude, rates etc, act together deciding which points release first, second etc on each bomb. ..this too, has a major impact on the initial ballistics, think bobbing bombs dropping from B-52's or B-17's, on dropping out of the bomb bay, some of this is sudden exposure to the airstream, some is un-even release, asymetric or whatever. I've asked Erik to upload the modified files to CVS. It looks OK on the Hunter, but perhaps Lee could give the revised submodel a good test. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
Arnt Karlsen wrote: Sent: Friday, September 17, 2004 9:47 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Fri, 17 Sep 2004 16:09:12 +0100, Vivian wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: Sent: Friday, September 17, 2004 10:03 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Fri, 17 Sep 2004 07:56:42 +0100, Vivian wrote in message [EMAIL PROTECTED]: Ampere K. Hardraade wrote Sent: Thursday, September 16, 2004 7:12 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On September 16, 2004 01:08 pm, Vivian Meazza wrote: There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level ..uh, in the real world, this is possible if not permissible, with fun consequences like one or more hard points releases jammed for at least a while etc. They shouldn't inherit accelerations. Quite right - they shouldn't. I was getting over enthusiastic there, and forgetting my Newtonian physics. ..don't worry, there is also Murphy law physics. ;-) Right, back to Newton :-). I think I've solved the problem. Mixing elevation up = positive with speed down = positive nearly made my brain blow a fuse .. ;-) I had to reverse a number of signs to get it right. I took the opportunity to add roll to the submodel so that droptanks will come off with the right orientation. I not yet added either the parent rotational speed to the submodel, or yaw, so if you release droptanks with significant roll rate or yaw angle on the aircraft the submodel will not be quite right. Straight and level, or nearly so, is fine. ..precisely, we will need roll rate, yaw, yaw rate, pitch rate etc, I can do all of that, providing I can get at the location of the CofG to relate the offsets. but no accelerations except gravity, to get it right. Not strictly true. We also need to apply aerodynamic forces. Drag is already applied, and wind can be applied, but no other. Wind is that experienced by the parent, not the submodel. This approximation is OK for tracer, less so for bombs. ..also, when we get that far in the modelling; some dive bombers had release rigging that threw some, say centerline bombs, clear of the propeller, adding to the fun we dream up here. We can already do that - just apply an appropriate initial velocity, and instantiate at the right offsets. ..also keep in mind most bombs are hung by more than one points, so the hardpoint mechanism and the flight conditions, attitude, rates etc, act together deciding which points release first, second etc on each bomb. We can probably ignore that. ..this too, has a major impact on the initial ballistics, think bobbing bombs dropping from B-52's or B-17's, on dropping out of the bomb bay, some of this is sudden exposure to the airstream, some is un-even release, asymmetric or whatever. We could probably add some randomness to account for this, if you think it's a significant factor, given all the other approximations, chief amongst which could be that the submodel has no inertia, and so aligns instantly with its trajectory. Again, OK for tracer, but for bombs? Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Saturday 18 September 2004 10:14, Vivian Meazza wrote: Lee Elliott wrote: Sent: Friday, September 17, 2004 9:57 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Friday 17 September 2004 16:09, Vivian Meazza wrote: Arnt Karlsen wrote: Sent: Friday, September 17, 2004 10:03 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Fri, 17 Sep 2004 07:56:42 +0100, Vivian wrote in message [EMAIL PROTECTED]: Ampere K. Hardraade wrote Sent: Thursday, September 16, 2004 7:12 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On September 16, 2004 01:08 pm, Vivian Meazza wrote: There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level ..uh, in the real world, this is possible if not permissible, with fun consequences like one or more hard points releases jammed for at least a while etc. They shouldn't inherit accelerations. Quite right - they shouldn't. I was getting over enthusiastic there, and forgetting my Newtonian physics. ..don't worry, there is also Murphy law physics. ;-) Right, back to Newton :-). I think I've solved the problem. Mixing elevation up = positive with speed down = positive nearly made my brain blow a fuse I had to reverse a number of signs to get it right. I took the opportunity to add roll to the submodel so that droptanks will come off with the right orientation. I not yet added either the parent rotational speed to the submodel, or yaw, so if you release droptanks with significant roll rate or yaw angle on the aircraft the submodel will not be quite right. Straight and level, or nearly so, is fine. I've asked Erik to upload the modified files to CVS. It looks OK on the Hunter, but perhaps Lee could give the revised submodel a good test. Regards Vivian Hello Vivian, I just updated from cvs, including updates to the sub-model stuff and while the pitch of the sub-model seems fixed ok, I'm still not able to get the speed right. I tried reducing the eda setting to a very low value (0.001) and then 0 but the velocity of the sub-model always seems to be zero. As an experiment I tried setting some +ve speed values i.e. 10 1000 but still got a zero sub-model speed - I tested this by 'releasing' the bomb (bearing in mind I have repeat and unlimited models set for de-bugging purposes) while sitting on the runway. Instead of a stream of sub-models moving forward away from the stationary a/c they remain at the origin. If I then accelerate the a/c I leave a trail of sub-models behind me. There's an archive of the a/c at http://www.overthetop.freeserve.co.uk/EE-Canberra-20040916.tar.gz ...if you want to have a look. The release keyboard mapping has been commented out in the ~set.xml file. Like the model: up to your usual standard. (Well, all except the pilot's bone dome - wrong pattern :-)) It works. The operative word is 'accelerate'. As you accelerate you leave bombs behind: they are instantiated with the velocity at the time of release, but since the aircraft is accelerating it will be left behind. Try the following using your original values in submodel: Release a bomb while stationary: it turns and aligns with the velocity - note although the aircraft is stationary, there are still some small N/E/D velocities. I'm not sure why. Accelerate down the runway: the bombs gradually align with the aircraft as forward motion is added, but they are left behind. Brake: the bombs shoot ahead of the aircraft, with their proper velocity. All those left behind now go past. Great fun - like big fish swimming by. I've convinced myself, anyway - Newton's Laws of Motion at work (see Arnt's comments). Regards Vivian Hello Vivian, I guess I'd better try to find some helmet 3-views;) I tried your suggestion of accelerating a little before releasing and then braking but the bombs are definitely staying in the same place after release. The buoyancy setting doesn't seem to be working either. I was originally using a buoyancy setting of 31 so that the bombs would fall slowly, allowing me to judge the eda value I needed but even when I set buoyancy to 34, so that they should rise, they still stayed in the same place, neither moving backwards or forwards, or up or down. When I set the speed to 100 I noticed that the bombs were all aligned correctly but when I tried re-setting it back to 0 I could see the alignment changing
RE: [Flightgear-devel] Problem with ballistic sub-model
Lee Elliott Sent: Saturday, September 18, 2004 3:03 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Saturday 18 September 2004 10:14, Vivian Meazza wrote: Lee Elliott wrote: Sent: Friday, September 17, 2004 9:57 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Friday 17 September 2004 16:09, Vivian Meazza wrote: Arnt Karlsen wrote: Sent: Friday, September 17, 2004 10:03 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Fri, 17 Sep 2004 07:56:42 +0100, Vivian wrote in message [EMAIL PROTECTED]: Ampere K. Hardraade wrote Sent: Thursday, September 16, 2004 7:12 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On September 16, 2004 01:08 pm, Vivian Meazza wrote: There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level ..uh, in the real world, this is possible if not permissible, with fun consequences like one or more hard points releases jammed for at least a while etc. They shouldn't inherit accelerations. Quite right - they shouldn't. I was getting over enthusiastic there, and forgetting my Newtonian physics. ..don't worry, there is also Murphy law physics. ;-) Right, back to Newton :-). I think I've solved the problem. Mixing elevation up = positive with speed down = positive nearly made my brain blow a fuse I had to reverse a number of signs to get it right. I took the opportunity to add roll to the submodel so that droptanks will come off with the right orientation. I not yet added either the parent rotational speed to the submodel, or yaw, so if you release droptanks with significant roll rate or yaw angle on the aircraft the submodel will not be quite right. Straight and level, or nearly so, is fine. I've asked Erik to upload the modified files to CVS. It looks OK on the Hunter, but perhaps Lee could give the revised submodel a good test. Regards Vivian Hello Vivian, I just updated from cvs, including updates to the sub-model stuff and while the pitch of the sub-model seems fixed ok, I'm still not able to get the speed right. I tried reducing the eda setting to a very low value (0.001) and then 0 but the velocity of the sub-model always seems to be zero. As an experiment I tried setting some +ve speed values i.e. 10 1000 but still got a zero sub-model speed - I tested this by 'releasing' the bomb (bearing in mind I have repeat and unlimited models set for de-bugging purposes) while sitting on the runway. Instead of a stream of sub-models moving forward away from the stationary a/c they remain at the origin. If I then accelerate the a/c I leave a trail of sub-models behind me. There's an archive of the a/c at http://www.overthetop.freeserve.co.uk/EE-Canberra-20040916.tar.gz ...if you want to have a look. The release keyboard mapping has been commented out in the ~set.xml file. Like the model: up to your usual standard. (Well, all except the pilot's bone dome - wrong pattern :-)) It works. The operative word is 'accelerate'. As you accelerate you leave bombs behind: they are instantiated with the velocity at the time of release, but since the aircraft is accelerating it will be left behind. Try the following using your original values in submodel: Release a bomb while stationary: it turns and aligns with the velocity - note although the aircraft is stationary, there are still some small N/E/D velocities. I'm not sure why. Accelerate down the runway: the bombs gradually align with the aircraft as forward motion is added, but they are left behind. Brake: the bombs shoot ahead of the aircraft, with their proper velocity. All those left behind now go past. Great fun - like big fish swimming by. I've convinced myself, anyway - Newton's Laws of Motion at work (see Arnt's comments). Regards Vivian Hello Vivian, I guess I'd better try to find some helmet 3-views;) I tried your suggestion of accelerating a little before releasing and then braking but the bombs are definitely staying in the same place after release. The buoyancy setting doesn't seem to be working either. I was originally using a buoyancy setting of 31 so that the bombs
Re: [Flightgear-devel] Problem with ballistic sub-model
On Saturday 18 September 2004 15:44, Vivian Meazza wrote: [snip...] It's just occurred to me that I'm using my local version, so it's possible that I haven't asked Erik to upload one of the multitude of files it requires to alter one parameter, or there's something wrong with the files I sent in. It's definitely OK here with your model. I'll check. There's nothing in the base package. BTW negative velocities don't work, otherwise drag would cause things to run backwards. If you want submodels to move to the rear apply a +ve speed with 180 yaw offset. Bone dome is easy - there's a Mk1A in the Hunter models. Feel free to use it. There's no under-helmet right now - on my todo list. You'll need the visor as well. Regards Vivian Thanks for looking into this - strange one though. Good to hear that it works properly on your system but that now means I have to find what's wrong with mine:) I'll take up your offer of a more accurate Bone dome too and use the one from the Hunter - Ta. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
Vivian Meazza wrote: It's just occurred to me that I'm using my local version, so it's possible that I haven't asked Erik to upload one of the multitude of files it requires to alter one parameter, or there's something wrong with the files I sent in. It's definitely OK here with your model. I'll check. There's nothing in the base package. You could try this: cd FlightGear/src cvs login cvs -z3 up -Pd cvs diff -puRN /tmp/diff cvs logout cat /tmp/diff Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
I wrote Sent: Saturday, September 18, 2004 3:44 PM To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] Problem with ballistic sub-model ... Snip ... Hmm... It's just occurred to me that although my cvs is up to date, I haven't copied over the base package data for a couple of days - is there anything in there that could be causing this problem? I've got to go out now but I'll try copying over the latest data too, when I get back. LeeE It's just occurred to me that I'm using my local version, so it's possible that I haven't asked Erik to upload one of the multitude of files it requires to alter one parameter, or there's something wrong with the files I sent in. It's definitely OK here with your model. I'll check. There's nothing in the base package. BTW negative velocities don't work, otherwise drag would cause things to run backwards. If you want submodels to move to the rear apply a +ve speed with 180 yaw offset. Bone dome is easy - there's a Mk1A in the Hunter models. Feel free to use it. There's no under-helmet right now - on my to-do list. You'll need the visor as well. Lee Blown that theory. I've just downloaded and recompiled. The Red Beard does what it should. I've made it go up, down, forward, back Buoyancy (sp ?) etc. all work. Try Buoyancy = 32 and eda = 0 (eda = 1 is the non-op), and you'll see that the parent velocities are transferred to the submodel. I can't think of anything else to suggest. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Saturday 18 September 2004 19:05, Vivian Meazza wrote: I wrote Sent: Saturday, September 18, 2004 3:44 PM To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] Problem with ballistic sub-model ... Snip ... Hmm... It's just occurred to me that although my cvs is up to date, I haven't copied over the base package data for a couple of days - is there anything in there that could be causing this problem? I've got to go out now but I'll try copying over the latest data too, when I get back. LeeE It's just occurred to me that I'm using my local version, so it's possible that I haven't asked Erik to upload one of the multitude of files it requires to alter one parameter, or there's something wrong with the files I sent in. It's definitely OK here with your model. I'll check. There's nothing in the base package. BTW negative velocities don't work, otherwise drag would cause things to run backwards. If you want submodels to move to the rear apply a +ve speed with 180 yaw offset. Bone dome is easy - there's a Mk1A in the Hunter models. Feel free to use it. There's no under-helmet right now - on my to-do list. You'll need the visor as well. Lee Blown that theory. I've just downloaded and recompiled. The Red Beard does what it should. I've made it go up, down, forward, back Buoyancy (sp ?) etc. all work. Try Buoyancy = 32 and eda = 0 (eda = 1 is the non-op), and you'll see that the parent velocities are transferred to the submodel. I can't think of anything else to suggest. Regards Vivian Hmm... I'll look further into this... update cvs etc. Thanks for checking. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Saturday 18 September 2004 19:05, Vivian Meazza wrote: I wrote Sent: Saturday, September 18, 2004 3:44 PM To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] Problem with ballistic sub-model ... Snip ... Hmm... It's just occurred to me that although my cvs is up to date, I haven't copied over the base package data for a couple of days - is there anything in there that could be causing this problem? I've got to go out now but I'll try copying over the latest data too, when I get back. LeeE It's just occurred to me that I'm using my local version, so it's possible that I haven't asked Erik to upload one of the multitude of files it requires to alter one parameter, or there's something wrong with the files I sent in. It's definitely OK here with your model. I'll check. There's nothing in the base package. BTW negative velocities don't work, otherwise drag would cause things to run backwards. If you want submodels to move to the rear apply a +ve speed with 180 yaw offset. Bone dome is easy - there's a Mk1A in the Hunter models. Feel free to use it. There's no under-helmet right now - on my to-do list. You'll need the visor as well. Lee Blown that theory. I've just downloaded and recompiled. The Red Beard does what it should. I've made it go up, down, forward, back Buoyancy (sp ?) etc. all work. Try Buoyancy = 32 and eda = 0 (eda = 1 is the non-op), and you'll see that the parent velocities are transferred to the submodel. I can't think of anything else to suggest. Regards Vivian Hmm... Just re-updated from cvs - no significant changes. Copied over all the latest data, did a make clean in both SimGear and FlightGear before re-compiling but still get no change. This is odd. If it wasn't for the fact that the same model works for you I'd suspect I'd got something wrong in the set-up. How do I fire the cannon in the Spitfire? I can't see a key-mapping anywhere. I suppose I could fire it via the property browser but that just makes me feel even more strongly that there's something wrong my end. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Saturday 18 September 2004 23:06, Lee Elliott wrote: On Saturday 18 September 2004 19:05, Vivian Meazza wrote: I wrote Sent: Saturday, September 18, 2004 3:44 PM To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] Problem with ballistic sub-model ... Snip ... Hmm... It's just occurred to me that although my cvs is up to date, I haven't copied over the base package data for a couple of days - is there anything in there that could be causing this problem? I've got to go out now but I'll try copying over the latest data too, when I get back. LeeE It's just occurred to me that I'm using my local version, so it's possible that I haven't asked Erik to upload one of the multitude of files it requires to alter one parameter, or there's something wrong with the files I sent in. It's definitely OK here with your model. I'll check. There's nothing in the base package. BTW negative velocities don't work, otherwise drag would cause things to run backwards. If you want submodels to move to the rear apply a +ve speed with 180 yaw offset. Bone dome is easy - there's a Mk1A in the Hunter models. Feel free to use it. There's no under-helmet right now - on my to-do list. You'll need the visor as well. Lee Blown that theory. I've just downloaded and recompiled. The Red Beard does what it should. I've made it go up, down, forward, back Buoyancy (sp ?) etc. all work. Try Buoyancy = 32 and eda = 0 (eda = 1 is the non-op), and you'll see that the parent velocities are transferred to the submodel. I can't think of anything else to suggest. Regards Vivian Hmm... Just re-updated from cvs - no significant changes. Copied over all the latest data, did a make clean in both SimGear and FlightGear before re-compiling but still get no change. This is odd. If it wasn't for the fact that the same model works for you I'd suspect I'd got something wrong in the set-up. How do I fire the cannon in the Spitfire? I can't see a key-mapping anywhere. I suppose I could fire it via the property browser but that just makes me feel even more strongly that there's something wrong my end. LeeE Hmm... (part 2) Just tried firing the Spitfire cannon via the property browser and while I could hear the cannon firing I couldn't see anything leaving the a/c. Could a library version mismatch cause this? There must be a problem at this end because it works for you on your system but I'm at a bit of a loss to explain it - the compilations of SimGear FlightGear seem to go fine. I haven't updated plib for a while - could the problem lie there? LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Saturday 18 September 2004 23:28, Lee Elliott wrote: On Saturday 18 September 2004 23:06, Lee Elliott wrote: On Saturday 18 September 2004 19:05, Vivian Meazza wrote: I wrote Sent: Saturday, September 18, 2004 3:44 PM To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] Problem with ballistic sub-model ... Snip ... Hmm... It's just occurred to me that although my cvs is up to date, I haven't copied over the base package data for a couple of days - is there anything in there that could be causing this problem? I've got to go out now but I'll try copying over the latest data too, when I get back. LeeE It's just occurred to me that I'm using my local version, so it's possible that I haven't asked Erik to upload one of the multitude of files it requires to alter one parameter, or there's something wrong with the files I sent in. It's definitely OK here with your model. I'll check. There's nothing in the base package. BTW negative velocities don't work, otherwise drag would cause things to run backwards. If you want submodels to move to the rear apply a +ve speed with 180 yaw offset. Bone dome is easy - there's a Mk1A in the Hunter models. Feel free to use it. There's no under-helmet right now - on my to-do list. You'll need the visor as well. Lee Blown that theory. I've just downloaded and recompiled. The Red Beard does what it should. I've made it go up, down, forward, back Buoyancy (sp ?) etc. all work. Try Buoyancy = 32 and eda = 0 (eda = 1 is the non-op), and you'll see that the parent velocities are transferred to the submodel. I can't think of anything else to suggest. Regards Vivian Hmm... Just re-updated from cvs - no significant changes. Copied over all the latest data, did a make clean in both SimGear and FlightGear before re-compiling but still get no change. This is odd. If it wasn't for the fact that the same model works for you I'd suspect I'd got something wrong in the set-up. How do I fire the cannon in the Spitfire? I can't see a key-mapping anywhere. I suppose I could fire it via the property browser but that just makes me feel even more strongly that there's something wrong my end. LeeE Hmm... (part 2) Just tried firing the Spitfire cannon via the property browser and while I could hear the cannon firing I couldn't see anything leaving the a/c. Could a library version mismatch cause this? There must be a problem at this end because it works for you on your system but I'm at a bit of a loss to explain it - the compilations of SimGear FlightGear seem to go fine. I haven't updated plib for a while - could the problem lie there? LeeE Just a thought - can anyone else confirm either behaviour? LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Saturday 18 September 2004 23:40, Arnt Karlsen wrote: On Sat, 18 Sep 2004 13:21:13 +0100, Vivian wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: Sent: Friday, September 17, 2004 9:47 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Fri, 17 Sep 2004 16:09:12 +0100, Vivian wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: Sent: Friday, September 17, 2004 10:03 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Fri, 17 Sep 2004 07:56:42 +0100, Vivian wrote in message [EMAIL PROTECTED]: Ampere K. Hardraade wrote Sent: Thursday, September 16, 2004 7:12 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On September 16, 2004 01:08 pm, Vivian Meazza wrote: There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level ..uh, in the real world, this is possible if not permissible, with fun consequences like one or more hard points releases jammed for at least a while etc. They shouldn't inherit accelerations. Quite right - they shouldn't. I was getting over enthusiastic there, and forgetting my Newtonian physics. ..don't worry, there is also Murphy law physics. ;-) Right, back to Newton :-). I think I've solved the problem. Mixing elevation up = positive with speed down = positive nearly made my brain blow a fuse.. ;-) I had to reverse a number of signs to get it right. I took the opportunity to add roll to the submodel so that droptanks will come off with the right orientation. I not yet added either the parent rotational speed to the submodel, or yaw, so if you release droptanks with significant roll rate or yaw angle on the aircraft the submodel will not be quite right. Straight and level, or nearly so, is fine. ..precisely, we will need roll rate, yaw, yaw rate, pitch rate etc, I can do all of that, providing I can get at the location of the CofG to relate the offsets. but no accelerations except gravity, to get it right. Not strictly true. We also need to apply aerodynamic forces. Drag is already applied, and wind can be applied, but no other. Wind is that experienced by the parent, not the submodel. This approximation is OK for tracer, less so for bombs. ..eh, accellerations, no, forces, yes. Both bomber and bomb sees the same wind etc until release of child. In a bomb bay or in a gun, the wind exposure happens as these objects emerge outta these shielded hideouts. ..If either (plane or bomb etc) object passes thru say wind shear, wing tip vortices, then the wind forces are _different_, even if they can be approximated as the same as the bomb drops thru that vortice in a millisecond. ..and don't forget gun recoil forces. Gun childs also experience wind drift. ;-) ..also, when we get that far in the modelling; some dive bombers had release rigging that threw some, say centerline bombs, clear of the propeller, adding to the fun we dream up here. We can already do that - just apply an appropriate initial velocity, and instantiate at the right offsets. ..also keep in mind most bombs are hung by more than one points, so the hardpoint mechanism and the flight conditions, attitude, rates etc, act together deciding which points release first, second etc on each bomb. We can probably ignore that. ..true, but see below. ..this too, has a major impact on the initial ballistics, think bobbing bombs dropping from B-52's or B-17's, on dropping out of the bomb bay, some of this is sudden exposure to the airstream, some is un-even release, asymmetric or whatever. We could probably add some randomness to account for this, if you think it's a significant factor, given all the other approximations, chief amongst which could be that the submodel has no inertia, and so aligns instantly with its trajectory. Again, OK for tracer, but for bombs? ..this is a design philosophy decision; how close to reality _do_ we wanna go? My point is do as you like, but don't cut off future development by hardcoding stuff, leave open hooks as bait for future developers to go berserk on. ;-) The development philosophy behind FG seems, to me, to be: get something working, then refine it:) I'm still at the get-it-working stage:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problem with ballistic sub-model
Lee Elliott wrote: Sent: Saturday, September 18, 2004 11:06 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Saturday 18 September 2004 19:05, Vivian Meazza wrote: I wrote Sent: Saturday, September 18, 2004 3:44 PM To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] Problem with ballistic sub-model ... Snip ... Hmm... Just re-updated from cvs - no significant changes. Copied over all the latest data, did a make clean in both SimGear and FlightGear before re-compiling but still get no change. This is odd. If it wasn't for the fact that the same model works for you I'd suspect I'd got something wrong in the set-up. How do I fire the cannon in the Spitfire? I can't see a key-mapping anywhere. I suppose I could fire it via the property browser but that just makes me feel even more strongly that there's something wrong my end. LeeE The Spitfire uses a trigger on your joystick - something like: button n=1 descTrigger/desc binding commandproperty-assign/command property/systems/submodels/trigger/property value type=booltrue/value /binding mod-up binding commandproperty-assign/command property/systems/submodels/trigger/property value type=boolfalse/value /binding /mod-up /button I would suggest that you use the property browser to test the Spitfire m/gs. If the cvs download was OK it is unlikely that there is something wrong with your system. Similarly, if the submodel aligns with the parent when taxi-ing at a reasonable speed, then, basically, it's working since it calculates the angles from speed N/E/D. Try these submodel settings: submodel nameredbeard/name modelAircraft/EE-Canberra/Models/RedBeard.xml/model trigger/controls/armament/red-beard-released/trigger speed0/speed repeattrue/repeat delay1.0/delay count-1/count x-offset0.0/x-offset y-offset-0.0/y-offset z-offset0.0/z-offset yaw-offset0/yaw-offset pitch-offset0.0/pitch-offset eda1.2/eda windfalse/wind buoyancy0/buoyancy /submodel And these: submodel nameredbeard/name modelAircraft/EE-Canberra/Models/RedBeard.xml/model trigger/controls/armament/red-beard-released/trigger speed0/speed repeattrue/repeat delay1.0/delay count-1/count x-offset0.0/x-offset y-offset-0.0/y-offset z-offset0.0/z-offset yaw-offset0/yaw-offset pitch-offset0.0/pitch-offset eda0/eda windfalse/wind buoyancy32/buoyancy /submodel And let me know what you see so that I can compare. Regards V. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Fri, 17 Sep 2004 07:56:42 +0100, Vivian wrote in message [EMAIL PROTECTED]: Ampere K. Hardraade wrote Sent: Thursday, September 16, 2004 7:12 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On September 16, 2004 01:08 pm, Vivian Meazza wrote: There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level ..uh, in the real world, this is possible if not permissible, with fun consequenses like one or more hard points releases jammed for at least a while etc. They shouldn't inherit accelerations. Quite right - they shouldn't. I was getting over enthusiastic there, and forgetting my Newtonian physics. ..don't worry, there is also Murphy law physics. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
Arnt Karlsen wrote: Sent: Friday, September 17, 2004 10:03 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Fri, 17 Sep 2004 07:56:42 +0100, Vivian wrote in message [EMAIL PROTECTED]: Ampere K. Hardraade wrote Sent: Thursday, September 16, 2004 7:12 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On September 16, 2004 01:08 pm, Vivian Meazza wrote: There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level ..uh, in the real world, this is possible if not permissible, with fun consequenses like one or more hard points releases jammed for at least a while etc. They shouldn't inherit accelerations. Quite right - they shouldn't. I was getting over enthusiastic there, and forgetting my Newtonian physics. ..don't worry, there is also Murphy law physics. ;-) Right, back to Newton :-). I think I've solved the problem. Mixing elevation up = positive with speed down = positive nearly made my brain blow a fuse I had to reverse a number of signs to get it right. I took the opportunity to add roll to the submodel so that droptanks will come off with the right orientation. I not yet added either the parent rotational speed to the submodel, or yaw, so if you release droptanks with significant roll rate or yaw angle on the aircraft the submodel will not be quite right. Straight and level, or nearly so, is fine. I've asked Erik to upload the modified files to CVS. It looks OK on the Hunter, but perhaps Lee could give the revised submodel a good test. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
Vivian Meazza wrote: Ampere K. Hardraade wrote Sent: Thursday, September 16, 2004 7:12 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model They shouldn't inherit accelerations. Ampere On September 16, 2004 01:08 pm, Vivian Meazza wrote: There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level :-). Regards Vivian Quite right - they shouldn't. I was getting over enthusiastic there, and forgetting my Newtonian physics. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Of course, they shouldn't inherit the plane's velocity exactly either unless they are at the cg of the plane or the plane isn't rotating. Theoretically, if you released a wing tip tank just at you gave a sharp roll input, you could toss it over the fuselage. You'd probably also tear your wings off and break your neck too, but you get the point. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
Josh Babcock wrote: Sent: Friday, September 17, 2004 5:41 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model Vivian Meazza wrote: Ampere K. Hardraade wrote Sent: Thursday, September 16, 2004 7:12 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model They shouldn't inherit accelerations. Ampere On September 16, 2004 01:08 pm, Vivian Meazza wrote: There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level :-). Regards Vivian Quite right - they shouldn't. I was getting over enthusiastic there, and forgetting my Newtonian physics. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Of course, they shouldn't inherit the plane's velocity exactly either unless they are at the cg of the plane or the plane isn't rotating. Theoretically, if you released a wing tip tank just at you gave a sharp roll input, you could toss it over the fuselage. You'd probably also tear your wings off and break your neck too, but you get the point. I would like to add the parent rotational velocities to the submodel for completeness. The math is a bit complex, but the main problem is that I can't find where the CofG is. I need to relate the offsets to the CofG, rather than the model origin. However, as a compromise, I might add roll velocity assuming it to be around the x axis, and ignore the other 2 axes ... I'm not sure if that is better than ignoring the problem altogether. Perhaps someone could tell me how to get at the CofG? Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Friday 17 September 2004 16:09, Vivian Meazza wrote: Arnt Karlsen wrote: Sent: Friday, September 17, 2004 10:03 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Fri, 17 Sep 2004 07:56:42 +0100, Vivian wrote in message [EMAIL PROTECTED]: Ampere K. Hardraade wrote Sent: Thursday, September 16, 2004 7:12 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On September 16, 2004 01:08 pm, Vivian Meazza wrote: There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level ..uh, in the real world, this is possible if not permissible, with fun consequenses like one or more hard points releases jammed for at least a while etc. They shouldn't inherit accelerations. Quite right - they shouldn't. I was getting over enthusiastic there, and forgetting my Newtonian physics. ..don't worry, there is also Murphy law physics. ;-) Right, back to Newton :-). I think I've solved the problem. Mixing elevation up = positive with speed down = positive nearly made my brain blow a fuse I had to reverse a number of signs to get it right. I took the opportunity to add roll to the submodel so that droptanks will come off with the right orientation. I not yet added either the parent rotational speed to the submodel, or yaw, so if you release droptanks with significant roll rate or yaw angle on the aircraft the submodel will not be quite right. Straight and level, or nearly so, is fine. I've asked Erik to upload the modified files to CVS. It looks OK on the Hunter, but perhaps Lee could give the revised submodel a good test. Regards Vivian Hello Vivian, I just updated from cvs, including updates to the sub-model stuff and while the pitch of the sub-model seems fixed ok, I'm still not able to get the speed right. I tried reducing the eda setting to a very low value (0.001) and then 0 but the velocity of the sub-model always seems to be zero. As an experiment I tried setting some +ve speed values i.e. 10 1000 but still got a zero sub-model speed - I tested this by 'releasing' the bomb (bearing in mind I have repeat and unlimited models set for de-bugging purposes) while sitting on the runway. Instead of a stream of sub-models moving forward away from the stationary a/c they remain at the origin. If I then accelerate the a/c I leave a trail of sub-models behind me. There's an archive of the a/c at http://www.overthetop.freeserve.co.uk/EE-Canberra-20040916.tar.gz ...if you want to have a look. The release keyboard mapping has been commented out in the ~set.xml file. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
Lee Elliott wrote: Sent: Wednesday, September 15, 2004 10:16 PM To: FlightGear developers discussions Subject: [Flightgear-devel] Problem with ballistic sub-model Hello all, I'm trying to use a ballistic sub-model to simulate a bomb but the parent a/c's speed and pitch etc. doesn't seem to be inherited i.e. the bomb appears to have no initial velocity and the pitch doesn't match that of the a/c. The sub-model.xml I'm using is below. Some of the settings are for de-bugging i.e. repeat, delay, count and buoyancy but I figure the important ones for a bomb would be speed and eda ?xml version=1.0? PropertyList submodel nameredbeard/name modelAircraft/EE-Canberra/Models/RedBeard.xml/model trigger/controls/armament/red-beard-released/trigger speed0.0/speed repeattrue/repeat delay1.0/delay count-1/count x-offset0.0/x-offset y-offset-0.0/y-offset z-offset0.0/z-offset yaw-offset0.0/yaw-offset pitch-offset0.0/pitch-offset eda0.0001/eda buoyancy30/buoyancy windfalse/wind /submodel /PropertyList LeeE I've been doing the same work for droptanks for the Hunter, with the same results. The ballistic submodel should inherit the parent velocities, and unless I've got a sign wrong somewhere (very possible), it does. On the other hand, the initial alignment of the submodel seems wrong. At the moment it aligns to the initial vector. This is a feature not a bug :-). The current module was designed for tracer and then extended to smoke, where it doesn't matter so much. I'll continue to investigate both issues today, but I can't promise instant results, as I think we may be hitting some fundamental design concepts rather than software bugs. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
Vivian Meazza wrote: Sent: Thursday, September 16, 2004 8:33 AM To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] Problem with ballistic sub-model Lee Elliott wrote: Sent: Wednesday, September 15, 2004 10:16 PM To: FlightGear developers discussions Subject: [Flightgear-devel] Problem with ballistic sub-model Hello all, I'm trying to use a ballistic sub-model to simulate a bomb but the parent a/c's speed and pitch etc. doesn't seem to be inherited i.e. the bomb appears to have no initial velocity and the pitch doesn't match that of the a/c. The sub-model.xml I'm using is below. Some of the settings are for de-bugging i.e. repeat, delay, count and buoyancy but I figure the important ones for a bomb would be speed and eda ?xml version=1.0? PropertyList submodel nameredbeard/name modelAircraft/EE-Canberra/Models/RedBeard.xml/model trigger/controls/armament/red-beard-released/trigger speed0.0/speed repeattrue/repeat delay1.0/delay count-1/count x-offset0.0/x-offset y-offset-0.0/y-offset z-offset0.0/z-offset yaw-offset0.0/yaw-offset pitch-offset0.0/pitch-offset eda0.0001/eda buoyancy30/buoyancy windfalse/wind /submodel /PropertyList LeeE I've been doing the same work for droptanks for the Hunter, with the same results. The ballistic submodel should inherit the parent velocities, and unless I've got a sign wrong somewhere (very possible), it does. On the other hand, the initial alignment of the submodel seems wrong. At the moment it aligns to the initial vector. This is a feature not a bug :-). The current module was designed for tracer and then extended to smoke, where it doesn't matter so much. I'll continue to investigate both issues today, but I can't promise instant results, as I think we may be hitting some fundamental design concepts rather than software bugs. I've checked and tested the submodel code. The submodel definitely inherits the parent velocities. Unfortunately, there's a basic snag: in order to get tracer to go in the right direction, I inserted a -ve rotation in pitch, but while making tracer correct, it applies an inverted pitch sense to droptanks/bombs. I don't understand why at this stage. Back to the drawing board! There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level :-). Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Thursday 16 September 2004 18:08, Vivian Meazza wrote: Vivian Meazza wrote: Sent: Thursday, September 16, 2004 8:33 AM To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] Problem with ballistic sub-model Lee Elliott wrote: Sent: Wednesday, September 15, 2004 10:16 PM To: FlightGear developers discussions Subject: [Flightgear-devel] Problem with ballistic sub-model Hello all, I'm trying to use a ballistic sub-model to simulate a bomb but the parent a/c's speed and pitch etc. doesn't seem to be inherited i.e. the bomb appears to have no initial velocity and the pitch doesn't match that of the a/c. The sub-model.xml I'm using is below. Some of the settings are for de-bugging i.e. repeat, delay, count and buoyancy but I figure the important ones for a bomb would be speed and eda ?xml version=1.0? PropertyList submodel nameredbeard/name modelAircraft/EE-Canberra/Models/RedBeard.xml/model trigger/controls/armament/red-beard-released/trigger speed0.0/speed repeattrue/repeat delay1.0/delay count-1/count x-offset0.0/x-offset y-offset-0.0/y-offset z-offset0.0/z-offset yaw-offset0.0/yaw-offset pitch-offset0.0/pitch-offset eda0.0001/eda buoyancy30/buoyancy windfalse/wind /submodel /PropertyList LeeE I've been doing the same work for droptanks for the Hunter, with the same results. The ballistic submodel should inherit the parent velocities, and unless I've got a sign wrong somewhere (very possible), it does. On the other hand, the initial alignment of the submodel seems wrong. At the moment it aligns to the initial vector. This is a feature not a bug :-). The current module was designed for tracer and then extended to smoke, where it doesn't matter so much. I'll continue to investigate both issues today, but I can't promise instant results, as I think we may be hitting some fundamental design concepts rather than software bugs. I've checked and tested the submodel code. The submodel definitely inherits the parent velocities. Unfortunately, there's a basic snag: in order to get tracer to go in the right direction, I inserted a -ve rotation in pitch, but while making tracer correct, it applies an inverted pitch sense to droptanks/bombs. I don't understand why at this stage. Back to the drawing board! There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level :-). Regards Vivian Thanks for the updates Vivian. I have complete confidence that you'll get it working;) I'll comment out the bomb release key-mapping for now, do some documentation and get an archive-package sorted out. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
They shouldn't inherit accelerations. Ampere On September 16, 2004 01:08 pm, Vivian Meazza wrote: There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level :-). Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Problem with ballistic sub-model
Hello all, I'm trying to use a ballistic sub-model to simulate a bomb but the parent a/c's speed and pitch etc. doesn't seem to be inherited i.e. the bomb appears to have no initial velocity and the pitch doesn't match that of the a/c. The sub-model.xml I'm using is below. Some of the settings are for de-bugging i.e. repeat, delay, count and buoyancy but I figure the important ones for a bomb would be speed and eda ?xml version=1.0? PropertyList submodel nameredbeard/name modelAircraft/EE-Canberra/Models/RedBeard.xml/model trigger/controls/armament/red-beard-released/trigger speed0.0/speed repeattrue/repeat delay1.0/delay count-1/count x-offset0.0/x-offset y-offset-0.0/y-offset z-offset0.0/z-offset yaw-offset0.0/yaw-offset pitch-offset0.0/pitch-offset eda0.0001/eda buoyancy30/buoyancy windfalse/wind /submodel /PropertyList LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with autogen in SuSe Linux Pro 9.1
On Friday 23 July 2004 06:12, Dave Perry wrote: The warnings are explained. by running info as documented and are not an issue. Questions 1. Has anyone had a similar problem with SuSe 9.1? Yes, i did with Slackware 10.0. 2. Any ideas how to get past this? To solve that error just delete your autom4te.cache folders in all your cvs trees (plib, simgear, flightgear-source etc.) and do a cvs update -Pd and ./autogen.sh again. This should solve the problem. The other error messages like underquoted definition of AM_PATH_GSL are just warning messages, you can ignore that, developers shouldn't. This is because automake 1.8,x handles macro definition files a lot stricter, that's the reason why these warning messages come up. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Problem with autogen in SuSe Linux Pro 9.1
Perhaps this has been discussed before, but I just updated my SuSe Linux to 9.1 pro and the various autogen scripts are not working right. The following errors occurred after updating plib from cvs and runing autogen: cvs update -dP dadsoffice:/usr/local/source/plib # sh autogen.sh Running aclocal /usr/share/aclocal/gsl.m4:5: warning: underquoted definition of AM_PATH_GSL run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal /usr/share/aclocal/avifile.m4:21: warning: underquoted definition of AM_PATH_AVIFILE Can't locate object method path via package Request at /usr/share/autoconf/Autom4te/C4che.pm line 69, GEN1 line 111. aclocal: autom4te failed with exit status: 1 Running automake Can't locate object method path via package Request at /usr/share/autoconf/Autom4te/C4che.pm line 69, GEN1 line 111. automake: autoconf failed with exit status: 1 Running autoconf Can't locate object method path via package Request at /usr/share/autoconf/Autom4te/C4che.pm line 69, GEN1 line 111. == Now you are ready to run './configure' == The warnings are explained. by running info as documented and are not an issue. Questions 1. Has anyone had a similar problem with SuSe 9.1? 2. Any ideas how to get past this? I have updated via YAST including the kernel to 2.6.5-7.95 and the results running autogen are the same. Thanks in advance for any help, Dave P. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] problem on exiting ( was: Next release of FlightGear )
Jonathan Polley wrote:
Fred,
It turns out that the problem should exist on every FlightGear
system, not just the Mac. On exit(), fgExitCleanup() is called which
deletes the globals class and then calls fgOSExit(). The only thing
that fgOSExit() does is turn around and call exit(), which repeats the
process. I changed fgExitCleanup() in main.cxx to be as follows:
void fgExitCleanup() {
delete globals;
//fgOSExit(0);
}
This prevented the recursive call to exit(), but will not work if
someone is using the fg_os_sld.cxx module, but it works for me.
I was suspecting that but was not able to reproduce this behavior on
windows.
What about this instead :
void fgExitCleanup() {
if ( globals ) {
delete globals;
globals = 0;
fgOSExit(0);
}
}
It will allow to call the function twice safely. Can you test that.
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] problem on exiting ( was: Next release ofFlightGear )
Frederic Bouvier wrote:
Jonathan Polley wrote:
Fred,
It turns out that the problem should exist on every FlightGear
system, not just the Mac. On exit(), fgExitCleanup() is called which
deletes the globals class and then calls fgOSExit(). The only thing
that fgOSExit() does is turn around and call exit(), which repeats the
process. I changed fgExitCleanup() in main.cxx to be as follows:
void fgExitCleanup() {
delete globals;
//fgOSExit(0);
}
This prevented the recursive call to exit(), but will not work if
someone is using the fg_os_sld.cxx module, but it works for me.
I was suspecting that but was not able to reproduce this behavior on
windows.
What about this instead :
void fgExitCleanup() {
if ( globals ) {
delete globals;
globals = 0;
fgOSExit(0);
}
}
It will allow to call the function twice safely. Can you test that.
And what about this that might be better.
-Fred
--- main.cxx 15 Jul 2004 18:07:03 - 1.170
+++ main.cxx 18 Jul 2004 12:38:52 -
@@ -1495,7 +1495,6 @@
// which happens in the sound manager destructor.
void fgExitCleanup() {
delete globals;
-fgOSExit(0);
}
--- util.cxx 16 Mar 2004 20:19:08 - 1.7
+++ util.cxx 18 Jul 2004 12:35:38 -
@@ -27,6 +27,7 @@
#include simgear/debug/logstream.hxx
+#include fg_os.hxx
#include fg_io.hxx
#include fg_props.hxx
#include globals.hxx
@@ -107,7 +108,7 @@
SG_LOG(SG_GENERAL, SG_INFO, Exiting FlightGear with status
status);
globals-get_io()-shutdown_all();
-exit(status);
+fgOSExit(status);
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] problem on exiting ( was: Next release ofFlightGear )
That patch worked just fine. Hopefully it can be rolled into CVS
before the release.
Thanks!
Jonathan Polley
On Jul 18, 2004, at 7:40 AM, Frederic Bouvier wrote:
Frederic Bouvier wrote:
Jonathan Polley wrote:
Fred,
It turns out that the problem should exist on every FlightGear
system, not just the Mac. On exit(), fgExitCleanup() is called which
deletes the globals class and then calls fgOSExit(). The only thing
that fgOSExit() does is turn around and call exit(), which repeats
the
process. I changed fgExitCleanup() in main.cxx to be as follows:
void fgExitCleanup() {
delete globals;
//fgOSExit(0);
}
This prevented the recursive call to exit(), but will not work if
someone is using the fg_os_sld.cxx module, but it works for me.
I was suspecting that but was not able to reproduce this behavior on
windows.
What about this instead :
void fgExitCleanup() {
if ( globals ) {
delete globals;
globals = 0;
fgOSExit(0);
}
}
It will allow to call the function twice safely. Can you test that.
And what about this that might be better.
-Fred
--- main.cxx 15 Jul 2004 18:07:03 - 1.170
+++ main.cxx 18 Jul 2004 12:38:52 -
@@ -1495,7 +1495,6 @@
// which happens in the sound manager destructor.
void fgExitCleanup() {
delete globals;
-fgOSExit(0);
}
--- util.cxx 16 Mar 2004 20:19:08 - 1.7
+++ util.cxx 18 Jul 2004 12:35:38 -
@@ -27,6 +27,7 @@
#include simgear/debug/logstream.hxx
+#include fg_os.hxx
#include fg_io.hxx
#include fg_props.hxx
#include globals.hxx
@@ -107,7 +108,7 @@
SG_LOG(SG_GENERAL, SG_INFO, Exiting FlightGear with status
status);
globals-get_io()-shutdown_all();
-exit(status);
+fgOSExit(status);
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Problem with game menu when switching to wireframe mode
Hello, today i played around with the wireframe mode which can be activated in-game by starting flightgear with the option --enable-wireframe or by setting in the property menu /sim/rendering/wireframe to true. But when i do this the in-game menu gets useless because the fonts used in the in game menu get scarcely visible. To solve that, the in-game menu and its fonts shouldn't be affected by setting the wireframe mode to true. Can someone fix this? Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] problem with SGLookupFunction (patch included)
Erik Hofman wrote: Andy Ross wrote: Seriously: consider the case where this symbol came out of a library that we *don't* link to statically. Why would I? Then this would undeniably be a bug, because the library would be unmapped before the function could be called. Honestly, this code is just wrong. No it's not. I can't see a case where a program that relies so heavily on OpenGL wouldn't link to the GL library at link time. Let's turn this around: what do you *want* the dlclose() invocation to do for you? Its documented behavior is to close and invalidate the shared library mapping if it is currently unused. Since you are caching and returning a pointer to a function in the library, this cannot possibly be what you want. Why is the line there if we all agree it is a no-op? Occam's razor demands that you take it out. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] problem with SGLookupFunction (patch included)
Andy Ross wrote: Erik Hofman wrote: Unfortunately RTLD_DEFAULT isn't supported on all platforms (it isn't supported in IRIX anyhow). I think that if what you describe is the problem this really is a bug at your side. What happens is that the function pointer is copied to ftpr. So dlcose() should never be able to have any effects on this copy ?? I think the idea here is that dlclose() is unmapping the memory region associated with the shared library. The pointer still has the same value, but there are no page table entries associated with that address any more, so an instruction fetch from that address causes a segmentation fault. Yes there should be, dlopen/dlclose keep a counter for the number of dlopen *and dlclose calls and only removed the library when the number of dlclose calls equals the number of dlopen calls. Since FlightGear is linked to libGL at link time, the number of dlclose calls would always be one less than the number of dlopen calls. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] problem with SGLookupFunction (patch included)
Erik Hofman wrote: Since FlightGear is linked to libGL at link time, the number of dlclose calls would always be one less than the number of dlopen calls. In which case the dlclose() is 100% guaranteed to be a noop anyway and can be safely removed. :) Seriously: consider the case where this symbol came out of a library that we *don't* link to statically. Then this would undeniably be a bug, because the library would be unmapped before the function could be called. Honestly, this code is just wrong. You don't close the library before calling functions in it, you just don't. Yes, the POSIX docs for dlclose() seem to imply that it should be safe as long as something else has a handle to libGL, but it's still not correct. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] problem with SGLookupFunction (patch included)
Alex Romosan wrote: trying to debug why i wasn't able to run flightgear on my laptop, i think i found a problem with SGLookupFunction. the problem is that we call dlclose() before we return the pointer to the GL function, and, if i understand things correctly, this invalidates the handle and the address might not be valid anymore (on my laptop i kept getting core dumps). anyway the fix is very simple: instead of calling dlopen() on libGL and then passing the libGL handle to dlsym() one can simply invoke dlsym on RTLD_DEFAULT (which is a special pseudo-handler that will find the first occurrence of the desired symbol using the default library search order). now i can run flightgear on both my laptop (with a radeon mobility card) and on my desktop (nvidia card) and i think the clouds actually look much better. Unfortunately RTLD_DEFAULT isn't supported on all platforms (it isn't supported in IRIX anyhow). I think that if what you describe is the problem this really is a bug at your side. What happens is that the function pointer is copied to ftpr. So dlcose() should never be able to have any effects on this copy ?? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] problem with SGLookupFunction (patch included)
Erik Hofman wrote: Alex Romosan wrote: trying to debug why i wasn't able to run flightgear on my laptop, i think i found a problem with SGLookupFunction. the problem is that we call dlclose() before we return the pointer to the GL function, and, if i understand things correctly, this invalidates the handle and the address might not be valid anymore (on my laptop i kept getting core dumps). anyway the fix is very simple: instead of calling dlopen() on libGL and then passing the libGL handle to dlsym() one can simply invoke dlsym on RTLD_DEFAULT (which is a special pseudo-handler that will find the first occurrence of the desired symbol using the default library search order). now i can run flightgear on both my laptop (with a radeon mobility card) and on my desktop (nvidia card) and i think the clouds actually look much better. Unfortunately RTLD_DEFAULT isn't supported on all platforms (it isn't supported in IRIX anyhow). I think that if what you describe is the problem this really is a bug at your side. What happens is that the function pointer is copied to ftpr. So dlcose() should never be able to have any effects on this copy ?? I checked the manual page for dlclose on Linux and Tru64 ( ex Digital Unix ) On Linux, it seems dlclose decrement a counter and the library is unloaded when it comes to zero. As libGL.so is already loaded by the linker, it should stay linked, except perhaps if the static link was made with libGL.a. OTOH, on Tru64, the man page says : The dlclose function deallocates the address space for the library corresponding to handle. The results are undefined if any user function continues to call a symbol resolved in the address space of a library that has since been deallocated by dlclose. So, if the library is really unloaded, the pointer access should be really undefined and could lead to a segfault. Anyway, is it really mandatory to do dlclose after getting the pointer ? It is if we do dlopen every time we get a pointer, but the handle could be allocated only once and stored for subsequent lookup. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] problem with SGLookupFunction (patch included)
Erik Hofman wrote: Unfortunately RTLD_DEFAULT isn't supported on all platforms (it isn't supported in IRIX anyhow). I think that if what you describe is the problem this really is a bug at your side. What happens is that the function pointer is copied to ftpr. So dlcose() should never be able to have any effects on this copy ?? I think the idea here is that dlclose() is unmapping the memory region associated with the shared library. The pointer still has the same value, but there are no page table entries associated with that address any more, so an instruction fetch from that address causes a segmentation fault. The meaning of dlclose() is I don't need this library any more, not please close the handle, I have what I need. Alex is right, this is a bug, even if it doesn't cause crashes up on all platforms. We clearly don't want to unload the OpenGL library. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] problem with SGLookupFunction (patch included)
trying to debug why i wasn't able to run flightgear on my laptop, i think i found a problem with SGLookupFunction. the problem is that we call dlclose() before we return the pointer to the GL function, and, if i understand things correctly, this invalidates the handle and the address might not be valid anymore (on my laptop i kept getting core dumps). anyway the fix is very simple: instead of calling dlopen() on libGL and then passing the libGL handle to dlsym() one can simply invoke dlsym on RTLD_DEFAULT (which is a special pseudo-handler that will find the first occurrence of the desired symbol using the default library search order). now i can run flightgear on both my laptop (with a radeon mobility card) and on my desktop (nvidia card) and i think the clouds actually look much better. this is the patch: RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/screen/extensions.hxx,v retrieving revision 1.13 diff -u -r1.13 extensions.hxx --- simgear/screen/extensions.hxx 21 May 2004 14:50:49 - 1.13 +++ simgear/screen/extensions.hxx 23 Jun 2004 01:08:01 - @@ -69,12 +69,7 @@ // GLX extension is *not* guaranteed to be supported. An alternative // dlsym-based approach will be used instead. -void *libHandle; -void (*fptr)(); -libHandle = dlopen(libGL.so, RTLD_LAZY); -fptr = (void (*)()) dlsym(libHandle, func); -dlclose(libHandle); -return fptr; +return (void (*)()) dlsym(RTLD_DEFAULT, func); #endif } --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problem with FG_ROOT in runfgfs.bat under cygwinbuild
Innis,
Thanks for your .BAT file - it works!
So FG_ROOT needs to be set to \DATA ... that was the problem...I wonder if
this should be reflected in the documentation on building flightgear section
4.2?
-
SET FG_ROOT=c:\FlightGear\DATA
and invoke FlightGear (within the same Command shell, as environment
settings are only valid locally within the same shell) via
fgfs --option1 --option2
...Of course, you can create your own runfgfs.bat with Windows Editor using
the two lines above.
--
Martin/David thanks for your replies,
Neil.
-Original Message-
From: Innis Cunningham [mailto:[EMAIL PROTECTED]
Sent: 01 April 2004 03:04
To: [EMAIL PROTECTED]
Subject: RE: [Flightgear-devel] Problem with FG_ROOT in runfgfs.bat
under cygwinbuild
Hi Neil
See below is my .bat file that I run from
the Flightgear folder under Cygwin
REM @ECHO OFF
REM Skip ahead to CONT1 if FG_ROOT has a value
IF NOT %FG_ROOT%.==. GOTO CONT1
SET TOP_ROOT=.
SET FG_ROOT=%TOP_ROOT%\DATA
:CONT1
REM Check for the existance of the executable
IF NOT EXIST %TOP_ROOT%\BIN\FGFS.EXE GOTO ERROR1
REM Now that FG_ROOT has been set, run the program
ECHO FG_ROOT = %FG_ROOT%
%TOP_ROOT%\BIN\FGFS.EXE
GOTO END
:ERROR1
ECHO Cannot find %TOP_ROOT%\BIN\FGFS.EXE
GOTO END
:END
HTH
Cheers
Innis
_
We've 100s of NEW questions! Play Millionaire online to win . Click here
http://sites.ninemsn.com.au/minisite/millionaire/default.asp
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Problem with FG_ROOT in runfgfs.bat under cygwin build
Hi, This is my first post so I apologise for it being trivial, I've built FlightGear under windows xp/cygwin following all the instructions in the manual (apart from building metakit which is not in the source files??). It compiles but a runfgfs.bat file wasn't produced. No problem - I created one with the two lines: SET FG_ROOT=c:\cygwin\usr\local\FlightGear %FG_ROOT%\BIN\FGFS.EXE but when I come to run it I get the following error: - C:\cygwin\usr\local\FlightGearSET FG_ROOT=c:\cygwin\usr\local\FlightGear C:\cygwin\usr\local\FlightGearc:\cygwin\usr\local\FlightGear\BIN\FGFS.EXE WARNING: ssgLoadAC: Failed to open './c:/cygwin/usr/local/FlightGear/data/Aircra ft/c172p/Models/c172p.ac' for reading Failed to load aircraft from Aircraft/c172p/Models/c172p.xml (Falling back to glider.ac.) WARNING: ssgLoadAC: Failed to open './c:/cygwin/usr/local/FlightGear/data/Models /Geometry/glider.ac' for reading Fatal error: Failed to load 3D model (received from ) C:\cygwin\usr\local\FlightGearpause Press any key to continue . . . So it looks like flightgear looks for the data path as ./c/ when trying to use the environment variable FG_ROOT. Which isn't a recongised windows path Any suggestions? Oh, I've tried a VS .NET build but no luck so farbut first things first ;-)! Neil. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem with FG_ROOT in runfgfs.bat under cygwin
Cooke N. wrote: So it looks like flightgear looks for the data path as ./c/ when trying to use the environment variable FG_ROOT. Which isn't a recongised windows path The problem sounds familiar - it hast been discussed on the PLIB mailing list last week. I didn't find any message that made notice of a solution ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem with FG_ROOT in runfgfs.bat under cygwin build
Cooke N. [EMAIL PROTECTED] writes: Hi, This is my first post so I apologise for it being trivial, Not being able to run FlightGear ain't trivial ;-) I've built FlightGear under windows xp/cygwin following all the instructions in the manual (apart from building metakit which is not in the source files??). It compiles but a runfgfs.bat file wasn't produced. No problem - I created one with the two lines: SET FG_ROOT=c:\cygwin\usr\local\FlightGear %FG_ROOT%\BIN\FGFS.EXE Just a shot in the dark, but you could try SET FG_ROOT=/cygdrive/c/cygwin/usr/local/FlightGear etc. Are you executing runfgfs.bat from a windows command prompt or from Cygwin's bash shell BTW. FWIW, I have export FG_ROOT=/cvs_clean/data in my .profile (a hidden file in the cygwin home directory) and just run bin/fgfs from a bash prompt after changing to the right directory. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problem with FG_ROOT in runfgfs.bat under cygwinbuild
Hi Neil See below is my .bat file that I run from the Flightgear folder under Cygwin REM @ECHO OFF REM Skip ahead to CONT1 if FG_ROOT has a value IF NOT %FG_ROOT%.==. GOTO CONT1 SET TOP_ROOT=. SET FG_ROOT=%TOP_ROOT%\DATA :CONT1 REM Check for the existance of the executable IF NOT EXIST %TOP_ROOT%\BIN\FGFS.EXE GOTO ERROR1 REM Now that FG_ROOT has been set, run the program ECHO FG_ROOT = %FG_ROOT% %TOP_ROOT%\BIN\FGFS.EXE GOTO END :ERROR1 ECHO Cannot find %TOP_ROOT%\BIN\FGFS.EXE GOTO END :END HTH Cheers Innis _ We've 100s of NEW questions! Play Millionaire online to win . Click here http://sites.ninemsn.com.au/minisite/millionaire/default.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem compiling latest jsbsim
Frederic Bouvier wrote: Hi, I have problems compiling today's JSBsim with MSVC. I had to patch the sources like this : ; - SG_USING_STD(sqrt); +// SG_USING_STD(sqrt); because sqrt is not a member of std:: Is this declaration really necessary ? I see that math.h is included 11 lines before and it should declare sqrt in the global namespace, not in the std namespace, so why a 'using std::sqrt;' here ? Is it required for cygwin or linux or another unix ? Actually I have no idea how math.h could define something in namespace std since it is a C header file. Maybe most unices put C definitions in namespace std by default, but they *must* be available outside of the std namespace also (IMHO). Committed. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Problem compiling latest jsbsim
Hi, I have problems compiling today's JSBsim with MSVC. I had to patch the sources like this : Index: FGColumnVector3.h === RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/FDM/JSBSim/FGColumnVector3.h,v retrieving revision 1.6 diff -u -r1.6 FGColumnVector3.h --- a/FGColumnVector3.h 14 Mar 2004 14:57:07 - 1.6 +++ b/FGColumnVector3.h 14 Mar 2004 22:17:22 - @@ -33,7 +33,7 @@ SG_USING_STD(cerr); SG_USING_STD(cout); SG_USING_STD(endl); - SG_USING_STD(sqrt); +// SG_USING_STD(sqrt); #else # include string # if defined(sgi) !defined(__GNUC__) (_COMPILER_VERSION 740) Index: FGColumnVector4.h === RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/FDM/JSBSim/FGColumnVector4.h,v retrieving revision 1.6 diff -u -r1.6 FGColumnVector4.h --- a/FGColumnVector4.h 14 Mar 2004 14:57:07 - 1.6 +++ b/FGColumnVector4.h 14 Mar 2004 22:19:05 - @@ -31,7 +31,7 @@ SG_USING_STD(cerr); SG_USING_STD(cout); SG_USING_STD(endl); - SG_USING_STD(sqrt); +// SG_USING_STD(sqrt); #else # include string # if defined (sgi) !defined(__GNUC__) (_COMPILER_VERSION 740) because sqrt is not a member of std:: Is this declaration really necessary ? I see that math.h is included 11 lines before and it should declare sqrt in the global namespace, not in the std namespace, so why a 'using std::sqrt;' here ? Is it required for cygwin or linux or another unix ? Thanks, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Problem with PA28-161 textures
Hi, David forgot to mark the .rgb files binary, so they are corrupted under windows. And the model is included by default by the AIMgr. Could someone add the binary tag to the .rgb files in Aircraft/pa28-61/Models Thanks, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem with PA28-161 textures
Frederic Bouvier wrote: Hi, David forgot to mark the .rgb files binary, so they are corrupted under windows. And the model is included by default by the AIMgr. Could someone add the binary tag to the .rgb files in Aircraft/pa28-61/Models Done. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Problem with derivative?
It appears that the derivative time value is performing opposite of what is exepcted. Increasing value seems to increase overshoot. Rather than hitting zero beneath the target (and applying the brakes so to speak), it hits zero after passing the target causing overshoot. This situation gets worse with increased values in Td. Decreasing the value to near zero just reduces the effect, it does not invert at any point. Is this a bug or do I just have something badly screwed up? Maybe this is why the ALT HLD started behaving better after making the derivative miniscule. Kp is a negative number on these heading controllers but a quick glance at the formula tells me that this probably isn't the issue. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem JSB FDM's
Jon Berndt wrote: I just built 0.9.3 and downloaded the 0.9.3 base package. The T-38 pulled left until I reset *both* the surface winds and the 500-foot winds to zero. Now it goes straight as an arrow. So, this says there is a problem with winds as added to JSBSim aero? If this is correct: Innis Cunningham wrote: The thing is that while trying to fix this problem I found that the F16 did not seem to be affected by the wind Then it's probably a aeromatic problem since the F-16 is created using NASA windtunnel data. This copes with what I wrote about JSBSim not turning when on the runway, that was with both fokker aircrafts. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem JSB FDM's
Jon Berndt wrote: Hi Folks After getting 9.3 going I find that the JSB A/C turn left off the runway going north and right going south is anyone else seeing this problem. It does not seem to effect the YASIM A/C. The 747 and F16(YASIM) take off straight and the T38 and 737 (JSBSIM)turn off the runway. YASim F-16??? I think this has been discussed in the Users mailing list - about 10/27, I think. You may be seeing an initialization problem. ?? Try centering all the aero surfaces immediately upon coming out of freeze. Also, maybe try an external view and see if the gear is turned. Also, try starting FlightGear with NO wind. I noticed that a ground turn in a JSBSim is next to impossible. The aircraft keeps going straight ahead, just as if there is no friction for tires moving sideways. I don't know if this is a recent problem, or this problem has been there for a while but I just recently noticed this. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem JSB FDM's
Erik Hofman The 747 and F16(YASIM) take off straight and the T38 and 737 (JSBSIM)turn off the runway. YASim F-16??? Sorry Erik dont know what I was looking at.Yes the F16 is JSB I noticed that a ground turn in a JSBSim is next to impossible. The aircraft keeps going straight ahead, just as if there is no friction for tires moving sideways. Are you saying that your JSB A/C are going straight on T/O. What A/C are you using. I don't know if this is a recent problem, or this problem has been there for a while but I just recently noticed this. I was not having this problem with 9.2 and as I dont continually update with cvs all I can say is it was not there in 9.2 but it is in 9.3 I will do some investigating tonight and see if I can come up with something.It just seems strange that no one else is see this problem. Either they are not flying the jets or they are only using yasim fdm's Erik Cheers Innis The Mad Aussi _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problem JSB FDM's
Jon Berndt writes I think this has been discussed in the Users mailing list - about 10/27, I think. Yes it was but the results were inconclusive . ?? Try centering all the aero surfaces immediately upon coming out of freeze They are centered.I have done nothing different to the A/C since 9.2 but now they wont go straight Also, maybe try an external view and see if the gear is turned. Also, try starting FlightGear with NO wind. Have done all this still the A/C goes right heading south and left heading north EG: at KSFO off 28L the A/c goes left and right off 10R If you were having this problem with the prop aircraft I'd say that you should expect the aircraft to fly that way, but this doesn't appear to be the case. I have not had time to update to the latest, yet. I guess I need to. I will have a play around with the yaw damper system as David Culp thinks the problem may be in there. Just how many of the real A/C have yaw damper.I is my understanding that it is only on sweept wing A/C to negate the onset of Dutch roll. Do A/C like the F16 and T38 have a yaw damper system. Jon Cheers Innis The Mad Aussi _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problem JSB FDM's
Do A/C like the F16 and T38 have a yaw damper system. The F-16 FCS has a LOT of things, including gun firing compensation! Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem JSB FDM's
Innis Cunningham wrote: I noticed that a ground turn in a JSBSim is next to impossible. The aircraft keeps going straight ahead, just as if there is no friction for tires moving sideways. Are you saying that your JSB A/C are going straight on T/O. What A/C are you using. What I meant to say is that while taxiing the aircraft won't turn, in any direction. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem JSB FDM's
I just built 0.9.3 and downloaded the 0.9.3 base package. The T-38 pulled left until I reset *both* the surface winds and the 500-foot winds to zero. Now it goes straight as an arrow. Dave David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem JSB FDM's
Ok David that seems to have fixed it for me to. The thing is that while trying to fix this problem I found that the F16 did not seem to be affected by the wind and I could get the 737 to t/o straight by changing the yaw beta but not the T38. Surely a 3 knot wind out of 270 would not cause that kind of swing taking off on 28L. While I have you does the (real)T38 have a yaw damper system. Cheers Innis The Mad Aussi David Culp writes I just built 0.9.3 and downloaded the 0.9.3 base package. The T-38 pulled left until I reset *both* the surface winds and the 500-foot winds to zero. Now it goes straight as an arrow. Dave _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problem JSB FDM's
I just built 0.9.3 and downloaded the 0.9.3 base package. The T-38 pulled left until I reset *both* the surface winds and the 500-foot winds to zero. Now it goes straight as an arrow. So, this says there is a problem with winds as added to JSBSim aero? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Problem JSB FDM's
Hi Folks After getting 9.3 going I find that the JSB A/C turn left off the runway going north and right going south is anyone else seeing this problem.It does not seem to effect the YASIM A/C. The 747 and F16(YASIM) take off straight and the T38 and 737 (JSBSIM)turn off the runway. Cheers Innis The Mad Aussi _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Problem with new JSBSim code
Hi, I made a CVS update and now, with the A320, I am not able to increase power to take of. The engines are desesperately at the idle power ( N1=30 N2=60 ) while moving my joystick throttle. This is with a modified -set file where I implemented the starting sequence ( engines not running at startup ). Any idea ? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem with new JSBSim code
Frederic Bouvier wrote: Hi, I made a CVS update and now, with the A320, I am not able to increase power to take of. The engines are desesperately at the idle power ( N1=30 N2=60 ) while moving my joystick throttle. This is with a modified -set file where I implemented the starting sequence ( engines not running at startup ). Any idea ? Forget this one. Just retried and it works now. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem for compiling and installing theSimgear-0.3.3 package
Hello Dai This is an old problem that has haunted FG for the best part of two years if you care to read back through the archives. Anyway before you run configure you need to write this line. export LDFLAGS=-L/usr/local/lib ./configure for both simgear and flightgear. The simple and easy way would be to download one of the two Win32 binaries that are produced by Norman Vine or Fredric Bouvier. HTH Cheers Innis Dai, Chengbi writes I try to compile the source code of flightgear-0.9.2 with Cygwin compiler. I have installed the cygin with version 2.249.2.5 on my windows 2000 computer. I installed the plib-1.6.0, zlib-1.1.4 and metakit-2.4.9.2 packages. When I try to install the Simgear-0.3.3 package, I get the following error. checking mk4.h... yes checking for metakit 2.4.3 or newer... wrong version configure error: Install metakit 2.4.3 or later first. Or, the compiler may not be finding your libmk4.so library. Please check the config.log file for specific details of the failure if you believe you have the correct metakit version. Also, look up this issue in the FlightGear FAQ. Can someone give me the suggestion for fixing this problem? Thanks for help Chengbi Dai ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ Hotmail is now available on Australian mobile phones. Go to http://ninemsn.com.au/mobilecentral/signup.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem for compiling and installing theSimgear-0.3.3 package
Yep... The 'ole export LDFLAGS deal That has caught me a few times until I learned to remember it ;) WillyB On Monday 14 July 2003 08:15, Innis Cunningham wrote: Hello Dai This is an old problem that has haunted FG for the best part of two years if you care to read back through the archives. Anyway before you run configure you need to write this line. export LDFLAGS=-L/usr/local/lib ./configure for both simgear and flightgear. The simple and easy way would be to download one of the two Win32 binaries that are produced by Norman Vine or Fredric Bouvier. HTH Cheers Innis Dai, Chengbi writes I try to compile the source code of flightgear-0.9.2 with Cygwin compiler. I have installed the cygin with version 2.249.2.5 on my windows 2000 computer. I installed the plib-1.6.0, zlib-1.1.4 and metakit-2.4.9.2 packages. When I try to install the Simgear-0.3.3 package, I get the following error. checking mk4.h... yes checking for metakit 2.4.3 or newer... wrong version configure error: Install metakit 2.4.3 or later first. Or, the compiler may not be finding your libmk4.so library. Please check the config.log file for specific details of the failure if you believe you have the correct metakit version. Also, look up this issue in the FlightGear FAQ. Can someone give me the suggestion for fixing this problem? Thanks for help Chengbi Dai ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ Hotmail is now available on Australian mobile phones. Go to http://ninemsn.com.au/mobilecentral/signup.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Problem to compile the flightgear-0.9.2 with Cygwin
Title: Problem to compile the flightgear-0.9.2 with Cygwin Hi I try to compile the source code of flightgear-0.9.2 with Cygwin compiler. I have installed the cygin with version 2.249.2.5 on my windows 2000 computer. I installed the plib-1.6.0, zlib-1.1.4 and metakit-2.4.9.2 packages. However, I still get the following error when I try to run the CONFIGURE OF the Simgear-0.3.3 package. checking mk4.h... yes checking for metakit 2.4.3 or newer... wrong version configure error: Install metakit 2.4.3 or later first. Or, the compiler may not be finding your libmk4.so library. Please check the config.log file for specific details of the failure if you believe you have the correct metakit version. Also, look up this issue in the FlightGear FAQ. Can someone give me the suggestion for fixing this problem? Thanks for help!!! Chengbi Dai ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Problem for compiling and installing the Simgear-0.3.3 package
Title: Problem for compiling and installing the Simgear-0.3.3 package Hi I try to compile the source code of flightgear-0.9.2 with Cygwin compiler. I have installed the cygin with version 2.249.2.5 on my windows 2000 computer. I installed the plib-1.6.0, zlib-1.1.4 and metakit-2.4.9.2 packages. When I try to install the Simgear-0.3.3 package, I get the following error. checking mk4.h... yes checking for metakit 2.4.3 or newer... wrong version configure error: Install metakit 2.4.3 or later first. Or, the compiler may not be finding your libmk4.so library. Please check the config.log file for specific details of the failure if you believe you have the correct metakit version. Also, look up this issue in the FlightGear FAQ. Can someone give me the suggestion for fixing this problem? Thanks for help Chengbi Dai ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] problem with a10cl-yasim -- elevator trim error at start
I get the following with --aircraft=a10cl-yasim (a10wl-yasim works fine), YASim SOLUTION FAILURE: Insufficient elevator to trim for approach leave NewTgtAirportInit() I am using base package, flightgear and simgear from about 12 noon gmt Other aircraft (checked 747, a4, sopwithCamel) seem to be ok. Changing altitude doesn't have any effect, the problem still occurs Any ideas why this is suddently appearing? I am using keyboard only, no rudder pedals or joystick. Mac OS X 10.2.4 The plane worked fine a few days ago. Any yasim gurus know how to debug this? Thanks! Ima ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] problem with a10cl-yasim -- elevator trim error at start
Ima Sudonim writes: YASim SOLUTION FAILURE: Insufficient elevator to trim for approach leave NewTgtAirportInit() Any ideas why this is suddently appearing? I am using keyboard only, no rudder pedals or joystick. Mac OS X 10.2.4 The plane worked fine a few days ago. Any yasim gurus know how to debug this? When Erik renamed the properties a few days ago, he accidentally typed /controls/light/elevator-trim instead of /controls/flight/elevator-trim in one spot. I've fixed it, and I'll check in the change (it's only fair, since Erik fixed a problem of mine earlier today). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] problem with a10cl-yasim -- elevator trim error at start
David, thanks, that fixed it! The a10's a great plane, big engines with a lot of power when not loaded, a good trainer for those of us who don't know what their doing. 8-) The model might not be realistic (I wouldn't know 8-)), but it's fun. Good to have it back! Ima ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
