Re: [Flightgear-devel] 2.6.0 for Mac - call for detail bug info known issues
Hi, So this could be ATI specific problem. I got a report about similar problem with MBP/Radeon X1600 on RC2. I have a dying MBP that has X1600. Unfortumately it has 10.5 so I haven't tried a Cocoa version. I'll Check on this later. Btw, why don't we make a universal binary with i386/Carbon and x86_64/Cocoa? Using arch command can pick one from two versions at launch time, so those who have this issue can stay with Carbon version while others can take advantage of cocoa/64bit. If I make i386 version compatible with 10.5, I can save much time for support. Tat --- Tatsuhiro Nishioka @ iPhone On 2012/02/22, at 7:09, HB-GRAL flightg...@sablonier.ch wrote: Hi Olaf This is a flightgear/osg/cocoa issue I can reproduce with release/2.6.0 on OSX 10.6.8. No MacBook graphics, but almost ... - ATI 5750. I am wondering a bit that this doesn’t happen with nVidia/10.7.2 Cheers, Yves Am 21.02.12 22:19, schrieb Olaf Flebbe: Hi Yves, Can you please more specific? Which download, Macbook, graphics, macosx, steps to reproduce? Thanks, Olaf Am 21.02.2012 um 09:43 schrieb flightg...@sablonier.ch: (and I also want someone to give me a Mac that reproduces #7 :-p). Here. Cheers, Yves -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] New package of 2.6.0 for Mac
Dear Mac users, Thanks to your help, I made a new package that solves many problems that are reported so far. I recommend all mac/fg users apply the new package - for speed and stability. Please go visit the site below for detail explanation and download: http://macflightgear.sourceforge.net/flightgear-260-for-mac-now-supports-many-of-your-wishes Good night, Tat -- Tatsuhiro Nishioka http://macflightgear.sourceforge.net/ -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.6.0 for Mac - call for detail bug info known issues
Olaf, James told me you two are talking about osgViewer issues. I'm using OSG trunk as of rev 12982 with my own patch that fixes crashes and wrong key mappings, etc... Could you tell me more detail about the important patches?. I want to know if i am missing some of these. (and I also want someone to give me a Mac that reproduces #7 :-p). Anyway, I think we need to talk to OSG/Mac developers on cocoa powered osgViewer. It needs some surgery. Tat --- Tatsuhiro Nishioka @ iPhone On 2012/02/21, at 5:54, Olaf Flebbe o...@oflebbe.de wrote: Hi Tat, Indeed I have problems with almost all kind of intel graphics chips on windows, mac and linux. Most of them are shader specific artifacts, only chance is to disable shaders completly. Looks like your #5 problem. AFAII (as far as i investigated) these seem to be driver specific defects, both present on windows and mac. #7: Do you use current OSG trunk? There are important patches not present in past OSG releases. My machine: OSX 10.7, cocoa 64bit, 2011 model (HD3000 sandy bridge). Olaf Flebbe Am 20.02.2012 um 06:52 schrieb Tatsuhiro Nishioka: Dear Mac users / developers First, I've heard some users complaining 2.6 for Mac doesn't work, in facebook, or via email without detail info. Could you help me collect what is the cause of this issue? I want to know the following things for reproducing the problem: - Mac model and OS version (e.g. MacBookPro 15/nVidia GT330M/OS X 10.7.2) - FG version and revision (e.g. 2.6.0 r314M) - Command-line option (you can get this from Console.app. it looks like 2/20/12 1:16:59.744 PM [0x0-0x4a04a0].net.sourceforge.macflightgear: Starting fgfs.sh with --aircraft=A6M2-jsbsim --browser-app=open --prop:/sim/rendering/multi-sample-buffers=true --prop:/sim/rendering/multi-samples=2 - Crash dump (if available). As I want to release the updater for fixing common issues in 2.6 ASAP, I want to have many info until the end of this week. Second, I want to share with you the known issues on FG 2.6.0 for mac that I've collected so far. #1) fgfs crashes with CitationX, 777-200ER, and any other Aircraft that add menu items. If an aircraft has Nasal/dialog.nas, it likely crashes when initializing subsystems. This is caused by my bad patch and is mac specific bug. :-( -- Fixed #2) fgfs cannot handle --browser-app=open properly. Somehow preferences.xml overwrites the command-line option. -- Workaround made (patch for preferences.xml), Code level fix is needed. #3) Random Vegetations give us the white squares instead of trees. (only on package for 10.5). -- under investigation. #4) 3D clouds don't show up (only on package for 10.5). -- under investigation. #5) Some aircraft's texture look broken with some integrated graphics chips (shutter-like or patch-work-ish). -- bad GPU OpenGL driver? (e.g. Intel HD Graphics), mainly happens with png textures, I guess. Changing png to rgb seems fixing this issue. it doesn't happen when using nVidia GT330M. #6) integrated graphic chip (e.g. Intel HD Graphics) crashes fgfs during startup (some can survive with cockpit view) -- bad GPU OpenGL driver, I guess ( see the dump below) Thread 3 Crashed: 0 com.apple.driver.AppleIntelHDGraphicsGLDriver0x05120480 glrReturnUnexpectedKillClient + 15 1 com.apple.driver.AppleIntelHDGraphicsGLDriver0x0500d2c7 GhalInterface::getCommandBuffer(unsigned char**, unsigned char**, unsigned int*, unsigned int*) + 203 2 com.apple.driver.AppleIntelHDGraphicsGLDriver0x050af495 GHAL3D::CPrivateCommandTransport::FlushCommandBuffer(GHAL3D::FLUSH_TYPE, unsigned char) + 341 3 com.apple.driver.AppleIntelHDGraphicsGLDriver0x050af217 g575SubmitPacketsToken + 51 4 com.apple.driver.AppleIntelHDGraphicsGLDriver0x051302e7 _ZL28GetNewVertexBufferFromKernelP17DataBufferManagerP13GLDContextRecm + 79 5 com.apple.driver.AppleIntelHDGraphicsGLDriver0x051305b7 g575GetVertexBuffer + 243 6 com.apple.driver.AppleIntelHDGraphicsGLDriver0x050af17a g575PrefetchPrimitiveBuffer + 49 7 com.apple.driver.AppleIntelHDGraphicsGLDriver0x050af05c glrBeginPrimitiveBufferUseDataBuffer + 171 8 GLEngine 0x04f85225 gleFlushPrimitiveTCLFunc + 652 9 GLEngine 0x04f0064e gleDrawArraysOrElements_ListExecCore + 199 10 GLEngine 0x04ea1fd3 gleDrawArraysOrElementsOutOfLine_ListExec + 1074 11 GLEngine 0x04e9f1ad gleCallList + 125 12 libGL.dylib 0x92baf188 glCallList + 27 13 fgfs 0x0043f2f6 osg::Drawable::draw(osg::RenderInfo) const + 202 This doesn't happen on major nVidia (e.g. GT330M) and some other AMD discrete chips so far. #7) Cocoa-osgviewer doesn't work properly on some Macs (2.6.0-RC2). Image inside window gets broken when resizing or when
Re: [Flightgear-devel] FlightGear 2.6.0 for Mac OS X.
Hi Yves, Though I haven't check the source code deeply, fgfs doesn't seem handling --browser-app command-line option properly. According to the code, its default value for OS X is set to open, and command-line option seems to be set properly. So I guess the property node (/sim/startup/browser-app) is overwritten by the one in preferences.xml. As a matter of fact, changing line 62 of preferences.xml to the following will fix the issue. browser-app write=nopen %u/browser-app It doesn't seem OS X specific, so this may happen on Windows as well. Maybe we should ask some windows users if it works properly (and if preferences.xml is modified) Hope this helps, Tat On Feb 20, 2012, at 1:05 AM, HB-GRAL wrote: Hi Tat I downloaded 10.6/7 version and it works fine. Just one small thing I noted (because I am on this myself at the moment for FGx): GUI-Help (opens in Browser) doesn’t open anything here. But maybe this is not OSX only? Cheers, Yves Am 19.02.12 08:55, schrieb Tatsuhiro Nishioka: Hi, I made a special package for OS X 10.5. Go get the package from: http://macflightgear.sf.net/home/downloads FlightGear-2.6.0 for Leopard is what you need. I recommend this package for those who have OS X 10.5 or have problems running the 2.6.0 original package on 10.6 or 10.7. This is tested on my old MacBook pro with 10.5, so it should work on other 10.5 capable macs. The special package is made with XCode 3.2.2 that was used to build FlightGear 2.0.0. Due to huge differences on SDKs between 10.5 and 10.7, apple gave up providing 10.5SDK on Xcode. This made it very difficult to make FG compatible with 10.7 and 10.5. Using Xcode 3.x on OS X 10.5 also has a problem. Since FG code is evolving day to day, it uses newer spells that 10.5 SDK doesn't understand. So I made the Come-on-FG-work-on-10.5! patch for this package :-p Moreover, some Xcode version cannot build FG properly with full optimization flags. I guess this is caused 50% by GCC bug and 50% by bad code like static class initialization with dynamic memory allocation). So picked up a dev tool that I can trust. Though the special package is a bit slower than that for 10.6/10.7 (since the latter is powered by LLVM that optimizes code much cleverer than GCC), it's better to have working binary. Anyway, I'm glad if this can save many FG Mac users. Tat --- Tatsuhiro Nishioka http://macflightgear.sf.net On 2012/02/19, at 8:55, Curtis Olsoncurtol...@gmail.com wrote: Sounds good -- I'm just asking questions. :-) Any thoughts on the reports of crashes for some Mac users -- are you thinking you might try to upload an update in the short term, or are these issues still pretty unknown? Again, just asking questions since I don't know much about the Mac side of things. BTW, as I said in my other email, your FlightGear-2.6.0.dmg works great for me here on an iMac with OSX 10.6.8 Thanks again, Curt. On Sat, Feb 18, 2012 at 4:56 PM, Tatsuhiro Nishiokatatn...@gmail.com wrote: Curt, There's a big hope of 10.5 support. It's just a matter of time to me (to make some fixes and it's almost done). So we can encourage people to be patient for a while. I don't want to let users upgrade their Macs since there must be some reason not to upgrade. Tat On Feb 19, 2012, at 7:02 AM, Curtis Olson wrote: Hi Tat, Is there any hope of supporting OSX 10.5 or do we just need to encourage people to upgrade their software? On my iMac I think it was free -- but I'm not much of a Mac expert -- is it fair to just encourage people to upgrade to OSX 10.6 or newer? Curt. On Sat, Feb 18, 2012 at 1:10 PM, Tatsuhiro Nishiokatatn...@gmail.com wrote: Hi, FlightGear 2.6.0 for Mac OS X is available (works on OS X 10.6, and 10.7 for now). Please download it from: https://sourceforge.net/projects/macflightgear/files/FlightGear/2.6.0/ Note: Currently our website is down so please download it from SF project page. Tat --- Tatsuhiro Nishioka http://macflightgear.sourceforge.net/ -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing
[Flightgear-devel] 2.6.0 for Mac - call for detail bug info known issues
Dear Mac users / developers First, I've heard some users complaining 2.6 for Mac doesn't work, in facebook, or via email without detail info. Could you help me collect what is the cause of this issue? I want to know the following things for reproducing the problem: - Mac model and OS version (e.g. MacBookPro 15/nVidia GT330M/OS X 10.7.2) - FG version and revision (e.g. 2.6.0 r314M) - Command-line option (you can get this from Console.app. it looks like 2/20/12 1:16:59.744 PM [0x0-0x4a04a0].net.sourceforge.macflightgear: Starting fgfs.sh with --aircraft=A6M2-jsbsim --browser-app=open --prop:/sim/rendering/multi-sample-buffers=true --prop:/sim/rendering/multi-samples=2 - Crash dump (if available). As I want to release the updater for fixing common issues in 2.6 ASAP, I want to have many info until the end of this week. Second, I want to share with you the known issues on FG 2.6.0 for mac that I've collected so far. #1) fgfs crashes with CitationX, 777-200ER, and any other Aircraft that add menu items. If an aircraft has Nasal/dialog.nas, it likely crashes when initializing subsystems. This is caused by my bad patch and is mac specific bug. :-( -- Fixed #2) fgfs cannot handle --browser-app=open properly. Somehow preferences.xml overwrites the command-line option. -- Workaround made (patch for preferences.xml), Code level fix is needed. #3) Random Vegetations give us the white squares instead of trees. (only on package for 10.5). -- under investigation. #4) 3D clouds don't show up (only on package for 10.5). -- under investigation. #5) Some aircraft's texture look broken with some integrated graphics chips (shutter-like or patch-work-ish). -- bad GPU OpenGL driver? (e.g. Intel HD Graphics), mainly happens with png textures, I guess. Changing png to rgb seems fixing this issue. it doesn't happen when using nVidia GT330M. #6) integrated graphic chip (e.g. Intel HD Graphics) crashes fgfs during startup (some can survive with cockpit view) -- bad GPU OpenGL driver, I guess ( see the dump below) Thread 3 Crashed: 0 com.apple.driver.AppleIntelHDGraphicsGLDriver 0x05120480 glrReturnUnexpectedKillClient + 15 1 com.apple.driver.AppleIntelHDGraphicsGLDriver 0x0500d2c7 GhalInterface::getCommandBuffer(unsigned char**, unsigned char**, unsigned int*, unsigned int*) + 203 2 com.apple.driver.AppleIntelHDGraphicsGLDriver 0x050af495 GHAL3D::CPrivateCommandTransport::FlushCommandBuffer(GHAL3D::FLUSH_TYPE, unsigned char) + 341 3 com.apple.driver.AppleIntelHDGraphicsGLDriver 0x050af217 g575SubmitPacketsToken + 51 4 com.apple.driver.AppleIntelHDGraphicsGLDriver 0x051302e7 _ZL28GetNewVertexBufferFromKernelP17DataBufferManagerP13GLDContextRecm + 79 5 com.apple.driver.AppleIntelHDGraphicsGLDriver 0x051305b7 g575GetVertexBuffer + 243 6 com.apple.driver.AppleIntelHDGraphicsGLDriver 0x050af17a g575PrefetchPrimitiveBuffer + 49 7 com.apple.driver.AppleIntelHDGraphicsGLDriver 0x050af05c glrBeginPrimitiveBufferUseDataBuffer + 171 8 GLEngine 0x04f85225 gleFlushPrimitiveTCLFunc + 652 9 GLEngine 0x04f0064e gleDrawArraysOrElements_ListExecCore + 199 10 GLEngine 0x04ea1fd3 gleDrawArraysOrElementsOutOfLine_ListExec + 1074 11 GLEngine 0x04e9f1ad gleCallList + 125 12 libGL.dylib 0x92baf188 glCallList + 27 13 fgfs 0x0043f2f6 osg::Drawable::draw(osg::RenderInfo) const + 202 This doesn't happen on major nVidia (e.g. GT330M) and some other AMD discrete chips so far. #7) Cocoa-osgviewer doesn't work properly on some Macs (2.6.0-RC2). Image inside window gets broken when resizing or when using menu. -- I dropped cocoa version and used Carbon version instead. but I want to know what is the cause. It doesn't happen on my MBP15/nVidiaGT330M/OS X 10.7.2 Thank you, Tat --- Tatsuhiro Nishioka http://macflightgear.sourceforge.net/ -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear 2.6.0 for Mac OS X.
Hi, FlightGear 2.6.0 for Mac OS X is available (works on OS X 10.6, and 10.7 for now). Please download it from: https://sourceforge.net/projects/macflightgear/files/FlightGear/2.6.0/ Note: Currently our website is down so please download it from SF project page. Tat --- Tatsuhiro Nishioka http://macflightgear.sourceforge.net/ -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 2.6.0 for Mac OS X.
Curt, There's a big hope of 10.5 support. It's just a matter of time to me (to make some fixes and it's almost done). So we can encourage people to be patient for a while. I don't want to let users upgrade their Macs since there must be some reason not to upgrade. Tat On Feb 19, 2012, at 7:02 AM, Curtis Olson wrote: Hi Tat, Is there any hope of supporting OSX 10.5 or do we just need to encourage people to upgrade their software? On my iMac I think it was free -- but I'm not much of a Mac expert -- is it fair to just encourage people to upgrade to OSX 10.6 or newer? Curt. On Sat, Feb 18, 2012 at 1:10 PM, Tatsuhiro Nishioka tatn...@gmail.com wrote: Hi, FlightGear 2.6.0 for Mac OS X is available (works on OS X 10.6, and 10.7 for now). Please download it from: https://sourceforge.net/projects/macflightgear/files/FlightGear/2.6.0/ Note: Currently our website is down so please download it from SF project page. Tat --- Tatsuhiro Nishioka http://macflightgear.sourceforge.net/ -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Tatsuhiro Nishioka http://macflightgear.sourceforge.net/ -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 2.6.0 for Mac OS X.
Hi, I made a special package for OS X 10.5. Go get the package from: http://macflightgear.sf.net/home/downloads FlightGear-2.6.0 for Leopard is what you need. I recommend this package for those who have OS X 10.5 or have problems running the 2.6.0 original package on 10.6 or 10.7. This is tested on my old MacBook pro with 10.5, so it should work on other 10.5 capable macs. The special package is made with XCode 3.2.2 that was used to build FlightGear 2.0.0. Due to huge differences on SDKs between 10.5 and 10.7, apple gave up providing 10.5SDK on Xcode. This made it very difficult to make FG compatible with 10.7 and 10.5. Using Xcode 3.x on OS X 10.5 also has a problem. Since FG code is evolving day to day, it uses newer spells that 10.5 SDK doesn't understand. So I made the Come-on-FG-work-on-10.5! patch for this package :-p Moreover, some Xcode version cannot build FG properly with full optimization flags. I guess this is caused 50% by GCC bug and 50% by bad code like static class initialization with dynamic memory allocation). So picked up a dev tool that I can trust. Though the special package is a bit slower than that for 10.6/10.7 (since the latter is powered by LLVM that optimizes code much cleverer than GCC), it's better to have working binary. Anyway, I'm glad if this can save many FG Mac users. Tat --- Tatsuhiro Nishioka http://macflightgear.sf.net On 2012/02/19, at 8:55, Curtis Olson curtol...@gmail.com wrote: Sounds good -- I'm just asking questions. :-) Any thoughts on the reports of crashes for some Mac users -- are you thinking you might try to upload an update in the short term, or are these issues still pretty unknown? Again, just asking questions since I don't know much about the Mac side of things. BTW, as I said in my other email, your FlightGear-2.6.0.dmg works great for me here on an iMac with OSX 10.6.8 Thanks again, Curt. On Sat, Feb 18, 2012 at 4:56 PM, Tatsuhiro Nishioka tatn...@gmail.com wrote: Curt, There's a big hope of 10.5 support. It's just a matter of time to me (to make some fixes and it's almost done). So we can encourage people to be patient for a while. I don't want to let users upgrade their Macs since there must be some reason not to upgrade. Tat On Feb 19, 2012, at 7:02 AM, Curtis Olson wrote: Hi Tat, Is there any hope of supporting OSX 10.5 or do we just need to encourage people to upgrade their software? On my iMac I think it was free -- but I'm not much of a Mac expert -- is it fair to just encourage people to upgrade to OSX 10.6 or newer? Curt. On Sat, Feb 18, 2012 at 1:10 PM, Tatsuhiro Nishioka tatn...@gmail.com wrote: Hi, FlightGear 2.6.0 for Mac OS X is available (works on OS X 10.6, and 10.7 for now). Please download it from: https://sourceforge.net/projects/macflightgear/files/FlightGear/2.6.0/ Note: Currently our website is down so please download it from SF project page. Tat --- Tatsuhiro Nishioka http://macflightgear.sourceforge.net/ -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Tatsuhiro Nishioka http://macflightgear.sourceforge.net/ -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org
[Flightgear-devel] FlightGear Mac OS X 2.6.0-RC1 has been released
Hi there, Mac version of FG 2.6.0-RC1 has been finally released. Please download the package from the link below and give it a try. http://macflightgear.sourceforge.net/home/downloads/ Feedbacks and bug reports are very welcome. Note for users: - In-sim menu shows on the Mac menu bar at the top of the screen. - $HOME/.fgfs folder moved to $HOME/Library/Application Support/FlightGear - It crashes on exit - under investigation Tat --- Tatsuhiro Nishioka http://macflightgear.sourceforge.net/ -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Patch to fix the wrong mouse-scroll behavior on Mac.
Hi there, I found a bug on 2.4.0 branch related to mouse scroll up/down. # I posted this issue to FlightGear Bug Tracker but I want to post this here since code fix is coming soon. Most of recent Macs have trackpad or magic mouse. The scrolling action on these devices generates SCROLL_2D event instead of SCROLL_UP/DOWN event. (FYI, SCROLL_UP or SCROLL_DOWN event is generated on unix and windows.) FGEventHandler.cxx handles SCROLL_UP/DOWN event as follows: if (ea.getScrollingMotion() == osgGA::GUIEventAdapter::SCROLL_UP) button = 3; else button = 4; Since this code implicitly handles SCROLL_2D as button 4 (means SCROLL_DOWN button), both scrolling up and down on Mac unexpectedly converted to scroll down button. As a result, scrolling up and down is always treated as scroll DOWN! (or zoom out on MAP) Patch for this is available from: http://code.google.com/p/flightgear-bugs/issues/detail?id=403 I already tested this on Mac and works fine with trackpad. please try this on unix and see if it won't affect unix/windows. I believe this doesn't affect the behavior on other platforms since osgViewer doesn't generate SCROLL_2D on unix and Windows. Tat p.s. btw, is there any button assigned for SCROLL_LEFT / RIGHT? --- Tatsuhiro Nishioka http://macflightgear.sourceforge.net/ -- FREE DOWNLOAD - uberSVN with Social Coding for Subversion. Subversion made easy with a complete admin console. Easy to use, easy to manage, easy to install, easy to extend. Get a Free download of the new open ALM Subversion platform now. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pro Flight Simulator
Hi, Flightgear Mac OS X site also has a note. See http://macflightgear.sf.net/home/downloads By the way, one thing I really hate about these products is that they skip supporting users. As a result, more than 30 users yelled at me like: hey, I got your product but I can't launch it successfully. DVD keeps me go crazy!! So I want you to pay me back!! My answer was like: yeah, here is the link so go ahead. I wish you could get your money back! FYI, I'm not the seller, so don't yell at me. See the link below for more detail... Etc. Then they find out I'm not the evil and give me a polite apology (or a big question mark with confusion). I'm happy to support all FG users including them, but I don't feel good to hear such complaints over something I never sold :-/ Tat - Tatsuhiro Nishioka On 2011/06/08, at 22:32, Stuart Buchanan stuar...@gmail.com wrote: This was discussed ad naseum quite some time ago on this list and on the forums. Those unfamiliar are welcome to look at the archives for details. There's also this statement that we release at the time: http://www.flightgear.org/flightprosim.html Personally, I think we've all got far better things to do with our time than discuss this all again. -Stuart -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear Mac OS X releases - 2.0.0-r284 and git-20110602
Hi there, I've released two binary packages for Mac OS X, one for 2.0.0 and another for git (developer version) as of Jun-02-2011. You can download these from: http://macflightgear.sourceforge.net/home/downloads For more detail, see a release note that comes with each package and the link below: http://macflightgear.sourceforge.net/flightgear-mac-os-x-has-two-updates-for-official-and-developer-releases Have a wonderful flight! Tat --- Tatsuhiro Nishioka http://macflightgear.sourceforge.net/ -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders: implicit cast in function parameters causes fatal error
Hi Fred, Thanks for the quick fix. I really appreciate it! Tat On Aug 23, 2010, at 3:55 PM, Frederic Bouvier wrote: Hi Tat, - Tatsuhiro Nishioka a écrit : The core problem is that an implicit cast (especially from int to double or float) in shader code leads some nVidia drivers a fatal error: (0) : fatal error C: can't find pow function in stdlib Cg compiler terminated due to fatal error (snip) This is fixed now. Thanks for reporting -Fred -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Shaders: implicit cast in function parameters causes fatal error
Hi there, First of all, I'm back to FlightGear after a bit longer vacation :-) I'm very happy that I released a fg-git for Mac OS, but immediately after that, a user gave me a bug report. X-) The core problem is that an implicit cast (especially from int to double or float) in shader code leads some nVidia drivers a fatal error: (0) : fatal error C: can't find pow function in stdlib Cg compiler terminated due to fatal error In his case, this happened when he was adjusting Performance vs Quality slider. So I grep pow in Shaders and found that urban.vert has this line: emission_factor *= 0.5*pow(tc.r+0.8*tc.g+0.2*tc.b, 2) -0.2; I changed 2 to 2.0 and the error went out. This, I believe, is a problem in some of nVidia drivers since it doesn't happen on my Macs, but it's safer not to use implicit cast in function calls. so please check your shader code and eliminate such implicit casts. Best, Tat --- Tatsuhiro Nishioka http://macflightgear.sourceforge.net/ -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Effects on OSX
Hi, This is a problem related to your ATI card (or its driver) I guess. The same thing happens on my old MacBook Pro with ATI Radeon X1600 while using default 2.0.0 base package. This has happened since a few months back (before 2.0.0 release), so I modified the shader scripts in 2.0.0 for avoiding this weirdness. The changes I made just lead some shader scripts to linker error, so it's not that smart way, but it works at least. You can see data/Shaders/*.vert in 2.0.0 data folder for more detail. I guess you can try copying the *.vert in 2.0.0 data folder to your CVS/data/Shaders. Tat On Apr 19, 2010, at 8:37 AM, HB-GRAL wrote: I am running a MacBookPro OSX 10.5 with OpenSceneGraph 2.9.7. I downloaded compiled today cvs source and and here is what I get with current cvs data folder: http://img255.imageshack.us/img255/1559/fgnewdata.png And here is what I get with recent source but an older data folder (same as used from Tat for FG 2.0.0 MacFlightGear Release): http://img532.imageshack.us/img532/2923/fgolddata.png I apologize but the log-level=debug gives me absolutely no information (or gives me a the same errors with both CVS data versions). FG is not really crashing. I get only =1 fps and this intersting gray triangles (when I disable the shaders all works fine but I want to work with the shaders and effects). Can someone give me some hints how recent CVS shaders/effects data runs on OSX? Is my MacBookPro out of date with RadeonX1600 now? Thanks in advance - Yves -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear Mac OS X pre3
Hi there, I've released the pre3 package of FlightGear Mac OS X at the macflightgear site. http://macflightgear.sourceforge.net Please check it out very quickly so I can have improve the quality of 2.0.0. Best, Tat p.s. Many mac users who gave me emails in the past week: Sorry for my very late reply. I'll be replying one by one tonight. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] configure.ac patches for FG/SG
Hi there, I've updated the configure.ac files on FG and SG. these patches fixes minor bug in addition to providing --with-openal-framework and --with-cocoa-framework. Now you can use your own version of OpenAL.framework for selecting various audio output device. Plus, you can build FG/SG on Snow Leopard with cocoa configuration. Please apply these patches. I've tested these on ubuntu and these seem working so far. Note that these patches include the effort of Jari Häkkinen Tat fg-configure.ac.diff Description: Binary data sg-configure.ac.diff Description: Binary data -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch to fix a crash on sound manager when a sound file is not found, etc.
Hi, Thanks for committing my patch, Erik. Could you file a bug report at Apple? Returning an error number when calling alGetError that is not supported by alGetString() is a no-go. I filed a bug report, but I don't think Apple will change their code. Fortunately or unfortunately, alGetString works as OpenAL specification claims. It returns 0 (NULL) when Invalid enum value is passed. So, application side must check the return value of alGetString since it does return NULL even though passing a non-enum error to alSetError is a No-Go. On Jan 5, 2010, at 1:26 AM, James Turner wrote: Ah, I just noticed your (Erik's) commit, never mind. I also note the error code on Mac is -43 which I have a horrible feeling might be the original File Manager 'file not found' code, from 1983. I wonder if someone is passing an OSStatus directly out of a system call to the OpenAL wrapper. As you wonder, OpenAL-MacOSX sometimes passes OSStatus value to alSetError, so not only -43 but many others can also be returned. Very bad! -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Update FG Short Reference
Hi toshi, On Jan 3, 2010, at 2:53 PM, YOSHIMATSU Toshihide wrote: These path names seem as if /FlightGear is a root directory. I think it might be better to write FlightGear and FlightGear\bin\Win32, respectively. Hopefully, adding a path for Mac OS X launcher will improve the quality of the documents. I remember its subdirectory is FlightGear.app/Contents/Resources, but I don't know the name of launcher program. Can anyone suggest a short description about Mac OS X launcher? How about this? Mac OS X via FlightGear.app under /Applications/ (or wherever you installed it). FG Short Reference uses 1.9.2, but the Manual uses 2.0.0. Which is correct as version number of the next release? Tim, Durk, Curt, and I agree with 2.0.0 for coming official version on the discussion of the releasing process. No final call is made yet, but 2.0.0 is going to be the next version number, I believe. Best, Tat -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Patch to fix a crash on sound manager when a sound file is not found, etc.
Hi there,
I found a bug in sound manager that crashes fgfs.
The crash occurs when a designated wav file is not found.
In this case SGSoundMgr::load() does the following (around line 580):
ALenum error = alGetError();
if ( error != AL_NO_ERROR ) {
string msg = Failed to load wav file: ;
msg.append(alGetString(error));
throw sg_io_exception(msg.c_str(), sg_location(samplepath));
return false;
}
Unfortunately alGetString(error) returns NULL (and sets another error) when
unexpected error number (maybe an OS specific error) is passed.
On Mac, OpenAL sets -43 when a given file is not found.
When this happens, msg.append(NULL) causes fgfs crash.
To avoid this crash, you need to check if alGetString returns NULL.
alGetString sets InvalidEnum error when NULL is being returned.
Thus the next alGetString(alGetError()) returns Invalid Enum.
I guess showing the original error message as well as Invalid Enum is helpful.
The enclosed is a patch to do this.
Please give it a try and apply.
Best,
Tat
soundmgr_openal.fix.diff
Description: Binary data
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev ___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main fg_props.cxx, 1.42, 1.43 / Possible cause of crashing FG at exit
Hi, I'd always got the crash when SGProp trying to delete /sim/logging/classes. So this must be the root cause of the crash (sound manager code is innocent). Now it quits without weird crash or malloc errors. Thanks!! Tat On Jan 1, 2010, at 2:32 AM, Martin Spott wrote: Tim Moore wrote: Update of /var/cvs/FlightGear-0.9/source/src/Main In directory baron.flightgear.org:/tmp/cvs-serv17684/src/Main Modified Files: fg_props.cxx Log Message: Move getLoggingClasses() result buffer to file level. Getting it out of the function fixes some corruption problems at program exit. Based on a pretty rough check I'd say this fixes the segfault on exit for me (Debian Lenny/AMD64), Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear Mac OS X 2.0.0-pre1 has been released.
Happy New Year! Finally, the 2.0.0-pre1 release of FlightGear for Mac OS X has been released. Go visit: http://macflightgear.sourceforge.net/home/ for the binary package. Don't forget to consult the ReadMe file that comes with the installation disk image for known issues and new features. I'm very happy if many Mac users help us improve the quality of the next official release by giving us feedbacks. Best Regards, Tat -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Possible cause of crashing FG at exit - HELP NEEDED
Hi, #7 0x0806cce7 in fgExitCleanup () at bootstrap.cxx:305 I only have a 265 line bootstrap.cxx ..?? Erik You have r1.42 of bootstrap.cxx. On r1.41, it has 310 lines. On Dec 16, 2009, at 6:20 PM, Erik Hofman wrote: As many of you already know, FG often crashes at exit (See back trace below). Though the chance of crash varies per platform, it crashes more than 80% on my Mac with very annoying Crash Reporter dialog popping up. This bug must be eliminated before the official release. Ok, you might want to make some big steps towards finding the cause by starting commenting out code in SGSoundMgr::~SGSoundMgr(). I would atart with the first call: 'stop()' If that fixes it then start to comment out code in SGSoundMgr::stop() until you locate the problem. (just comment out big sections with #if 0 .. #endif first). I'll give this a try! Thanks, Tat -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Possible cause of crashing FG at exit - HELP NEEDED
Hi there, As many of you already know, FG often crashes at exit (See back trace below). Though the chance of crash varies per platform, it crashes more than 80% on my Mac with very annoying Crash Reporter dialog popping up. This bug must be eliminated before the official release. As a result of several hours of research, I've found a possible cause that crashes fgfs at exit, which has something to do with the Sound Manager updates committed on Oct-24-2009 (See the cvs logs below for detail). I've been looking at the code and tracing up and down on gdb, but I've not yet found a root cause. So I want you guys to help me find the root cause. I'm not so sure if Erik's commits are directly related to the crash since fgfs crashes after SGSoundMgr is already deleted. Maybe the problem were there and his commits just pull out the crash. maybe his commit has something to do with it deep inside. Maybe using SGPropertyNode * instead of SGPropertyNode_ptr (with explicit delete) will help you find the cause FYI, I tried several FG/SG cvs checkouts and found that FG starts crashing on 10/24. (FG on 10/23 15:00 UTC doesn't crash at exit but 10/24 15:00 UTC does). I checked the commits between 10/23 15:00 and 10/24 15:00 and found 6 commits (4 Sound Manager commits, one JSBSim sync, and one more. So I applied each independent set of commits onto 10/23 source one by one, and the crash occurs only with Sound Manager commits. I also tried fg/sg as of a few days back and got the same crash dump. Thanks for your help, Tat -- back trace on FG/SG 10/25 15:00 (one file in on 10/27 due to typo) - [on Mac OS 10.5] Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x01e4 0x93134c4f in szone_free () (gdb) bt #0 0x93134c4f in szone_free () #1 0x9313438d in free () #2 0x9189202a in std::string::_Rep::_M_destroy () #3 0x918934ab in std::basic_stringchar, std::char_traitschar, std::allocatorchar ::~basic_string () #4 0x006e4c77 in SGPropertyNode::~SGPropertyNode (this=0x227905a0) at props.cxx:737 #5 0x9516 in SGSharedPtrSGPropertyNode::put (this=0x22790604) at SGSharedPtr.hxx:107 #6 0x9533 in SGSharedPtrSGPropertyNode::~SGSharedPtr (this=0x22790604) at SGSharedPtr.hxx:61 #7 0x00069f61 in __gnu_cxx::new_allocatorSGSharedPtrSGPropertyNode ::destroy (this=0xbfffee4f, __p=0x22790604) at ext/new_allocator.h:107 #8 0x00069f7e in std::_DestroySGSharedPtrSGPropertyNode*, std::allocatorSGSharedPtrSGPropertyNode (__first=0x22790604, __last=0x22790608, __all...@0xbfffee4f) at stl_construct.h:174 #9 0x00069fc6 in std::vectorSGSharedPtrSGPropertyNode, std::allocatorSGSharedPtrSGPropertyNode ::~vector (this=0x227904f4) at stl_vector.h:273 #10 0x006e4c42 in SGPropertyNode::~SGPropertyNode (this=0x227904e0) at props.cxx:737 #11 0x9516 in SGSharedPtrSGPropertyNode::put (this=0x24c7701c) at SGSharedPtr.hxx:107 #12 0x9533 in SGSharedPtrSGPropertyNode::~SGSharedPtr (this=0x24c7701c) at SGSharedPtr.hxx:61 #13 0x00069f61 in __gnu_cxx::new_allocatorSGSharedPtrSGPropertyNode ::destroy (this=0xbfffef7f, __p=0x24c7701c) at ext/new_allocator.h:107 #14 0x00069f7e in std::_DestroySGSharedPtrSGPropertyNode*, std::allocatorSGSharedPtrSGPropertyNode (__first=0x24c7701c, __last=0x24c77130, __all...@0xbfffef7f) at stl_construct.h:174 #15 0x00069fc6 in std::vectorSGSharedPtrSGPropertyNode, std::allocatorSGSharedPtrSGPropertyNode ::~vector (this=0x22779484) at stl_vector.h:273 #16 0x006e4c42 in SGPropertyNode::~SGPropertyNode (this=0x22779470) at props.cxx:737 #17 0x9516 in SGSharedPtrSGPropertyNode::put (this=0x2513b3a0) at SGSharedPtr.hxx:107 #18 0x9533 in SGSharedPtrSGPropertyNode::~SGSharedPtr (this=0x2513b3a0) at SGSharedPtr.hxx:61 #19 0x00069f61 in __gnu_cxx::new_allocatorSGSharedPtrSGPropertyNode ::destroy (this=0xb0af, __p=0x2513b3a0) at ext/new_allocator.h:107 #20 0x00069f7e in std::_DestroySGSharedPtrSGPropertyNode*, std::allocatorSGSharedPtrSGPropertyNode (__first=0x2513b3a0, __last=0x2513b404, __all...@0xb0af) at stl_construct.h:174 #21 0x00069fc6 in std::vectorSGSharedPtrSGPropertyNode, std::allocatorSGSharedPtrSGPropertyNode ::~vector (this=0x22779424) at stl_vector.h:273 #22 0x006e4c42 in SGPropertyNode::~SGPropertyNode (this=0x22779410) at props.cxx:737 #23 0x9516 in SGSharedPtrSGPropertyNode::put (this=0x1b34328) at SGSharedPtr.hxx:107 #24 0x9533 in SGSharedPtrSGPropertyNode::~SGSharedPtr (this=0x1b34328) at SGSharedPtr.hxx:61 #25 0x0003c6c4 in FGGlobals::~FGGlobals (this=0x1b34320) at globals.cxx:166 #26 0x2ce8 in fgExitCleanup () at bootstrap.cxx:305 #27 0x93156dc7 in __cxa_finalize () #28 0x93156cb0 in exit () #29 0x0005069f in fgExit (status=Could not find the frame base for fgExit(int). ) at util.cxx:117 #30 0x000689c5 in fgOSMainLoop () at fg_os_osgviewer.cxx:177 #31 0x3be3 in fgMainInit (argc=1, argv=0xb490) at
Re: [Flightgear-devel] Version number for the upcoming release
Hi, On Dec 14, 2009, at 7:18 AM, James Turner wrote: One observation - the intention, at least mine and Tim's, is to move to quarterly releases, so I have no intention of 'finishing' the route manager for a particular release. (Regular release cycles take the pressure of rushing to complete a feature) Stable features will be integrated onto the 'next' branch, when they're complete (or a functionally useful subset is complete). The shaders and sound changes both fall into this category, while the route manager work is certainly not in that category yet. I vote to both quarterly release and separating stable branch from development branch. My opinion about next version number is 1.10.0 since the current FG doesn't reach the 2.0 criteria (We stil miss shadows). I would accept 1.19.0 if we agree that our effort in this year worth 10 times of minor updates. Anyway, we must not go for 2.0 unless we change the 2.0 criteria. Tat p.s. Though 1.10.0 can be confusing (or using dots is confusing), you can get used to it when you know how the versions numbers are compared. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL / ALUT problem on Mac (was PATCH Suggested configure.ac changes/improvements affecting mac users)
Hi Jari, On Dec 2, 2009, at 4:50 AM, Jari Häkkinen wrote: Hi Tat, I have a working dev setup which I rebuild automatically more often I'd should thanks to your scripts and others input. Once everything compiles and the scripts are tuned the effort to update to latest repository versions of all packages is minimal. Patience is required though since the compile time can be very long. Yeah, even with make -j 4, it takes for a while. What a big project For building a release package (universal binary), I run build.sh and have a meal. :-p I wish I could have Mac Pro and do make -j 16. that'll be helpful. I just saw an opportunity to decrease the compile time dependencies. For me personally there is no need to provide prebuilt partial packages but thanks anyway. I'll start to compile the OSXLauncher soon so maybe there'll be a new thread opening soon ;-) Cool. I look forward to it. Best, Tat -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] OpenAL / ALUT problem on Mac (was PATCH Suggested configure.ac changes/improvements affecting mac users)
on purpose?) However, this is all valid since freeglut of course provides the required underlying functionality. My experience is that this works perfectly without any need to change API names as claimed by Tat. One further confusion is that the alut.h is unnecessarily included in soundmgr_openal.hxx and alut becomes exposed to code that includes soundmgr_openal.hxx, i.e., fg source. To compile fg/source you need to have alut.h as the code is today. If nothing else, please remove the include in soundmgr_openal.hxx, the file itself does not use anything from alut.h. All alut.h usages is in the cxx-file. One of my coding rules is to avoid including header files not needed. I post this with good intent, Cheers Jari On 2009-11-29 19.35, Tatsuhiro Nishioka wrote: On Nov 29, 2009, at 8:12 AM, Jari Häkkinen wrote: On 2009-11-28 23.01, Erik Hofman wrote: Jari Häkkinen wrote: My comments was to elaborate on the consequences of the removed alut support by Apple. It is dangerous to use any alut.h you find on the web. As you point out using Creatives alut.h may make things simpler (macports.org is another option). I used freealuts alut.h which made the compiler to choose an unexpected path (for macs) in the source during compilation. The path chosen by the compiler required more alut functionality than provided by my mac. However, using freealut libs and alut.h, and Apples OpenAL framework works perfectly, I have done that for a while. (Now I changed strategy as outlined in other postings in this thread.) From what I understand Apple is depreciating those old alut functions (but still keeps hem in the library for backwards compatibility) and is encouraging everyone to use the freealut package instead. And so do I. Erik Yes, you are right. FYI, Here is Apple's policy on ALUT thing. http://developer.apple.com/mac/library/qa/qa2006/qa1504.html I believe we have a few options to use ALUT thingie in your code on Mac. 1) Use OpenAL.framework's backward compatibility (You need alut.h that comes with Creative's OpenAL.framework) 2) Use OpenAL framework + free-alut (You need to change some API names for avoiding name conflicts) 3) Change your code not to use ALUT (without embedding ALUT source code) One thing you must avoid is to add free-alut's alut.h to Apple's OpenAL.framework since this causes linker errors due to version mismatch. Anyway, I'll make a patch for configure.ac so we can support case 1 and 2 above so you can safely use free-alut. Best, Tat -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fg shows a blank screen
Hi Jari, On Nov 29, 2009, at 12:33 AM, Jari Häkkinen wrote: On the startup terminal I get messages like this one Sat Nov 28 16:27:15 signori.local fgfs[54344] Error: CGBitmapContextCreate: unsupported parameter combination: 8 integer bits/component; 16 bits/pixel; 1-component color space; kCGImageAlphaLast; 512 bytes/row. Sat Nov 28 16:27:15 signori.local fgfs[54344] Error: CGContextDrawImage: invalid context 0x0 The error messages are made due to failure in loading PNG files (usually grayscale images + alpha). This is Mac OS X specific and is under investigation but you can see the cause and the workaround at: http://macflightgear.sourceforge.net/home/development-notes/devnote-nov-26-2009 Hope it helps in separating the problems, Tat -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
On Nov 29, 2009, at 8:12 AM, Jari Häkkinen wrote: On 2009-11-28 23.01, Erik Hofman wrote: Jari Häkkinen wrote: My comments was to elaborate on the consequences of the removed alut support by Apple. It is dangerous to use any alut.h you find on the web. As you point out using Creatives alut.h may make things simpler (macports.org is another option). I used freealuts alut.h which made the compiler to choose an unexpected path (for macs) in the source during compilation. The path chosen by the compiler required more alut functionality than provided by my mac. However, using freealut libs and alut.h, and Apples OpenAL framework works perfectly, I have done that for a while. (Now I changed strategy as outlined in other postings in this thread.) From what I understand Apple is depreciating those old alut functions (but still keeps hem in the library for backwards compatibility) and is encouraging everyone to use the freealut package instead. And so do I. Erik Yes, you are right. FYI, Here is Apple's policy on ALUT thing. http://developer.apple.com/mac/library/qa/qa2006/qa1504.html I believe we have a few options to use ALUT thingie in your code on Mac. 1) Use OpenAL.framework's backward compatibility (You need alut.h that comes with Creative's OpenAL.framework) 2) Use OpenAL framework + free-alut (You need to change some API names for avoiding name conflicts) 3) Change your code not to use ALUT (without embedding ALUT source code) One thing you must avoid is to add free-alut's alut.h to Apple's OpenAL.framework since this causes linker errors due to version mismatch. Anyway, I'll make a patch for configure.ac so we can support case 1 and 2 above so you can safely use free-alut. Best, Tat -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] clouds heads up
Hi, On Nov 28, 2009, at 7:16 PM, Tim Moore wrote: On 11/28/2009 05:25 AM, Tatsuhiro Nishioka wrote: Hi Tim, As I said to you in IRC, I have a weird transparency problem with the shaders enabled. Here's the snapshot (helicopter view) with shaders. http://macflightgear.sourceforge.net/wp-content/uploads/snapshots/3dclouds-effect-enabled.png I used both FG/SG @ cvs-head as of yesterday and FG/SG @ Tim's git, but I got exactly the same result. The cause of this fancy rainbow-ish filter is the alpha calculation in both default.vert and model-default.vert. A lazy patch to avoid this issue is available at: http://macflightgear.sourceforge.net/wp-content/uploads/patches/shaders-weird-alpha-fix.diff I don't know if the real problem is in a shader side or C++ side. Tim, do you have any hint on this? Pretty bizzare. Obviously turning off alpha altogether isn't a real option. Is this a new problem since the 3d clouds went in, or are/were you seeing it without 3d clouds at all? What version of OSG are you using? I guess this problem is not that new, but I couldn't see it until you introduced the alpha calculation on .vert files. As a matter of fact, a bit older FG/SG/OSG/data (cvs or svn as of Sep/07/2009) and the latest shaders (all .eff, .vert, .frag, and materials.xml as of Nov/28/2009) gave me the similar result. The rainbow-ish effect shows up on both scenery and ground objects. Only the difference is that the older FG doesn't have a rainbow-ish effect on the aircraft model, while the latest FG/SG the latest Shader make a rainbow-ish effect on the aircraft model as well. (FYI, I use OSG/svn on Nov/27 for the latest FG/SG.) This rainbow-ish effect shows up with or without 3D clouds on both old and the latest FG, so I guess it has nothing to do with the new 3D cloud shader. Anyway, I'll keep investigating this. Tat Tim -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
Hi Jari, First, I made patches for configure.ac in both SimGear and FlightGear (except svn lib part) so please give it a try. # This assumes you have alut.h (that comes with Creative's OpenAL.framework) in /Developer/SDKs/MacOSX10.6/System/Library/OpenAL.framework/Headers On Nov 27, 2009, at 10:37 PM, Jari Häkkinen wrote: Jari Häkkinen wrote: Tatsuhiro Nishioka wrote: Ah, so there is no real need for alut.h at all. Hm, so the alut.h issue should rather go in to simgear. I now tested with a zero length alut.h and no libalut. Compiling works but the linker fails with alut-complaints Undefined symbols: _alutInitWithoutContext, referenced from: SGSoundMgr::SGSoundMgr()in libsgsound.a(soundmgr_openal.o) I guess you're using SG from Tim's git repository (or similar). To get simgear I of course had to provide an alut.h but the one I have is from freealut-1.1 which gives me unwanted consequences. I am not sure about the #if statements on ALUT_API_MAJOR_VERSION in simgear/soundmgr_openal.cxx but I think that the compiler should not compile code calling alutInitWithoutContext on Apple computers. With my below suggested changes this issue will go away. Using alut.h from freealut-1.1 with Apple's OpenAL.framework (0.0.8) is a big problem. You need to use alut.h that comes with OpenAL.framework in Creative's OpenAL installer. SimGear's sound_manager.cxx uses free-alut's ALUT functions only if ALUT_API_MAJOR_VERSION is defined (free-alut's alut.h defines it, but (older) alut.h in OpenAL.framework doesn't), so using alut.h that comes with Creative's OpenAL.framework gets rid of your linker error. As a matter of fact, I have no linker errors in compiling SG @ Tim's git with alut.h that comes with Creative's OpenAL installer. and more. Listing alut-related functions in the OpenAL framwork only gives a short list of alut related functions: # nm openAL | grep alut 00013133 T _alutExit 00013168 T _alutInit 00013a2e T _alutLoadWAVFile 000136f8 T _alutLoadWAVMemory 0001311e T _alutUnloadWAV I have freealut installed to resolve the above linker problem Browsing through simgear/soundmgr_openal.cxx it looks like the calls to non-supported alut functions can be avoided. I look into that. I removed all dependencies on alut.h which all seems to be in simgear/sound only. I simply removed a few include statements and added one function declaration (see attached patch file). All of the fg components now compiles without any alut/freealut added (except for the backward compatibility stuff in OpenAL framework supplied by Apple). Isn't there non-alut replacement for alutLoadWAVFile? If there is then alut could be removed completely. I have not yet had the possiblity to extensively test the changes suggested in the patch but during a short flight the changes seems to work. If the proposed changes is pushed to the official simgear CVS then the configure scripting will be easier for simgear and fg/source wrt alut (at least for mac developers). Using the alut.h in Creative's OpenAL.framework will get the job done, so you don't have to do this yourself. If you want to use more embedded way rather than adding alut.h to Mac's Developer SDK, then you can locally add alut.h to simgear/sound folder. I used this way to avoid changing headers on every OS update. You can also use the following patches for this purpose. http://macflightgear.svn.sourceforge.net/viewvc/macflightgear/trunk/patches/SimGear-0.3-cvs-20061203-MacOSX.diff?revision=170view=markup http://macflightgear.svn.sourceforge.net/viewvc/macflightgear/trunk/patches/alc.patch?revision=217view=markup First one is a patch for local alut.h inside SimGear and the second one is a patch to alc.h for compiling with gcc 4.2.x (optional) Maybe you want to change the folder name from MacOSX10.5.sdk to MacOSX10.6.sdk in the second patch. Best, Tat fg-configure.diff Description: Binary data sg-configure.diff Description: Binary data -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] clouds heads up
Hi Tim, As I said to you in IRC, I have a weird transparency problem with the shaders enabled. Here's the snapshot (helicopter view) with shaders. http://macflightgear.sourceforge.net/wp-content/uploads/snapshots/3dclouds-effect-enabled.png I used both FG/SG @ cvs-head as of yesterday and FG/SG @ Tim's git, but I got exactly the same result. The cause of this fancy rainbow-ish filter is the alpha calculation in both default.vert and model-default.vert. A lazy patch to avoid this issue is available at: http://macflightgear.sourceforge.net/wp-content/uploads/patches/shaders-weird-alpha-fix.diff I don't know if the real problem is in a shader side or C++ side. Tim, do you have any hint on this? Best, Tat On Nov 27, 2009, at 2:41 AM, Tim Moore wrote: I've checked in code that changes 3D clouds to use effects. you should update simgear and Effects and Shaders in the data directory. There is a one frame blip of weirdness that I know about; a fix is in the works. Tim -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
Hi Jari,
Thanks for your patch, and sorry for my very late reply.
I'm back from my vacation and have been catching up the discussions on the list.
It all seems good to me but I need to work a bit more on OpenAL and svn lib
thingies.
Mac OS X, by default, has OpenAL.framework with ALUT implementation.
Only the problem is that it lacks alut.h in its Headers folder.
So what we need to check is the existance of alut.h in SimGear's configure
FlightGear's configure doesn't need to check the existance of alut.h since it
doens't include the header.
Anyway, we have to either install OpenAL with alut.h to /Library/Frameworks or
manually add alut.h to
/Developer/SDKs/*/System/Library/Frameworks/OpenAL.frameworks/Headers/
We also need some hacks to alc.h for avoiding error messages (invalid type
conversion between ALvoid and void) when using g++ 4.2.x.
Maybe we should add some note on this issue to README.OpenAL.
svn library checks look good to me, but we probably should let the users
specify the location of the libs.
This is mainly because svn libs on 10.5.x is older and users usually install
the newer ones to /usr/local or some other folder.
LDFLAGS=-L/some/path/to/svn-libs configure works in such case, but configure
--with-svn-libs=/some/path/to/svnlibs could be better.
Anyway, I'll apply your patch and make some modifications for better usability,
so be patient for a bit more please.
Best,
Tat
On Nov 1, 2009, at 7:03 AM, Jari Häkkinen wrote:
I have made changes (improvements?) to the configure script. I have
attached a patch file for configure.ac with changes targeting issues
with building flightgear on my mac. The changes will only impact mac
users.
Changes made:
1) Fixed mixup in AC_ARG_WITH between osg and plib.
2) Added check for that openal framework can be located in the default
framework path. Test for non-standard path is not implemented.
3) Added check if alut is a part of the OpenAL framework, if not the a
AC_SEARCH_LIBS os performed to search for freealut. Snow Leopard
does not provide alut as a part of the OpenAL framework.
4) I added --with-cocoa-framework option. This enables the user to
switch from the default Carbon framework to Cocoa.
Comments:
Change 1) is an error in configure.ac and should be fixed even if the
rest of my changes are rejected.
Change 2) and 3) may break things for other mac users since there was
no checks before, configure simply set some variables without testing.
Change 4) is needed to compile 64-bit binaries on mac but the change
will not affect Carbon users. Carbon is 32-bit only whereas Cocoa
comes also in 64-bit flavour. (OSG works with Cocoa but OSG quicktime
support must be dropped and the ImageIO plug-in must probably be used
in OSG).
Can some other mac users try my changes and report back? If the
changes work on other machines than mine then can convince someone to
commit the changes to CVS.
Cheers,
Jari
Index: configure.ac
===
RCS file: /var/cvs/FlightGear-0.9/source/configure.ac,v
retrieving revision 1.154
diff -u -p -r1.154 configure.ac
--- configure.ac 17 Sep 2009 07:39:04 - 1.154
+++ configure.ac 31 Oct 2009 21:55:35 -
@@ -85,16 +85,27 @@ case ${host} in
])
# Mac OS X specific configure options
-AC_ARG_WITH(osg_framework, [ --with-osg-framework=PREFIX Specify
the prefix path to osg frameworks [default=standard framework paths]])
-if test x$with_plib_framework != x ; then
-echo plib prefix is $with_plib_framework
+# OpenAL framework is used by default, no openal_framework implemented.
+
+AC_ARG_WITH(cocoa_framework, [ --with-cocoa-framework Use the
Cocoa rather than Carbon]])
+if test x$with_cocoa_framework != x ; then
+macAPI=Cocoa
+AC_MSG_NOTICE([Using Cocoa framework])
+else
+macAPI=Carbon
+AC_MSG_NOTICE([Using Carbon framework])
fi
-AC_ARG_WITH(plib_framework, [ --with-plib-framework=PREFIX
Specify the prefix path to PLIB framework [default=standard framework paths]])
+AC_ARG_WITH(osg_framework, [ --with-osg-framework=PREFIX Specify
the prefix path to osg frameworks [default=standard framework paths]])
if test x$with_osg_framework != x ; then
echo osg prefix is $with_osg_framework
fi
+
+AC_ARG_WITH(plib_framework, [ --with-plib-framework=PREFIX
Specify the prefix path to PLIB framework [default=standard framework paths]])
+if test x$with_plib_framework != x ; then
+echo plib prefix is $with_plib_framework
+fi
;;
esac
@@ -335,7 +346,7 @@ case ${host} in
*-apple-darwin*)
dnl Mac OS X
-LIBS=$LIBS -framework GLUT -framework OpenGL -framework AGL -framework
Carbon -lobjc
+LIBS=$LIBS -framework GLUT -framework OpenGL -framework AGL -framework
$macAPI -lobjc
Re: [Flightgear-devel] Problematic forum discussion on an MP event
Ieee. Do not nudge my expressions and thought. First, I didn't express this is the recreation of the a-bomb raids. That's way far from what I've said. Second, I didn't say I ignored many of the posts. I skipped some meaningless posts on the forum, and I wrote that because I might have skipped a post that some of the potential participants might try to change the plan. If that expression get your temper lost, I feel very sorry, but only by that expression, you cannot judge what I actually have done. All you can do, in a logical fashion, is to assume what I possibly did. Third, I haven't even force my will on other people. As a matter of fact, none of them changed the plan. I rather simply expressed my thought on their event. Why can't I do that? I'm also not forbidding them to use Hiroshima and Nagasaki. I expressed my opinion that I object to use these, hoping they understand how other people may get hurt. Fourth, I don't even think getting away from the fact that happened as a real event is the best idea. When did I say that? As a matter of fact, I've learned about Hiroshima and Nagasaki, and other war events for many years, including the effects and affects. If the MP event is like to simulate the past horrible event and try to learn some meaningful out of it, I will never stop it. It rather, I think, is worth participating. Unfortunately, the event I mentioned is very far from that purpose. Aside from your criticism, I do agree with your expression of Swastika. it is used in Japan (typically opposite direction) as a symbol of good sign and typically used as a symbol of shrine. Though there're no problem in using Swastika in Japan, we don't usually use these in European countries. As a matter of fact, many japanese cartoons exported to Europe tends to delete the Swastika signs. But this is not for ignoring the past event or a specific sign, but for showing the respect to some other's thought or feeling. Anyway, my whole point of posting my opinion on the event was not to force them ignore the past event, but rather ask them to consider someone's negative feeling. Ignorance and solicitude is very different. If you take my point as an ignorance, then I feel very sorry on that. By the way, I do agree with the thought this must be out of the list, but I couldn't leave someone misunderstand my whole point. If someone still want to discuss this, please send me an email. Now I shut my mouse on this topic on the list. On Sep 19, 2009, at 12:28 AM, leee wrote: The most depressing thing about this thread is that it highlights the fact that many people seem to think that the best way to deal with unpleasant events in history is to mythologise and make them sacred and untouchable, and then to try to force other people to comply with their personal views. First of all, Tat has presented this event as a recreation of the A-bomb raids, which is factually incorrect. Tat even says in his post on the forum I haven't read all posts in this thread... but that ignorance hasn't stopped him from going off on an irrelevant tangent over something that isn't even happening. Harsh words? Yes indeed, but I have no patience or sympathy for anyone who wants to force their will on other people, especially when they've got their facts wrong, or simply choose to misrepresent them. It's bad enough that politicians get away with it. In any case though, even if the raid was to be an enactment of one of the A-bomb raids, is forbidding people to do it the best way to deal with the issue? Should enactments of unpalatable events in history made into thought-crimes? There's certainly no real crime being committed here, is there? The fact is, events like the A-bombing of Hiroshima and Nagasaki actually occurred, along with numerous other raids where the majority of casualties were civilian, such as the firebombing of Tokyo (which is believed to have actually killed more people than either of the A-bomb raids), Dresden and Hamburg, together with the raids on Coventry Sheffield, not forgetting to mention the Blitz on London or the attacks on the Ruhr Dams. So no, mythologising these unpalatable events is not the best way to come to terms with them. To understand how such terrible events came to occur requires that the events be inspected down to their finest details and it's only when you completely understand what happened that you stand a chance of ensuring that it doesn't happen again. Saying that people should treat these events as something sacred and that re-enacting them or studying them is somehow offensive just ensures ignorance, which is no way to tackle the future. This issue really has nothing to do with FlightGear. FlightGear is all about flight, and to a large degree about the development of flight, both in the past and for the future, and the fact is that much of the development in flight has its origins in the
[Flightgear-devel] Problematic forum discussion on an MP event
Hi there, I found a problematic forum topic on planning an MP event, by which I really got hurt at least. http://www.flightgear.org/forums/viewtopic.php?f=10t=5761 The plan of the event is to simulate the bombing mission against both Hiroshima and Nagasaki (the horrible two atomic bombs). As a developer of FG / Zero, and as a person who lives in Japan. I'm very angry and sad to see such event is being planned. I don't want the topic leader to completely cancel the event, but at least he must change the plan. If you agree with me, please help me change his plan. Thanks in advance, Tat -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Their Plan / Problematic forum discussion on MP event
Hi syd, You're right. I should have added that the discussion must be made on the forum, not in the devel list. Forks, thanks for the comments and opinions. please discuss this issue on the forum, not in the list, please. Thanks, - Tatsuhiro Nishioka On 2009/09/18, at 12:16, syd adams adams@gmail.com wrote: Just a thought , but could these kinds of topics be kept to the forum , not the dev-list ? Thanks On Thu, Sep 17, 2009 at 8:03 PM, George Patterson george.patter...@gmail.com wrote: On Fri, Sep 18, 2009 at 11:51 AM, Pete Morgan ac...@daffodil.uk.com wrote: *Their mission is below.* All some of us need to do is to be there at the right time and the right place.. right ? We'll buzz them down ;-) Nope.. that just validates the idea. I'm not sure where all these people came from but I am happy to have them with us. If I was running a fg mp server, I'd be performing maintenance at short notice during the event. Regards George --- --- --- - Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel --- --- --- - Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patches for configure.ac/Makeifle.am in SG/FG
Hi Torsten, I'm very glad that you committed the patch! I really appreciate that. Best, Tat On Sep 17, 2009, at 2:18 AM, Torsten Dreyer wrote: I've updated the patches. [..] I believe these patches are really important for Mac users since they don't have to wait for my updating xcode project files. these also saves up to 50% of build time since most of users don't have to make universal binaries. I have just commited these and they work fine for me (Linux/openSUSE). No other systems here to test, so please report if anything is broken. Torsten -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patches for configure.ac/Makeifle.am in SG/FG
Hi, That's weird since my patch doesn't have a reference to utils/fgpanel. I don't have such folder in my end either. Torsten, do you happen to have had the reference in your configure.ac? Tat On Sep 17, 2009, at 2:42 AM, Csaba Halász wrote: On Wed, Sep 16, 2009 at 7:18 PM, Torsten Dreyer tors...@t3r.de wrote: I've updated the patches. [..] I believe these patches are really important for Mac users since they don't have to wait for my updating xcode project files. these also saves up to 50% of build time since most of users don't have to make universal binaries. I have just commited these and they work fine for me (Linux/openSUSE). No other systems here to test, so please report if anything is broken. Willie just reported on IRC, that this patch references utils/fgpanel which is not in cvs. -- Csaba/Jester -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] generic input device support: wrong button event names in Linux
Hi Torsten, On Sep 15, 2009, at 10:20 PM, Torsten Dreyer wrote: I guess it is safer to use button-0, button-1, ... button-N for button event names so the names stays the same on different OSs. maybe we need to pull out some info using ioctl to find the first hid event code for a given device (e.g. 228 for joystick). I think your are right, simply numbering the buttons is probably the better approach. I assume, that button numbers are consitent across OSes, because they are defined in the HID report descriptor. Glad to hear that. I also agree on your assumption. We can find a means of numbering the buttons on Linux. or maybe you already know that. I'll also keep testing this feature on both Linux and Mac using some devices that I have. I'll let you know if I found any problems. Best, Tat -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] generic input device support: wrong button event names in Linux
Hi Brant,
Though your problem should be looked and fixed, it is different from
this one since the generic input device support is not implemented on
windows yet.
Plus, it does nothing on any platform unless you make a configuration
file for your device under $FG_ROOT/input/event/Some Vendor/Some
product.xml.
Thus this problem doesn't affect the existing joystick feature.
Btw, is any one kindly enough to implement this feature on windows?
Tat
On 2009/09/15, at 8:30, Brant G ioncannon21...@gmail.com wrote:
Indeed. I have a X52 joystick and it's very confusing to configure
in the joystick .xml file. When I updated to CVS recently, the hats
buttons don't work properly in windows. This should be looked at and
fixed.
On Mon, Sep 14, 2009 at 6:45 PM, Tatsuhiro Nishioka tat.fgmac...@gmail.com
wrote:
Hi,
I've been testing X52 joystick with FGLinuxEventInput.cxx on liunx
and found that button event names for joysticks/gamepad are very
suspicious, and we need to consider some other means of naming
button events.
The problem is that a joystick (, mouse or gamepad) button can have
wrong event name if a device has more than 16 buttons.
This is because Linux hid driver (drivers/hid/hid-input.c) assumes
that a device has 16 buttons at most.
e.g. If a joystick has more than 16 buttons, a button event name for
button-#16 or higher are mistakenly assigned to ones in game pads,
digitizer, or others.
This is the excerpt from hid-input.c ( hidinput_configure_usage)
that shows how Linux driver converts HID usage to a code of hid
event written to /dev/input/js*
case HID_UP_BUTTON:
code = ((usage-hid - 1) 0xf); // Note:
assuming #buttons = 16.
switch (field-application) {
case HID_GD_MOUSE:
case HID_GD_POINTER: code += 0x110;
break;
case HID_GD_JOYSTICK: code += 0x120;
break;
case HID_GD_GAMEPAD: code += 0x130;
break;
default:
switch (field-physical) {
case HID_GD_MOUSE:
case
HID_GD_POINTER: code += 0x110; break;
case
HID_GD_JOYSTICK: code += 0x120; break;
case
HID_GD_GAMEPAD: code += 0x130; break;
default: code += 0x100;
}
}
map_key(code);
break;
As a matter of fact, event names for X52 buttons are assigned as
follows in FGLinuxEventInput.cxx:
#00 button-trigger: type=1, code=288 (trigger)
#01 button-thumb: type=1, code=289 (FIRE button on stick)
#02 button-thumb2: type=1, code=290 (A button on stick)
#03 button-top: type=1, code=291 (B button on stick)
#04 button-top2:type=1, code=292 (C button on stick)
#05 button-pinkie: type=1, code=293 (pinkie button)
#06 button-base:type=1, code=294 (D button on throttle)
#07 button-base2: type=1, code=295 (E button on throttle)
#08 button-base3: type=1, code=296 (T1)
#09 button-base4: type=1, code=297 (T2)
#10 button-base5: type=1, code=298 (T3)
#11 button-base6: type=1, code=299 (T4)
#12 button-300: type=1, code=300 (T5)
#13 button-301: type=1, code=301 (T6)
#14 button-302: type=1, code=302 (strong press of trigger)
#15 button-dead:type=1, code=303 (top hat up)
// buttons below are mistakenly assigned to GamePad buttons
#16 button-a: type=1, code=304 (top hat right)
#17 button-b: type=1, code=305 (top hat down)
#18 button-c: type=1, code=306 (top hat left)
#19 button-x: type=1, code=307 (hat up on throttle)
#20 button-y: type=1, code=308 (hat right on throttle)
#21 button-z: type=1, code=309 (hat down on throttle)
#22 button-tl: type=1, code=310 (hat left on throttle)
#23 button-tr: type=1, code=311 (mode1 on stick)
#24 button-tl2: type=1, code=312 (mode2 on stick)
#25 button-tr2: type=1, code=313 (mode3 on stick)
#26 button-select: type=1, code=314 (Function button on
throttle)
#27 button-start: type=1, code=315 (Start button on
throttle)
#28 button-mode:type=1, code=316 (RESET button on
throttle)
#29 button-thumbl: type=1, code=317 (i button on throttle)
#30 button-thumbr: type=1, code=318 (mouse button on
throttle)
#31 button-319: type=1, code=319 (wheel button on
throttle) // undefined in input.h
// buttons below
Re: [Flightgear-devel] Patches for configure.ac/Makeifle.am in SG/FG
Hi, I've updated the patches. I tested these, with the code as of a few hours ago, on both Mac and ubuntu-9.04 on vmware, and these work fine on both (with or without --with-eventinput configure option). Now I can say it is safe to apply, so please commit these patches. Don't forget to run autogen.sh after applying attached patches (with -p0 at the top directory of each project). I want to thank James Turner on this. He was kindly enough to make a test for me on a linux in VMWare on his Mac, and gave me the problem report (the order of static libs on linux), which reminds me that I also have VMWare! I, therefore, installed ubuntu-9.04 on it and made some tests. I got some linker errors during the tests so I fixed these. I believe these patches are really important for Mac users since they don't have to wait for my updating xcode project files. these also saves up to 50% of build time since most of users don't have to make universal binaries. Best, Tat flightgear-configure.diff Description: Binary data simgear-configure.diff Description: Binary data -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Patches for configure.ac/Makeifle.am in SG/FG
Hi,
I've updated the patches for configure.ac and Makefile.am files in FG/SG so Mac
developers can build these in a unix way.
These also enables Mac developers to choose either PLIB framework or PLIB
static libs.
The patches work fine on my Mac, and I want linux users to check if these also
work OK.
This update includes the changes to generic input device so it can be built
under both Linux and Mac.
Please let me know if there are any problems.
Torsten,
Could you check if the change to configure.ac and src/{Input, Main}/Makefile.am
work on Linux regarding to generic input?
If everything works fine, please commit these patches for me.
Best,
Tat
flightgear-configure.diff
Description: Binary data
simgear-configure.diff
Description: Binary data
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patches for configure.ac/Makeifle.am in SG/FG
Hi Torsten,
Thanks for your offer.
Of course I can wait.
Plus, James Turner was kindly enough to test my patches and it got a linker
error on SG,
so I need to fix the error (due to the order of static libs, I guess).
It may takes a few days, so no problem at all.
I'll repost the patches when it is fixed.
Best,
Tat
On Sep 10, 2009, at 4:38 AM, Torsten Dreyer wrote:
Hi,
I've updated the patches for configure.ac and Makefile.am files in FG/SG so
Mac developers can build these in a unix way. These also enables Mac
developers to choose either PLIB framework or PLIB static libs.
The patches work fine on my Mac, and I want linux users to check if these
also work OK. This update includes the changes to generic input device so
it can be built under both Linux and Mac. Please let me know if there are
any problems.
Torsten,
Could you check if the change to configure.ac and src/{Input,
Main}/Makefile.am work on Linux regarding to generic input? If everything
works fine, please commit these patches for me.
Best,
Tat
Hi Tat,
I'll have a look at your changes, but probably not before the weekend.
Hope you can wait that long ;-)
Greetings, Torsten
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Patch to fix a Keypad problem on Mac OS X
Hi there, On Mac OS X, FG doesn't handle number keys on Keypad properly. Attached is a patch for solving this problem (on src/Main/FGEventHandler.cxx), so please commit it. Here is the brief problem statement. FGEventHandler::handleKey converts KEY_KP_Insert ... KEY_KP_PageUp keys to '0' ... '9' when num-lock modifier is on However, Apple keyboard don't have Num-lock key so num-lock modifier never becomes true. As a result, Number keys on Keypad is ignored. My patch makes handleKey ignore num-lock modifier on Macs, which converts KEY_KP_XXX to '0'..'9' all the time. It works fine on my Mac and it doesn't affect other platforms. Best, Tat FGEventHandler.diff Description: Binary data -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: SimGear/simgear/math SGGeod.cxx, 1.1, 1.2 SGGeod.hxx, 1.10, 1.11 SGQuat.hxx, 1.16, 1.17 SGVec2.hxx, 1.7, 1.8 SGVec3.hxx, 1.20, 1.21 SGVec4.hxx, 1.14, 1.15
Hi James, I've tried, on my Mac OS 10.5/Xcode 3.1.1, FG/SG as of both Sep-06 and Sep-07 (without -DNO_OPENSCENEGRAPH_INTERFACE option) and all have worked fine so far. Does this have something to do with timing issue? Another thing I have in my mind is whether you disabled the HW mipmapping on osgViewer or not. As you already know, enabling HW mipmapping crashes FG, when splash screen disappears, on a Mac with some NVIDIA chip. Unfortunately my patch for solving this problem was rejected since OSG maintainer hates to import a workaround for a bug in HW / driver. This means you need to manually apply the patch when you get vanilla OSG code. If this is not the case, could you elaborate how you built fg/sg (e.g. with what patches or with what compiler/configure options)? Plus, If you post a crash log or gdb stack trace, maybe we can help you more. For seeing the build options and patches I use, you can get these from: http://macflightgear.svn.sourceforge.net/viewvc/macflightgear/trunk.tar.gz?view=tar Looking at patches/*, build.sh, localbuild.sh would be enough. tat On Sep 8, 2009, at 12:21 AM, James Turner wrote: On 7 Sep 2009, at 15:17, James Turner wrote: I'm still triple-checking that this is definitely the cause, re- building from clean, etc - since I admit the diff looks pretty safe to me. Tried a rebuild with GCC 4.2, which made no difference - memory/stack corruption happens as the splash screen would vanish (I think). I've looked more closely at the diffs, and tried some minor changes to see if I could affect the crash, but no luck so far. James -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 1.9.2 release for FSWeekend?
Hi, Though I prefer an official release, I can live with beta release so we can avoid killing Durk ;-) I guess it is a good to have a release (in either official or beta) since we can have lots of feedback reports that will improve the quality of FG for the scheduled release in the next Christmas. I also want to add that we have enough features and bug-fixes for beta release. Shader effects and generic input device are in progress, but I guess we can improve these by FSWeekend (or Christmas). I get lots of feedback reports from Mac users on every official release, but I have less than ten for every snapshot release. So cutting a release is more effective on Mac platform in terms of collecting feedback reports. By the way, is the version number going to be 1.9.2? I think it should be 1.10.0 since it is not a maintenance release. If we are going to have shadow effect working by Christmas, then we could go to 2.0.0. Best, Tat On Sep 6, 2009, at 9:36 PM, Tim Moore wrote: On 09/06/2009 08:13 AM, Durk Talsma wrote: Hi James, I'm certainly open to the idea, but I don't think I'm able to manage that, since I'm both primarily responsible for organizing FSWeekend, and have been coordinating the releases in the last few years as well. Having two deadlines come up at the same time, in addition to teaching four courses (of which two are new - lots of preparation), a deadline for a grant proposal, and a major review paper (both Sept 30), as well as serving on a PhD defense committee and preparing a symposium talk (Nov 2 and 3 respectively), I'm not sure whether I'm alive by the start of FSWeekend. :-) For this reason, my personal preference would be to continue regular development until FSWeekend, than allow us a few weeks for bugfixing and Beta testing. That would put the release around christmas time, which would be a lot more of an easy time for me. I agree with Heiko (see earlier post in this thread) that we should have a more careful beta testing period. Last year we had a few last minute check-ins that turned out to bite us. Let's try to circumvent that. I'd prefer to shoot for having a strong beta to show at FSWeekend, then do a release around Christmas. I suppose this implies a feature freeze in the release around the 1st of October. My preference would be to do the release like we did the maintenance release -- from a git branch that contains only selected patch sets from CVS. In order to get users to actually test the beta, do we need to essentially cut a release? Tim -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 1.9.2 release for FSWeekend?
Hi George, On Sep 6, 2009, at 10:38 PM, George Patterson wrote: On Sun, Sep 6, 2009 at 11:16 PM, Tatsuhiro Nishiokatat.fgmac...@gmail.com wrote: Hi,Though I prefer an official release, I can live with beta release so we can avoid killing Durk ;-) I guess it is a good to have a release (in either official or beta) since we can have lots of feedback reports that will improve the quality of FG for the scheduled release in the next Christmas. I also want to add that we have enough features and bug-fixes for beta release. Shader effects and generic input device are in progress, but I guess we can improve these by FSWeekend (or Christmas). If you wait until something has improved, then you are running a risk of never releasing something as it's still improving. I don't get what you mean by this, since none of my post above said to wait until improvement, didn't it? I said I'm for releasing, not for waiting. By the way, is the version number going to be 1.9.2? I think it should be 1.10.0 since it is not a maintenance release. If we are going to have shadow effect working by Christmas, then we could go to 2.0.0. Current release is 1.9.1 so I'd be happy with 1.9.2. Using 1.10 is out as it's less than 1.9.1. Which brings up a good question, do we call the next version of FlightGear 2.0? Maybe you misunderstand the versioning system. 1.10.0 IS newer than 1.9.1 with no doubt. if 1.10.0 is less than 1.9.1, then 10 is smaller than 9. Plus, 1.10.0 is very different from 1.1.0. We talked about how we should give a version number, and (I believe that) we ended up with the following consensus: Major version (first number) for big step: (e.g. shadows and landing lights for 2.0.0 IIRC) Minor version (second number) for feature improvement, basically for scheduled release. Micro version (third number) for maintenance release. This is why we got 1.9.1 after 1.9.0 (since it was a bug-fix version of 1.9.0). With this rule, the next release should be 1.10.0 (or 1.10.0 beta) unless shadows and landing lights will be implemented until then. If the next release actually is a maintenance release without new features like shaders and generic input device, then it will be 1.9.2. Tat -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] patch to solve a crash at exit
Hi, Glad to hear you kindly committed the patch. Thanks! I also want to thank you for committing my patch for Generic input device. Best Tat On 2009/09/04, at 14:43, Torsten Dreyer tors...@t3r.de wrote: I've found that FG crashes at exit at very high likelihood. Attached is a patch (for Main/globals.cxx) to fix this. Please commit this change. (snip) This happened to me sometimes, indeed. Good catch. Commited - Thanks Torsten -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Source code control systems
Hi there, First of all, I want to thank Curt for starting this discussion. I'm very glad to hear that you are willing to improve the current situation. Aside from the religious aspect of choosing a version control software (or whatever you name it), I want to say what should or can be improved in the current situation. As long as these things are (supposed to be) improved or resolved, any tool(s) work fine for me. 1) Response time Sometimes it takes very long for checking in or out the current repository. I've encountered time out and cannot check in or out. If moving the current repository to some other server(s) solve this problem, that's fine. 2) Permission problem Sometimes I've encountered errors in committing my local modification to the repository because of the lack of permission even one has a write access. When this happens, only Curt can fix the problem. This (including Curt's workload on this) must be improved. 3) Patches are sometimes not committed. I've seen some developers / contributers complain about their patches not being committed for a long time. Such incidents can affect the motivation of contributing to FG project. As a matter of fact, I, some time ago, posted a patch for configure.ac and Makefile.am so Mac users can build FG/SG using configure/make. However, it is not yet committed. If some tool can help in resolving such problem, that's very helpful. # I believe this is basically not a tool oriented problem, though. 4) No branches are made for making both release process and developing new features easier I believe that It is good to have a release branch while we are preparing for an official release since it doesn't prevent developers from committing a new features during the release process. I want to note that I don't say we need permanent development/release branches. You may have found that most (or all) of the issues above can be tool independent. I want to share these issues because it is very important to consider such issues when we choose a version control software, besides the pros and cons of each tool. Best, Tat p.s. Needless to say, a tool must work on Mac OS X ;-) On Sep 4, 2009, at 1:07 AM, Curtis Olson wrote: On Thu, Sep 3, 2009 at 4:10 AM, Tim Moore timo...@redhat.com wrote: It is important to remember that, unlike a personal religious choice like emacs vs. vi, the outcome of this religious debate will affect many people's daily interaction with Flightgear. In this way I suppose the debate is more like a religious war :) To dismiss the debate as merely religious is to ignore real technical arguments. At the end of the day, of course, a choice must be made that will leave some people unhappy, but I hope we can arrive there by listening to all sides. I only said that in attempt to deflect comments ahead of time from anyone who would immediately take this up as a religious war and choose to push the discussion in that direction. I really appreciate those that have responded professionally. This really helps to advance this discussion in a positive direction. It would be a pity to move from CVS and end up with SVN, even temporarily. First, let's be clear that some other system means Git. Several of us already use git for working with Flightgear. If anyone is using another system to interact with Flightgear's CVS, I'm not aware of it. There are at least two Git mirrors of of Flightgear and Simgear, so the conversion work has already been done. As long as this discussion is branching off in several directions, is it worth discussing mercurial versus git? code.google.com supports mercurial (hg). I have never used either. I've done a bit of googling, but much of the information I've found has been dated, or not written in a way that convinces me of the author's objectivity. The advantages of distributed version control systems over centeralized ones like SVN are numerous, and I won't hash them out here unless it becomes necessary :) code.google.com does support Mercurial (also known as Hg), and I would urge you to consider that as a target instead of SVN. That said, I have not used Hg; from what I have read, git's support for branching, merging, and preserving the history of merges is stronger. These features were very useful in creating the 1.9.1 maintenance release, where new development was able to continue on a mainline branch and specific fixes could be pulled into the maint branch, or made on the maint branch and merged to the mainline. For me, lack of Git support would be a deal breaker for code.google.com. From what I've read, hg and git seem to be converging in similar directions and each tool seems to be adding features to address their own weaknesses in comparison with the other. Just as I'm writing this I am remembering an old grad school class project I did with two other guys. We created a system based on CVS which would automatically replicate a CVS
[Flightgear-devel] patch to solve a crash at exit
Hi there,
I've found that FG crashes at exit at very high likelihood.
Attached is a patch (for Main/globals.cxx) to fix this.
Please commit this change.
The cause of the crash is that some subsystems (input and gui) call
get_subsystems() at their destructor.
This is very dangerous since SGSubSystemMgr::get_subsystem() can refer to
already deleted subsystems.
Here is the code related to this issue.
// (1) called when deleting subsystem_mgr (in FGGlobals::~FGGlobals)
SGSubsystemGroup::~SGSubsystemGroup ()
{
for (unsigned int i = 0; i _members.size(); i++)
{
_members[i]-printTimingStatistics();
// (Note 1): Subsystems are deleted here, but are not erased from
// SGSubsystemMgr::_subsystem_map that maps name with SGSubsystem *
delete _members[i]; // (2) this calls subsystem's destructor
}
}
// (3) called by some subsystem's destructor
SGSubsystemMgr::get_subsystem (const string name)
{
// (Note 2) this _subsystem_map.find(name) refers already deleted subsystems
// since the maps are not erased when deleting subsystems.
mapstring,SGSubsystem *::iterator s =_subsystem_map.find(name);
if (s == _subsystem_map.end())
return 0;
else
return s-second;
}
Reading methods above tells you how dangerous it is to call get_subsystem()
from subsystem's destructor.
If you have never encountered the crash by this issue, you're simply lucky
because the deleted objects still exist when referred.
Possible solutions are:
(a) change ~FGGlobals to clearly delete the relevant subsystems prior to
deleting subsystem_mgr
(b) change SGSubsystemMgr and SGSubsystemGroup to remove deleted subsystems
from their maps and vectors.
I chose (a) for this time.
Best,
Tat
globals.diff
Description: Binary data
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [DRAFT] generic input devices and hotplug support
Hi, Attached is a patch for FGMacOSXEventInput.[ch]xx Torsten, Could you commit it with the following comments: - Fixed: wrong event name for abs-hat0-y Modified: let AxisElement to generate normalized input (-1.0 to 1.0). This can be temporal and can be removed when AxisEvent normalizes its value. Modified: clean up code Added: some comments so other Mac developers can see what's going on - By the way, I found some differences between Linux and Mac OS X implementation, and want to hear some idea on how to eliminate the differences. 1. button index in FGLinuxEventInput.cxx the button index for misc usage begins from 0, but in USB specification, the index for button (on Button Usage Page) begins from 1 (same in FGMacOSXEventInput.cxx) This difference affects the compatibility (among OSs) of event configuration files. So I'm wondering which way we should follow. Maybe we should follow the linux way since it's easier to convert the existing joystick configuration files into new event configuration files. (button index in a joystick configuration file also begins from 0) What do you guys think? 2. event names for buttons of mice, joysticks (for generic desktop page), and gamepads At this moment, there's no button-left, button-right, etc in Mac OS X implementation. The same is applied for gamepad buttons, and joystick buttons. Instead, the button events are named like button-N regardless of device type. I guess it is easier to assign names in button-N format, but if we really need to clearly state button-left, or button-right, button-a, or button-trigger instead of button-N, then I'll add some code to generate these. I want to note that it is doable on Mac OS X by checking CA type of HID usage, but I'm not so sure if it is one-to-one relationship among HID usage and button names in all devices. if not, we must not use the linux way. We also needs to consider the possible Windows implementation. Any idea on this? Thanks in advance, Tat FGMacOSXEventInput.diff Description: Binary data -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [DRAFT] generic input devices and hotplug support
Hi, I've implemented Mac specific portion of generic input devices, and am testing it. The Mac specific source (including some local modification on FGEventInput.* and Makefile.am files) ATM are available at: http://macflightgear.sourceforge.net/wp-content/uploads/eventinput/FGMacEventInput.tgz The source files are still in progress, but these work fine on my Mac. Anyway, I have some questions and comments on this: 1. Is AxisEvent::fire suppose to set a raw input value (e.g. -1024 to 1024), or normalized value (-1.0 to 1.0) to its relevant node? I assume it's latter, but the normalization portion seems missing. If it is assumed that the OS specific FGInputDevice must pass a normalized input value to HandleEvent, then I'll add such code to FGMacOSXEventInput.cxx, but then FGAxisEvent's MinRange, MaxRange, etc will be useless. 2. /input/event/device[N]/event[M]/setting seems missing. Is such node set on Linux? It is good to have the setting for adjusting some control (like throttle using controls.throttleAxis()) 3. Hot plug thing seems missing, so I modified FGEventInput.* for attaching/detaching both property nodes and FGInputDevice. it works fine on Mac OS X, so please take a look at my FGEventInput.*[ch]xx. The key thing is that FGMacOSXInputDevice must know an index of a device node, device handler (Mac specific), and an instance of FGInputDevice. So I modified FGEventInput::AddDevice to return an index for the added device, and let FGMacOSXEventInput to map the index with a device handler. This allows me to find a node index when HID Manager tells me a device handler to be detached. By calling FGEventInput::RemoveDevice(index) will remove both FGInputDevice and its relevant property nodes. What do you think about this? 4. What is the naming convention for event names? I read Universal Serial Bus HID Usage Tables (http://www.usb.org/developers/devclass_docs/Hut1_12.pdf) but there's no -translate, -rotate things in its definition. I guess it is good to have some convention so we can add new events in a consistent fashion. I added some event names on my code, and most of the names (except the ones you defined) are directly converted from HID usage table's definition (by changing capital letters to small, replacing white spaces with '-' ). I'm not offensive so -translate or -rotate is ok, but I'm not so sure how to convert vrbx James, Thanks for your concern. Some portion of my code is based on PLIB's js implementation (like element enumerator, and opening device interfaces, etc) I'll ask you for some advice if needed. I wish I could use a new HID Manager code but it is only available on Mac OS 10.5 so I stay with old one. Best, tat On Aug 21, 2009, at 7:02 PM, Torsten Dreyer wrote: Hi, This indeed is a good idea. I took a look at the code, and I believe I can implement the Mac portion of the new input event model using HID Manager. I'll post the patch when I finish implementing it. - Tatsuhiro Nishioka Great! Looking forward to receiving your patch. Torsten -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Generic Input Support
Hi Jim,
Thanks for the info and the link to USB spec.
I'm not so sure if Windows need this table, but on Macs it's inevitable.
We also need to look up other usage pages like general desktop page (0x01),
buttons page
since many joysticks use these pages instead of simulation page.
FYI,
There is a newer version of HID usage table.
http://www.usb.org/developers/devclass_docs/Hut1_12.pdf
Best,
Tat
On Aug 7, 2009, at 5:37 PM, Jim Campbell wrote:
Hi,
The HID Usage Tables (extracted from MacOSX) incude a sub-section
specifically for Simulation:
/* Simulation Page (0x02) */
/* This section provides detailed descriptions of the usages employed
by simulation devices. */
enum
{
kHIDUsage_Sim_FlightSimulationDevice= 0x01,/* Application
Collection
*/
kHIDUsage_Sim_AutomobileSimulationDevice= 0x02,/* Application
Collection */
kHIDUsage_Sim_TankSimulationDevice = 0x03,/* Application
Collection */
kHIDUsage_Sim_SpaceshipSimulationDevice= 0x04,/* Application
Collection */
kHIDUsage_Sim_SubmarineSimulationDevice= 0x05,/* Application
Collection */
kHIDUsage_Sim_SailingSimulationDevice = 0x06,/* Application
Collection
*/
kHIDUsage_Sim_MotorcycleSimulationDevice= 0x07,/* Application
Collection */
kHIDUsage_Sim_SportsSimulationDevice= 0x08, /* Application
Collection
*/
kHIDUsage_Sim_AirplaneSimulationDevice= 0x09, /* Application
Collection */
kHIDUsage_Sim_HelicopterSimulationDevice= 0x0A,/* Application
Collection */
kHIDUsage_Sim_MagicCarpetSimulationDevice= 0x0B,/* Application
Collection */
kHIDUsage_Sim_BicycleSimulationDevice = 0x0C,/* Application
Collection
*/
/* 0x0D - 0x1F Reserved */
kHIDUsage_Sim_FlightControlStick= 0x20,/* Application
Collection */
kHIDUsage_Sim_FlightStick = 0x21, /* Application Collection */
kHIDUsage_Sim_CyclicControl = 0x22, /* Physical Collection */
kHIDUsage_Sim_CyclicTrim= 0x23, /* Physical Collection */
kHIDUsage_Sim_FlightYoke= 0x24, /* Application Collection */
kHIDUsage_Sim_TrackControl = 0x25, /* Physical Collection */
/* 0x26 - 0xAF Reserved */
kHIDUsage_Sim_Aileron = 0xB0, /* Dynamic Value */(
kHIDUsage_Sim_AileronTrim = 0xB1, /* Dynamic Value */
kHIDUsage_Sim_AntiTorqueControl = 0xB2,/* Dynamic Value */
kHIDUsage_Sim_AutopilotEnable = 0xB3, /* On/Off Control */
kHIDUsage_Sim_ChaffRelease = 0xB4, /* One-Shot Control */
kHIDUsage_Sim_CollectiveControl = 0xB5,/* Dynamic Value */
kHIDUsage_Sim_DiveBrake = 0xB6, /* Dynamic Value */
etc. etc.
A google search for Universal Serial Bus HID usage will reveal a pdf
document www.usb.org/developers/devclass_docs/Hut1_11.pdf (159 pages so
not included) and it would be useful for cockpit building if some of
these could be recognised, especially pages 0x01(generic) and
0x02(simulation) (see specificially the table on page 36 of the
document)!!
cheers
Jim
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [DRAFT] generic input devices and hotplug support
Hi, On Aug 28, 2009, at 4:28 AM, Torsten Dreyer wrote: thanks for that - it looks like you spent a lot of time on it ;-) I will soon merge your updates into my code which has changed a little bit since the last cvs commit. I hope to get it done by the weekend. Do you think your FGMacOSXEventInput.?xx is ready for CVS? I modified these a bit and I guess these are ready now. The updated files are available at: http://macflightgear.sourceforge.net/wp-content/uploads/eventinput/FGMacEventInput-20090827.tar.gz I also modified your code to eliminate compilation errors (linux headers in FGEventInput.cxx) and warnings (the order of initializing member variables), so please merge these portions to your code. btw, Makefile.am files are my local use only, so don't commit these. # I'll also make a patch so Mac users can build FG with configure/make. Anyway, I have some questions and comments on this: 1. Is AxisEvent::fire suppose to set a raw input value (e.g. -1024 to 1024), or normalized value (-1.0 to 1.0) to its relevant node? I assume it's latter, but the normalization portion seems missing. If it is assumed that the OS specific FGInputDevice must pass a normalized input value to HandleEvent, then I'll add such code to FGMacOSXEventInput.cxx, but then FGAxisEvent's MinRange, MaxRange, etc will be useless. Currently the value is not normalized. To do so, we have to scale the value by the minimum/maximum values delivered from the HID report descriptor. Not sure, if it's physical or logical max/minimum. To be consistent within FlightGear we should normalize the value. I guess you can get min/max values using ioctl, but not that sure.. maybe we can use the similar idea that PLIB's jsJoystick::fudge_axis does. Though we can let users define min/max things in xml files, it's way better to normalize axis inputs without using xml tags. 2. /input/event/device[N]/event[M]/setting seems missing. Is such node set on Linux? It is good to have the setting for adjusting some control (like throttle using controls.throttleAxis()) Good point - I will add it. Glad to hear that! 3. Hot plug thing seems missing, so I modified FGEventInput.* for attaching/detaching both property nodes and FGInputDevice. it works fine on Mac OS X, so please take a look at my FGEventInput.*[ch]xx. The key thing is that FGMacOSXInputDevice must know an index of a device node, device handler (Mac specific), and an instance of FGInputDevice. So I modified FGEventInput::AddDevice to return an index for the added device, and let FGMacOSXEventInput to map the index with a device handler. This allows me to find a node index when HID Manager tells me a device handler to be detached. By calling FGEventInput::RemoveDevice(index) will remove both FGInputDevice and its relevant property nodes. What do you think about this? That's perfect. I admit being lazy and not having implemented hotplug yet ;-) Your RemoveDevice is a good start. Great! I haven't test with more than one plug-able HID devices, so we need to carefully see what happens when device[0] is unplugged and device[1] stays plugged. Maybe device[0] is removed but device[1] is there, and when you plug it again, device[0] shows up again. 4. What is the naming convention for event names? I read Universal Serial Bus HID Usage Tables (http://www.usb.org/developers/devclass_docs/Hut1_12.pdf) but there's no -translate, -rotate things in its definition. I guess it is good to have some convention so we can add new events in a consistent fashion. I added some event names on my code, and most of the names (except the ones you defined) are directly converted from HID usage table's definition (by changing capital letters to small, replacing white spaces with '-' ). I'm not offensive so -translate or -rotate is ok, but I'm not so sure how to convert vrbx We shall take care that the same device generates the same named event on every operating system. The HID report should assist us in that - the USAGEs describes the event. The usages X, Y, Z are for linear translation along the x,y,z axes while RX, RY and RZ are rotation around the axes. Hence the names -translate and -rotate ;-) I used the event names defined in the linux/input.h from the linux kernel. But I am open for other/better sugestions. I also want to know if the event names that I defined are acceptable. most of these are directly converted as I mentioned but some are translated likely-torsten way :-) I also added button- prefix to some OSC/OOC type of elements, but these can be omitted. The problem here is I have only a few devices and I can't test many events to see if I name these properly. Best, Tat -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best,
Re: [Flightgear-devel] [DRAFT] generic input devices and hotplug support
Hi, This indeed is a good idea. I took a look at the code, and I believe I can implement the Mac portion of the new input event model using HID Manager. I'll post the patch when I finish implementing it. - Tatsuhiro Nishioka On 2009/08/05, at 5:37, Torsten Dreyer tors...@t3r.de wrote: I Just found out that my notebook's lid switch is an input device: I: Bus=0019 Vendor= Product=0005 Version= N: Name=Lid Switch P: Phys=PNP0C0D/button/input0 S: Sysfs=/devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input5 U: Uniq= H: Handlers=event5 B: EV=21 B: SW=1 So - FlightGear now pauses when I close my notebook's lid. This could be very useful when running FlightGear at work and the boss suddenly shows up on a short final... --- --- --- - Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New member...and questions ;-)
Hi Oliver Welcome to FG world. I use vstab for lower wing on K5Y1 (Aka Tombo). You can see K5Y1.xml to find what should be done. The latest K5Y1 is available at CVS and: http://macflightgear.sourceforge.net/home/aircraft/k5y1 There're some points you need to know: - dihedral must be clearly specified, otherwise it will be set to 90 degree. - two vstab tags are needed (for left wing and right wing) since vstab will not be mirrored. - some attributes must be negative for the right wing (since dihedral 90) I put incidence attribute to vstab, but I'm not that sure if it works properly. Does anyone know about this? If none knows, I'll take a look at Yasim code some time later (I have no time tonight...) Hope it helps. Tat On Jun 26, 2009, at 9:04 PM, Olivier Faivre wrote: Interesting. Will try both possibilities. if mstab is not use by the solver, What about biplane ? Not so clear anymore in my mind... However, if i cannot set incidence to the mstab, my idea is dead... Olivier 2009/6/26 leee l...@spatial.plus.com On Thursday 25 Jun 2009, Maik Justus wrote: Hello Olivier, Olivier Faivre schrieb am 25.06.2009 20:52: Hello guys, ... Actually, the wing is done with only one piece, 7° dihedral, no twist. Can I use the mstab command to specify the outer wing and the regular wing command for the inner one ? yes In the readme file, I read this for mstab : these surfaces are not involved with the solver computation these surfaces are not involved with the solver computation... I'm not sure to well understand. if you define a yasim FDM you have to define two configurations with different airspeed, typ. cruise and approach. Yasim modifies lift and drag factors and the incidence of the wing to meet these configurations. Therefore the incidence of a wing will be modified by the yasim solver (only once - when the model is loaded) while the incidence of a mstab is unchanged. I just thought I'd point out that the YASim solver sets the incidence for the hstab element, not the wing element. Thus, you can specify the incidence for the wing, but not for the hstab. There is also an INCIDENCE control-axis in YASim, which should allow the wing element incidence to be changed in flight and I think the F-8E, which is shown on the FG aircraft download web-page, may actually use this. However, when I've tried using the INCIDENCE control-axis with vstab or mstab elements, to simulate all-moving/slab tailfins/rudders (as in the BAC-TSR2) or all-moving canards (as in the SU-37) it has had no aerodynamic affect at all. YASim does indeed generate drag factors for wing, vstab and mstab elements, but it is possible to modify the the AoA related drag forces by including suitable idrag elements . This seems to work well when you're trying to simulate all-moving tailplanes, for example, if you specify a very low idrag factor for the hstab element. I also experimented with using mstabs to more accurately model the correct shape of wings when developing the Canberra-B(I)8 YASim config but found that the solver does indeed ignore the mstab elements when working out its stuff. While I could get it to solve, the effect was that of just having the very short inner wing panels. The vstab and mstab elements do have directional effects however, and the control-surface sub-elements, such as flapn and spoiler will also have an effect. For the main lifting surface then, using a full-span wing element will give more accurate results than a combination of wing and mstab elements because the mstab elements will be ignored. Although this may seem less than ideal, it's possible to fine-tune the single wing element to get very close to the real world characteristics, and certainly closer than you could get with a wing and mstab combination. LeeE -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] configure/Makefile.am patches for Mac OS X
Hi there, I've made patches for configure.ac and Makefile.am on both FG and SG for Mac OS X. Here are the patches: http://macflightgear.svn.sourceforge.net/viewvc/macflightgear/trunk/patches/flightgear-configures.diff http://macflightgear.svn.sourceforge.net/viewvc/macflightgear/trunk/patches/simgear-configures.diff The changes include: - handles PLIB.framework when --with-plib-framework= option is specified you can also use static PLIB libs with --with-plib= is option. - links PLIB/OSG/OpenThreads frameworks only when needed The current configure on FG force links all executables against all osg frameworks, but this is painful since some command-line tool's icon pops up on the Dock and that captures keyboard/mouse focus. This change needs to modify some Makefile.am files. I've tested on my Mac and it works very fine. Now I want unix users to test these patches for checking if these don't affect anything on non-Mac environment. If everything goes well, I'd like someone to check this in. For Mac developers: You can build the latest fgfs in a unix way without waiting for my synchronizing xcode project files. I wrote a brief document for building fgfs with one script, which is available at: http://macflightgear.sourceforge.net/home/documents/how-to-build-flightgear-cvs-in-a-unix-way/ If you want to have a bundle, copy all binaries under /usr/local/FlightGear/bin to /Applications/FlightGear.app/Contents/Resources. If you build the newer OSG or PLIB than ones come with FlightGear/CVS package, overwrite frameworks to /Applications/FlightGear.app/Contents/Frameworks Best, Tat -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] startup.nas
Hi there, On Jun 15, 2009, at 4:12 AM, Torsten Dreyer wrote: I've had another error message for the last few weeks while starting FG , Nasal runtime error: nil used in numeric context at data/Nasal/startup.nas , line 12 I've encountered exactly the same problem. I'm not so sure what it should look like, but at least it needs nil check for the property. Another solution can be setting 0 to the property at the beginning. setprop(/environment/metar/base-wind-speed-kt, 0.0); before set_runway_from_metar_wind() is called. Melchior, what do you think is the better solution for this? Tat so it looks like environment/metar/base-wind-speed-kt is still nil when read the first time ... I fixed it locally , but not sure who added it , so I'll leave it alone That's my fault for sure. This node is not initialized before a valid metar has been decoded. The boolean property /environment/metar/valid is true if the properties under /environment/metar are filled from a valid metar. So - if a valid metar has not (yet) been received from noaa, there is no wind-speed and no wind-range. Probably startup.nas should wait for /environment/metar/valid to become true before using the wind-speed and wind-range nodes. Maybe Melchior has a good idea how to do this? Torsten -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] crash after several seconds after Pilot List dialog shows up.
Hi there,
I got a problem on pilot list, which crashes fgfs several seconds after the
dialog shows up.
The crash dump and some info on gdb below shows Null pointer assignment
(iter-second = NULL).
This problem happens with fgfs as of June 13th, but doesn't happen with one as
of May 19th,
so some changes between these two dates have something to do with this problem.
I've started investigating on this but not yet reached the real cause.
Does anyone knows anything on this?
FYI, I attached the excerpt cvs logs of FG and SG at the bottom (from May 19th
to June 13th)
--
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x
0x0033bf53 in NewGUI::update (this=0x2493f840,
delta_time_sec=0.10001) at new_gui.cxx:124
124 iter-second-update();
(gdb) info stack
#0 0x0033bf53 in NewGUI::update (this=0x2493f840,
delta_time_sec=0.10001) at new_gui.cxx:124
#1 0x006c7a1f in SGSubsystemGroup::Member::update (this=0x2493f8f0,
delta_time_sec=0.10001) at subsystem_mgr.cxx:306
#2 0x006c92c5 in SGSubsystemGroup::update (this=0x202da50,
delta_time_sec=0.10001) at subsystem_mgr.cxx:159
#3 0x006c7c9e in SGSubsystemMgr::update (this=0x202da30,
delta_time_sec=0.10001) at subsystem_mgr.cxx:390
#4 0x6f13 in fgMainLoop () at main.cxx:460
#5 0x0005f5c1 in fgOSMainLoop () at fg_os_osgviewer.cxx:179
#6 0x372c in fgMainInit (argc=6, argv=0xb724) at main.cxx:1004
#7 0x283b in main (argc=6, argv=0xb724) at bootstrap.cxx:216
(gdb) p *iter
$13 = (class std::pairconst std::basic_stringchar, std::char_traitschar,
std::allocatorchar ,FGDialog* ) @0x4a2389c0: {
first = {
static npos = 4294967295,
_M_dataplus = {
std::allocatorchar = {
__gnu_cxx::new_allocatorchar = {No data fields}, No data
fields},
members of
std::basic_stringchar,std::char_traitschar,std::allocatorchar
::_Alloc_hider:
_M_p = 0x4a4953cc who-is-online
}
},
second = 0x0
}
Log:
Dave LUFF: Fix buffer overrun with longer runways
Modified files:
Instrumentation/dclgps.cxx on date: 2009/06/01 10:32:44 author: mfranz as
revision 1.17
Log:
Also take the current BVH nodes transform into account.
Modified files:
FDM/groundcache.cxx on date: 2009/06/07 11:24:42 author: frohlich as
revision 1.44
Log:
Remove unused header.
Modified files:
Scenery/scenery.cxx on date: 2009/06/06 07:46:08 author: frohlich as
revision 1.29
Log:
new command line option --metar=some metar
new handling of real-weather-fetch
major code cleanup
Modified files:
Environment/environment_mgr.hxx on date: 2009/05/29 10:26:35 author: torsten
as revision 1.9
Environment/fgclouds.cxx on date: 2009/05/29 10:26:35 author: torsten as
revision 1.29
Environment/fgclouds.hxx on date: 2009/05/29 10:26:35 author: torsten as
revision 1.16
Environment/fgmetar.hxx on date: 2009/05/29 10:26:35 author: torsten as
revision 1.4
Main/options.cxx on date: 2009/05/29 10:26:36 author: torsten as revision
1.121
Log:
immediately fetch a metar if real-weather-fetch is re-enabled at runtime
Modified files:
Environment/environment_ctrl.cxx on date: 2009/06/08 19:39:37 author:
torsten as revision 1.74
Environment/environment_ctrl.hxx on date: 2009/06/08 19:39:37 author:
torsten as revision 1.38
Log:
No need to zero the _props variable.
This reference is released by the SGSharedPtr destructor anyway.
Modified files:
Scripting/NasalSys.cxx on date: 2009/06/07 11:23:54 author: frohlich as
revision 1.125
Log:
Remove dead variables.
Modified files:
Model/acmodel.cxx on date: 2009/06/11 09:19:32 author: frohlich as revision
1.24
Model/acmodel.hxx on date: 2009/06/11 09:19:32 author: frohlich as revision
1.13
Log:
Replace plain doubles with SGGeod in FGViewer for position and target pos.
Modified files:
Main/viewer.cxx on date: 2009/06/09 12:15:48 author: jmt as revision 1.36
Log:
Upgrade to JSBSim 1.0-prerelease
Modified files:
FDM/JSBSim/FGFDMExec.cpp on date: 2009/06/01 08:52:34 author: ehofman as
revision 1.31
FDM/JSBSim/FGFDMExec.h on date: 2009/06/01 08:52:35 author: ehofman as
revision 1.17
FDM/JSBSim/FGJSBBase.h on date: 2009/06/01 08:52:35 author: ehofman as
revision 1.27
FDM/JSBSim/JSBSim.cxx on date: 2009/06/01 08:52:35 author: ehofman as
revision 1.57
FDM/JSBSim/initialization/FGInitialCondition.cpp on date: 2009/06/01 08:52:37
author: ehofman as revision 1.11
FDM/JSBSim/initialization/FGInitialCondition.h on date: 2009/06/01 08:52:37
author: ehofman as
Re: [Flightgear-devel] Mac crashes / corruption with CVS
Hi, On Jun 17, 2009, at 6:44 AM, Jari Häkkinen wrote: I am working on such scripts and writing a short document describing the process of using the different repos (osg, simgear, fg, ...) to build a fg on mac without Xcode. For the OSXLauncher and creating creating a bundle I use Xcode. I'll send you the docs when they are more mature. Great to hear that. Btw, Did you read my recent post about this script? http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg22570.html I made one so please give it a try. I also wrote a brief document and is available at: http://macflightgear.sourceforge.net/home/documents/how-to-build-flightgear-cvs-in-a-unix-way/ Tat -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mac crashes / corruption with CVS
Hi James, I reinstalled Leopard and the problem seems resolved so far. I'll apply the 10.5.6 combo update and see how it works tomorrow. Forgive my very slow work. I don't have much time doing this. I'll also manually update and x11 from 10.5.7 update package. There is some nice tool to do so, but I prefer pkgtool + gzcat | cpio + cp way for doing so. I'll let you guys know how it works as well, hopefully tomorrow. Tat - Tatsuhiro Nishioka On 2009/06/16, at 22:30, James Turner zakal...@mac.com wrote: On 16 Jun 2009, at 13:32, Tatsuhiro Nishioka wrote: I think it might be a problem on nVidia driver update that Apple released after 10.5.6 update. I have an iMac with nVidia GT7300, and it also has the same problem as James has. This makes me really happy, since it means my specific system isn't broken! This problem happens not only on FG but also on some other OpenGL based applications. On my end, ac3d locks up after some minutes or some seconds of use. Interesting, this suggests whichever OpenGL apps I tested, don't trigger the problem. Hmmm. In such case I see tons of OpenGL exceptions at /var/log/system.log (of course via ssh). I'll look for these next time, of course. On my end solution 1 and 2 didn't work, so will try 3 and 4 maybe tomorrow. Urk, an OS downgrade would be tricky for me - i'm doing iPhone dev for work, and I think I need 10.5.7 to run iTunes 8.2, to run the right iPhone SDK... I also found some web article shows that Apple stopped distributing the nVidia driver update after several days from its release due to tons of complaints. Of this is true, it can be the key to explain the different situation between Jari and us. Or possibly it only affects 7xxx generation nVidia chips, and Jari's 8600 is a separate module/sub-module. I don't know enough about nVidia's driver architecture to guess that, though. I could be lazy and use this as an excuse to buy a Radeon 3870 (or 4870 if I'm feeling rich!). But in general nVidia has been better to me than Ati ... though at the moment, on Mac, I would tend to agree Ati is looking in better shape. Regards, James --- --- --- - Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] unix way of building fgfs for Mac OS X
Hi there, I've been trying a unix way of building FlightGear for my daily/debug use, and I managed to reach a solution for intel Macs with OS X 10.5.x. So I added helper scripts to macflightgear's repository for doing download, patch, and build in one command! You can download the build package (including xcode projects) from: http://macflightgear.svn.sourceforge.net/viewvc/macflightgear/trunk.tar.gz?view=tar untaring this will make trunk folder. To build fgfs, you type the following command under trunk folder (of course without $) in Terminal.app. $ sh ./localbuild.sh Then it magically builds everything. You need to type your password when asked (for a few times I guess). this is needed for installation and applying a patch to broken OpenAL.framework header file. After a while, you'll get fgfs in /usr/local/bin. To launch fgfs, you'll need to do: $ DYLD_LIBRARY_PATH=/usr/local/OpenSceneGraph/lib /usr/local/FlightGear/bin/fgfs --fg-root=/usr/local/FlightGear/data it is a bit long command, so making an alias command or a script will help you. Though the script still relies on macflightgear's svn repository due to Mac specific patches that conflicts with original FG/SimGear and fancy downloading mechanism, it is good that you don't have to wait for my updating XCode projects and directly build the latest FG/CVS on your end. It also saves your time in downloading everything you need. That's way handy, isn't it? Plus, you can also clean up everything using localclean.sh. Details are written in localbuild.sh, but I give you some usages: For taking a build log, try: $ sh ./localbuild.sh build.log 21 For updating source, data, and rebuilding fgfs, you can try: $ sh ./localbuild.sh --skip=patch For skipping a certain build process, you can try $ sh ./localbuild.sh --skip=download,patch,plib,osg This will skip downloading, patching, building plib and osg. If you want to have a debug version of fgfs, or want to build for ppc, then you need to change localbuild.sh See localbuild.sh for more detail. I need to patch Simgear's configure.ac and some Makefile.am at this moment, but will try modifying these so it works on both Mac and unix varients. More effort is needed for building OS X bundle and/or for ppc Macs with this way, but will take a while, so please be patient. Best, Tat p.s. Jari and James, Could you guys try this script? -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mac crashes / corruption with CVS
Hi, I think it might be a problem on nVidia driver update that Apple released after 10.5.6 update. I have an iMac with nVidia GT7300, and it also has the same problem as James has. This problem happens not only on FG but also on some other OpenGL based applications. On my end, ac3d locks up after some minutes or some seconds of use. In such case I see tons of OpenGL exceptions at /var/log/system.log (of course via ssh). Googling gave me some possile solution candidates: 1) PRAM reset 2) reinstall 10.5.6 combo update to bring driver back to the old one. 3) archive install and apply 10.5.6 combo update 4) use hardware test on installation disk 5) yell at Apple on this ;-) On my end solution 1 and 2 didn't work, so will try 3 and 4 maybe tomorrow. I also found some web article shows that Apple stopped distributing the nVidia driver update after several days from its release due to tons of complaints. Of this is true, it can be the key to explain the different situation between Jari and us. I don't see any GUI lockups on my MacBook pro/ATI and MacBook/GMA. Now I hate nVidia (or should I hate Apple that doesn't provides any solution yet?) By the way, I agree with Jari's opinion. I guess I need to add some script or document for building a local fgfs. I use mac specific repository since I need to make Universal binary with GUI launcher for both Tiger and Leopard. Thus the manual building instruction for the latest CVS is very complicated. But many users need fgfs/CVS that runs only on their system. I'll do something on this issue, hopefully soon. - Tatsuhiro Nishioka On 2009/06/16, at 17:38, James Turner zakal...@mac.com wrote: On 16 Jun 2009, at 00:47, Jari Häkkinen wrote: The reason for doing the above is that I do not like the macflightgear strategy of having snapshot copies of different fg components in the macflightgear repository. Also, getting access to all new stuff takes a while since the macflightgear maintainer must update the repo. Last week I realized that I miss the OSX lancher. I checked out the OSX launcher from the repository (trunk branch ... I don't get latest fixes to the launcher :-0), hacked around with the Xcode stuff and now I have an application bundle. Unfortunately I only bundle minimum amount of information and use links to fg/data and some other things which makes the current bundle non-distributable. In the short-term, I don't care about Atlas, terragear or the Macflightgear launcher - so perhaps you could send me your update-and- build script (that you use for the development version), and I can modify it to work locally. That wouldn't answer the binary question, but it might expose any compile-option strangeness that could be causing my crashes. Also, you could send me your compiled fgfs binary (and any dynamic dependencies) - I can test that without you needing to produce a viable application bundle. All this is only if you have time, of course - thanks for your help in figuring this out. James --- --- --- - Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mac crashes / corruption with CVS
Jari, On Jun 16, 2009, at 8:47 AM, Jari Häkkinen wrote: Last week I realized that I miss the OSX lancher. I checked out the OSX launcher from the repository (trunk branch ... I don't get latest fixes to the launcher :-0), FYI, the latest fix on GUI launcher is in macflightgear's svn trunk and 1.9.1 branch. in trunk, it was fixed on rev 213. You can get svn/head of macflightgear from: http://macflightgear.svn.sourceforge.net/viewvc/macflightgear/trunk.tar.gz?view=tar The head is for sources as of June 13th. best, Tat -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Generic fcs,nas
Hi Lee, Thanks for your opinion. I totally agree with that. At this moment, it is generic fcs among fcs capable helicopters, but not enough for all fcs capable aircraft. So Helijah renamed it to helicopter-fcs.nas. Then I updated it to the latest version. For those who use Aircraft/Generic/fcs.nas or who have clone fcs.nas originally from OH-1: Please change -set.xml so it refers to Aircraft/Generic/helicopter-fcs.nas Best, Tat On Jun 11, 2009, at 10:15 PM, leee wrote: Hi list, I noticed the Generic fcs.nas, and an update to it, going through on cvs-logs and a potential problem occurs to me... Although it's called Generic, I noticed that it seems to be specifically for helis. Assuming that fixed-wing and LTA FCSs will someday turn up, perhaps it might be a good idea to think in terms of either re-naming the current 'Generic' FCS so that it's clearly a generic Heli FCS, or re-designing the 'Generic' FCS so that it is modular, with truly generic modules, applicable to any type of vehicle, and separate vehicle type-specific modules. LeeE -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear/CVS binary package for Mac OS X as of May 19th, 2009
Hi there, After a long absence from the internet due to my moving-house process, I'm back on track, and the latest cvs binary package for Mac OS X is available. You can download the package from: http://macflightgear.sourceforge.net/flightgear-cvs-bin-20090519-has-been-released If you have any problem downloading the file, go visit: https://sourceforge.net/project/showfiles.php?group_id=126825package_id=212565release_id=683768 best, Tat --- Tatsuhiro Nishioka http://macflightgear.sourceforge.net/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Bug fix for FlightGear-1.9.1 GUI Launcher for Mac OS X
Hi, I got some user reports that show a weird option misinterpretation on the GUI launcher for Mac OS X. The problem is that a certain option is sometimes ignored and falls back to its default value even you clearly specify one on the GUI launcher. Possible options to be ignored are such as multi-play switch, aircraft, airport, and time-of-day. You can download the update package from: http://macflightgear.sourceforge.net/wp-content/uploads/launcher/1.9.1/GUIUpdater-1.9.1-r214.tar.gz See the instruction below for updating the GUI launcher for 1.9.1: 1. Launch FlightGear.app 2. Open Advanced Options Others Install Add-on data 3. Choose GUIUpdater-1.9.1-r214.tar.gz (You'll see a message when the update is done.) 4. Restart FlightGear.app Note: Don't forget to restart FlightGear.app. Best, Tat p.s. GUI launcher's revision number is not updated on About dialog, but you can see it by viewing INFO of FlightGear.app by doing Ctrl-click on FlightGear.app icon. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] RFC: graphics effects files
Hi again,
On 2009/04/07, at 21:04, Tim Moore timo...@redhat.com wrote:
Tatsuhiro Nishioka wrote:
As Melchior alrwady said, the new format has nothing to do with what
Tim really wants (performance improvement). A node with 3 or 4 float
numbers can be converted into a vector class internally in C++ code
without the new vector format inside an XML tag.
I've explained before why this is approach is messy and has
performance
implications in OSG. If you want to see this strategy in action,
look at
scene/model/SGMaterialAnimation.cxx and the hundreds of lines of code
that are needed to bridge the difference between colors represented as
discrete properties and vector colors in OSG.
What about this way?
Say you have your own material class(e.g.
SGMaterial, or whatever you name it) inherited from osg::Material
class so you may access the protected color vectors like _ambient,
_emission, etc.
SGMaterial has its own vectors (or a float array) for tying 'rgba's in
the property tree (say _ambient_prop, _emission_prop). The class can
also have setters / getters for r,g,b,a, factor and offset if you want
to avoid updating color vectors on every frame.
Separating tying/setters/getters portion of code into another class
(like ColorSpec) may reduce some amount of code since you can reuse
the typing/setter/getter code for different color vectors like ambient
and emission.
As a result, you can save 4 or 5 vector passing into OSG every time
UpdateCallback is called from osg. It also saves several property
references by calling getFloatValue since each element in
_ambient_prop (and so on) is tied to property system. It can't save
the memory for extra vectors (like _ambient_prop) since each color
value is calculated by {r,g,b} * factor + offset, and the rgb value
needs to be tied to the property system.
This way you can improve the performance without making a new vector
format inside XML tag.
# I wish I could send you a code snippet on this but forgive me since
I send this from my iPhone.
Moreover, the new vector format doesn't improve the usability at all.
a user-defined text format inside an XML tag is not recommended since
it decreases the readability unless you give a comment, which is way
not better than using tags. If we really need more concise format
that
improves usability, then we need to throw away our current xml files
and make new files in our own new format, which I believe is
nonsense.
This is the COBOL and Java idea that locally simple, self
documenting
syntax improves readability. I simply don't buy it because the
resulting loss
of abstraction means that the total amount that a user needs to
absorb in
order to understand a program increases dramatically. Now, it may be a
lost cause to try to improve an XML-based file format, but I feel that
it is worthwhile to try.
Could be, but my way, and some other ways, can be also worthwhile to try.
What I want to say is that changing a text format inside XML is the
last option to take. But boy, your idea saves a lot of CPU time and
memory considering a number of materials in FG. Good indeed.
The new format also needs a parser, property browser changes, and
converter(s) that don't help us improve any usability or performance
at runtime, I guess. If such new format gives us some usability or
performance improvement, I can accept it even if some extra work is
required, but this is not the case.
These changes are very small, as can be seen in my code. If they
weren't,
I wouldn't have been tempted to mess with the property system.
That's a good news. I'll take a look at your code when I can see it
via a real network.
Or, Is there any URL that I can see your own code in a plain text/html format?
iPhone can access most of web sites but it can't use git to get your files.
My proposed usage is just as local, except that eventually I want to
change effects properties from Nasal code.
Then it is not just local, and you need to make colors accessible via
the property tree.
Anyway, I really like your basic idea. And I hope my idea can be a way
to satisfy you both.
Best,
Tat
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
Hi, I agree with those who are against the proposed new vector format even though I like Tim's basic idea that improves vector calculation performance. As Melchior alrwady said, the new format has nothing to do with what Tim really wants (performance improvement). A node with 3 or 4 float numbers can be converted into a vector class internally in C++ code without the new vector format inside an XML tag. Moreover, the new vector format doesn't improve the usability at all. a user-defined text format inside an XML tag is not recommended since it decreases the readability unless you give a comment, which is way not better than using tags. If we really need more concise format that improves usability, then we need to throw away our current xml files and make new files in our own new format, which I believe is nonsense. The new format also needs a parser, property browser changes, and converter(s) that don't help us improve any usability or performance at runtime, I guess. If such new format gives us some usability or performance improvement, I can accept it even if some extra work is required, but this is not the case. The JSBSim's table format, which I believe, also lacks the readability. It ,however, gives aircraft developers some usability like easier to copy and paste some table data from external tools like javaprop or excel. I know some helper script can create a well- formatted XML tags, but it could be true that many aircraft developers like simple copy-paste things while tweeking prop/engine things tons of times a day. Nevertheless to say, these tables don't need converters or browser changes since these are only read at launch time, and are not readable from the property browser or telnet. So comparing JSBSim table and the vector format doesn't seems fair to me. I hope many people understands what Melchior said on the property system. His going home thing didn't mean that he just wants to hide away unless his opinion is accepted, but he wanted to say the proposed vector format is that bad in terms of software architecture. He might be sometimes brutal in his written words, but I really like his software architecture related comments. These are almost always right, at least to me. I don't say anything on his other comments though :-p Tat p.s. I've moved and my network connection is limit only to iphone until at the end of this month. Sorry for my vry slow response, especially to Mac users. - Tatsuhiro Nishioka On 2009/04/06, at 5:33, Erik Hofman e...@ehofman.com wrote: Curtis Olson wrote: This isn't an argument for or against Tim's proposal in and of itself, but it's at least interesting to observe other real world cases that are at least partially similar. Has JSBSim run into any problems with it's journey down this path? This has been one reason why I have been cautious about including it, this setup does tend to result more errors than laying it down is separate xml nodes. Also, the JSBSim configuration files are often generated by a script (aeromatic in this case) first and then altered. This minimizes human error. That said, it looks to me the best way to eliminate all concerns is to make sure that subsystems that are going to use array-properties use a detached property tree (not attached to the root tree as shown in the property manager). It looks to me that would be no problem for the shader subsystem since it (like JSBSim) only uses the property tree to read the configuration file. After it has been read there would probable little or no need to adjust the individual properties using the property manager, or to send them over the network, anyhow. Erik --- --- --- - ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Very bad surprise with last FG cvs
Hi, On Jan 9, 2009, at 11:38 PM, Torsten Dreyer tors...@t3r.de wrote: Hello, What happen now with the Cockpit view Getting now the cockpit cutted That's the near clipping pane, you might want to add sim rendering camera-group znear type=double0.1/znear /camera-group /rendering /sim in your model-set.xml It works on fg/cvs, but it crashes 1.9.0 since no camera groups are created if you give a camera-group tag without specifying any camera configs. It is safer to settle znear property from Nasal after the camera groups are created. Doing so in a FDM-initialized listener is enough for this case. However, I really want Tim to change it in cpp code. I believe that the default value of znear must be less than 0.25 for avoiding my- cockpit-is-cut-away thingie. I know this is for avoiding flicker thingies, but Tat -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Aircraft download page for 1.0.0 or earlier
Hi there, Is there any chance of having aircraft download pages for 1.0.0 on the FG web site? I've been asked from some users and friends of mine for how to download aircraft for 1.0.0. Most of their machines are a bit older and thus not able to run FG smoothly. We have nice download page for 1.9.0 aircraft, but there's no pages for 1.0.0 or earlier as far as I can see. I can tell them how to get 1.0.0 aircraft via either cvs or git but is not that easy for bigginers. Alternative easy means of getting 1.0.0 aircraft are also welcome as long as these are easy enough for bigginers. Best, Tat - Tatsuhiro Nishioka -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] problems with z-buffer
Hi, I tried this change on my MacBook Pro with ATI Radeon X1600. Setting .1 to znear increases a chance of flickering 3D clouds as Tim mentioned. Changing it to .4 reduces the flicker but not enough on my Mac. .7 will be sufficient to eliminate flicker in most of views but you cannot see very near side of the cockpit. As Tim mentioned, we need to settle the default value of this property for reasonable result in many machines, but I guess it is a bit hard. I wonder if decreasing the zfar reduces the chance of flickering. Will try it tonight. Anyway, it is very good to have these properties exposed so that users can adjust these for getting a suitable result. Thanks Tim! In my own opinion, the default value can be .1 if we provide a brief guide for ajdusting these properties. We can write a wiki page about it and advertise the guide via here and/ or the forums. I also found the side effect of putting small number to near-field (the boundary of near and far camera). If you place the boundery in front of the propeller, the alpha blend of the propeller seems not working and thus it hides the 3D clouds behind it. For example, putting 1 to near-field when in the cockpit view of A6M2 hides the 3F clouds behind the propeller. I think the far camera is for avoiding such problem so this can be predictable side effect. But if this can be solved, that would be great. (I'm not that sure if we need to though). I also want to add a fact that the blackbox issue does not appear on my macs, and I have never heard about similar issues from Mac users yet. So most of mac users don't have to adjust these properties. Best, Tat @ iPhone On Dec 29, 2008, at 5:40 PM, Tim Moore timo...@redhat.com wrote: Alex Romosan wrote: the latest commit to src/Main/CameraGroup.cxx changed the value of zNear from .1 to .4 and this causes strange artifacts to show up when panning around (like holes in the cockpit, etc.). the following patch changes it back: --- src/Main/CameraGroup.cxx27 Dec 2008 14:35:33 - 1.9 +++ src/Main/CameraGroup.cxx29 Dec 2008 06:58:41 - @@ -446,7 +446,7 @@ cgroup-buildGUICamera(pNode); } } -bindMemberToNode(gnode, znear, cgroup, CameraGroup::_zNear, .4f); +bindMemberToNode(gnode, znear, cgroup, CameraGroup::_zNear, .1f); bindMemberToNode(gnode, zfar, cgroup, CameraGroup::_zFar, 12.0 f); bindMemberToNode(gnode, near-field, cgroup, CameraGroup::_nearField, 100.0f); any reason for the change? FlightGear displays an enormous visual range, from 4 inches in front of your eyes out to 120km now and more in the future. It's a basic fact when using Z-buffered computer graphics that the precision of the Z-buffer deteriorates with huge near-far spreads and that the near plane distance has a much greater effect than the far plane. The symptoms are flickering, jitter, and other unpleasantness. About a year ago I added a scheme to use several cameras within the scene graph to work around this problem. Each camera draws a slice of the scene using the full range of the Z buffer. This mostly works well, though depending on your video hardware you can occasionally see a line in the scene. This should be able to be eliminated with some tuning. Recently, as part of the work in implementing shadow maps, I moved the cameras out of the scene graph to a top level. For some reason this provoked the black-rectangle bug on some video hardware that's reared its head in the forums, but that's another story :) Anyway, my intention is to restrict shadows to the near camera. Shadow maps are even more sensitive to near-far plane precision issues than the normal Z buffer, so I'm experimenting with pushing the near plane out. .4 meters seemed sufficient to me, but others don't agree, so perhaps we can settle on some value larger than .1. The near plane value is settable, both in the camera configuration and as a live property in /sim/rendering/camera- group/znear. Tim --- --- --- - ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 1.9.0 feedback
On Dec 28, 2008, at 1:24 AM, Csaba Halász wrote: FYI, the black rectangle also occurs on linux, especially with older nvidia cards only supported by the legacy driver (no possibility to upgrade). The bug appeared with the change to 2 cameras. Tim said he might have some workaround for this. The splash-screen bug might be some timing issue and it has been mostly reported by single-core users. Way too long splash-screen occur on my MacBook Pro with core 2 duo, so this is not only for single core users. In that case I quit it during the splash screen, and then launch it again. The second trial usually works fine. Only the problem I have in that case is that FG crashes with sigsevg if you quit it during splash screen. This is another issue but it must also be fixed. I've not yet reported that any Mac has a black box problem, but I've reported one crash with nVidia GeForce ti4x00 driver bug exactly the same as GeForce 7x00GT. Tat -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC : FlightGear Roadmap for 2.0 and further
Hi, Thanks for the comments, It's kinda hard to reply individually, so here I wrap up the comments given so far: 1) The version numbers and release dates Here's an example list of version numbers and release dates when FlightGear will be released quarterly. 2.0 - at the end of March, 2009 2.1 - at the end of June, 2009 2.2 - at the end of September, 2009 2.3 - at the end of December, 2009 James: It's not quite the number system I first guessed at, and I think the odds of ever *doing* a bug-fix release are quite low, but it sounds reasonable. Stuart: A roadmap would be a great idea. However, I'm not sure a quarterly release cycle is realistic. Allowing for a 2 week RC test, you're talking about less than 3 months of actual development between releases. That's not much time. Tim: This is a good idea, regardless of the specific milestones that make it into a release. It seems to me that just the data tree sees enough new development that quarterly releases would have interesting new content. So having such version numbers are acceptable but we have more room on determining the release cycle. To me quarterly release cycle is reasonable, plus you don't have to promise 100% completeness on a certain feature for each release. Almost all open source software have some bugs in each release, so we don't have to seek for such perfect project that none can reach. There're some preferences for version numbers, but all the comments are not against the version numbers I listed as examples. So my idea may be acceptable, I think. I want to collect more opinions on the release cycle. Which do you prefer, semiannual or quarterly? and why? 2) Milestones (Goal for each release) Here's an example list of must-achieve things for 2.0.0 (based on discussion on the list, I believe). [2.0.0 - at the end of March, 2009] Functionality: - Landing Lights - Shadows - More improvements in 3D clouds (I don't know the exact goal on this though...) Stuart: These seem like sensible goals for a 2.0 release. However, they appear to be very dependant on Tim and myself. (snip) Pushing for a release in 3 months without any commitment from the developers involved in the main feature improvements is pretty high risk. Tim: This sounds nice, but we, or at least I, can't commit to specific features or development on a fixed timescale. James: Overall I agree, coming from a commercial software development side, I'd prefer people to think in terms of features, and committing to delivering them for a certain release. Where a feature means the kind of thing we'd put in a 'new for this release' bullet point list. Then we can decide whether to delay a release because feature X will take an extra two weeks, or postpone feature Y from release 2.n to 2.n+1 because it would delay it too much. So maybe Must-achieve is a bit too tight. What about listing features that you (will) start working instead of must achieve. That also work. This way there's no commitment of achievement on each release, but it rather says you are or will be start working on a listed feature on a certain release. We cannot seek for the 100% completeness at the end of each release, but it is a good idea to show that we have a certain set of features regardless of completeness. we can keep improving such features in the versions follow. How's this? About the milestone document, we can put these in either wiki or cvs. Maybe there's no perfect place so we can start writing such things to wiki with a clear note like developers only. By the way, are there any features that can be implemented on 2.0.0? 3) Release branch I believe that we need to have a release branch for both developers and release organizers. The main reason is to separate bug fixes from implementing a new features. This way, developers don't have to wait for the release to check in attractive but likely buggy code to cvs. Usually you must not include a new feature to the release branch once it is created. However, if many developers want to include one to the release branch, then we can discuss it in the list. After each release, we'll merge the bug fixes to trunk. If we get used to this release process, maybe a branch exists only for a few weeks, and thus merging changes to trunk is not gonna be that hard. James: I think in practice, the odds of ever doing a release *branch* for a project like FG is very low. I'd rather just stabilise trunk and tag. If we ever needed to do a x.y.1 release, it's trivial to branch from the tag and fix the bug. In general, back-merging from a release branch to a trunk is a horrible, thankless task, so avoiding it seems like a win to me. Stuart: I think cutting a release branch just prior to the release makes sense, but having long-term release branches and only merging from trunk when you're confident a feature is finished and
[Flightgear-devel] RFC : FlightGear Roadmap for 2.0 and further
Hi there, I'm very happy that we finally released 1.9.0. According to the discussions before the release, I believe that many of us are willing to release FlightGear more often, like semiannually or quarterly (or even more often). To release more than once a year, I believe that we need to have clearer roadmap, versioning policy, and the release process. Here are my opinions so please give me comments and feedback please. 1) The version numbers and release dates Here's an example list of version numbers and release dates when FlightGear will be released quarterly. 2.0 - at the end of March, 2009 2.1 - at the end of June, 2009 2.2 - at the end of September, 2009 2.3 - at the end of December, 2009 0.1 is increased on every release until it reaches the goal of 3.0.0 (it can be 2.10.0 or 2.150.0 :-p) I think incrementing minor version number on each release is enough for our project, and micro version number can be reserved for bug-fix releases between two releases. 2) Milestones (Goal for each release) Here's an example list of must-achieve things for 2.0.0 (based on discussion on the list, I believe). [2.0.0 - at the end of March, 2009] Functionality: - Landing Lights - Shadows - More improvements in 3D clouds (I don't know the exact goal on this though...) Reliability: - NaN things must be eliminated - SIGSEGV must be avoided when: + no osg plugins are found + a sound file is missing + there are some other missing xml / ac files Usability: - to be determined (T.B.D.) Effifiency: - T.B.D. Maintainability: - T.B.D. Portability: - T.B.D. [2.1.0 and further versions ] - T.B.D. :-p We can add more items on each category (I took these categories from ISO-9126, but we can express the must-achieve things in a different categorization) Maybe we need to separate general FG things from per aircraft things. It is also very good to organize the must-achieve items for each release based on the following documents: - http://wiki.flightgear.org/index.php/Long_Term_Goals - http://wiki.flightgear.org/index.php/FGFS_Todo - http://wiki.flightgear.org/index.php/Feature_Requests_/_Proposals_/_Ideas I believe that these milestones don't prevent the developers from implementing their new ideas at all. we can freely add new features even these are not listed in the milestones. Moreover, if we cannot implement some of the must-achieve items due to lack of time, then we will carry these over the next release, and make the current release published. 3) Release branch I believe that we need to have a release branch for both developers and release organizers. The main reason is to separate bug fixes from implementing a new features. This way, developers don't have to wait for the release to check in attractive but likely buggy code to cvs. Usually you must not include a new feature to the release branch once it is created. However, if many developers want to include one to the release branch, then we can discuss it in the list. After each release, we'll merge the bug fixes to trunk. If we get used to this release process, maybe a branch exists only for a few weeks, and thus merging changes to trunk is not gonna be that hard. Any comments, better idea? Tat -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 1.9.0 for Mac OS X has been released.
Hi there, FlightGear 1.9.0 for Mac OS X is available from: http://macflightgear.sourceforge.net Please consult ReadMe file before you start flying. There are so many updates and some known issues in this package. Have a happy flight, happy holidays! Tat p.s. Documents on the web page will be updated some time (hopefully) soon, so be patient. :-) -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear web site aircraft download page
Hi Curt, I found one mistake: A6M2 - author unknown. This is because A6M2-set.xml includes A6M2-base.xml that has author tag. If it is very hard to avoid this in the script side, please let me know. Tat On Dec 22, 2008, at 10:38 AM, Curtis Olson wrote: It was looking for description tags in the -set.xml file ... I changed it to stop looking after the first one. Curt. On Sun, Dec 21, 2008 at 4:48 PM, Alexis Bory - xiii alexis.b...@gmail.com wrote: Curtis Olson wrote: These aircraft download packages as well as the download page is all autogenerated from scripts, and all the information about authors and versions is contained within your aircraft. If you have any questions, look at an example aircraft that does things the way you like. :-) Hi Curt, On the aircraft download page I note: *A-10*: Fairchild A-10 (YASim FDM) tank-600-gals AN-ALQ-131 dual-AIM-9 LAU-68 triple-MK-82-LD single-MK-82-LD none none none none none none none none none none none Well I don't really know how to avoid this list of ordnances to appear... Wouldn't the script be overzealous ? Thanks for your help, Alexis -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Link update request to webmasters
Curt, and the webmasters of mirror sites: Please update the URL for Japanese mirror site to: www.flightgear.jpn.org Thank you very much, Tat -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
Hi, Thanks for the report. Please send me the crash logs. I need to take a look at these. I'll also update OSX tomorrow and see what's going on. - Tatsuhiro Nishioka On Dec 19, 2008, at 6:19 PM, Richard Hornby r.f.hor...@btinternet.com wrote: I have just run 1.9.RC2 from your dowload site for the first time. First, continued thanks for your work in making this distro. I am getting 'consistent' crashes with all the non-yasim A/C. To put it another way, only the Yasim A/C are working. Attached are the first few lines of the crash report of various JSB sim A/C Zero, Cessna 172, Moyes Dragonfly, Kawasaki T4, Zeppelin Path:/Applications/FlightGear.app/Contents/Resources/fgfs Identifier: fgfs Version: ??? (???) Code Type: X86 (Native) Parent Process: FlightGear [524] Date/Time: 2008-12-19 08:55:45.432 + OS Version: Mac OS X 10.5.6 (9G55) Report Version: 6 Exception Type: EXC_SOFTWARE (SIGTRAP) Exception Codes: 0x0007, 0x Crashed Thread: 2 Cessna 172 (2D) Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0008 Crashed Thread: 0 Seneca II Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0xfff4 Crashed Thread: 2 And on other sim types: - Camel (both versions, Larcsim) - as for Zero, etc FG Video assistant EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x27aaf890 Crashed Thread: 0 UFO - no crash report I have installed this straight from the box - no tweaks or prefs. I upgraded to the latest Mac OS X release yesterday. Can send a full crash log off-net if you want. Brgds, R --- --- --- - ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
Hi, On Dec 16, 2008, at 10:54 PM, James Turner zakal...@mac.com wrote: On 16 Dec 2008, at 13:45, Frederic Bouvier wrote: After 2.0 I'll start merging in my Effects framework code that will make, among other things, local light sources practical. I'm not sure if the best way to do cockpit lighting is to have a light source in the cockpit or to simply turn up the emissiveness of the instruments and dashboard... I don't think there will be a 2.0 anytime soon. It took 10 years to have v1.0 . I hope you mean 1.99.5 Heh, I was wondering about this - I'm hopeful that Tim means what he wrote, but that 2.0 will also be along soon, maybe even Q1 2009. And then 2.1, 2.2 I guess Tim means 1.9.0, not 2.0. Actually 1.99.5 is just a temporal number for fgfs/cvs and (I believe) we're heading to 1.9.0. Curt told us that he put 1.99.5 since he had missed the discussion on this list about the version number for the first OSG release. This is why I gave 1.9.0-preN to mac binaries. Got confused? The final dicision will be made soon, so we'll see. Anyway, shorter release cycle can give flightgear a chance to get more attension, so I like that idea. If quarterly releasing cycle is a bit too often, then semiannual is fine for me. What do you guys think? Tat -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
Hi guys, Personally, I think a big build up to an oddball version number like 1.99.5 is a little strange, but again, I'm not so hung up on version numbers as long as they keep increasing. It would also be odd to backtrack since the point of version numbers is to distinguish releases in some logical order. We had a change to revert the version back to 1.8.x or something before releasing 1.99.5-rc1 thing, didn't we? I had in my mind that there would be a 1.99.x release sequence as a build up to a major v2.0 release (rather than 1.99.5-rcX building up to a v1.99.5 release.) So there are some crossed wires here that unfortunately is leading to a weird version number situation. And you are a person who can fix it up. In the meantime, I have been working on a script that will streamline the release process a bit. My hope is to start doing more frequent source releases once this major release is pushed out the door. For the moment, the really strange thing is that the mac version has another numbering scheme. This is because we don't have any clear versioning policy, and I really don't want to buy such meaningless number as an official release. I thought that pushing for having clear versioning policy should be after the release, but I take it back. We really need a clear versioning policy. I already asked once or twice that we need to settle the official release number soon, but none did. That's why I stayed in 1.9.0 with respect to the result of the discussion made in this list. I already told Curt that we need to have versioning policy before going to make scripts for automatic release process. Automation for the release is basically good, but if that is the cause of using such a weird number, We better not use it. What does 5 in 1.99.5 mean? Did we release 1.99.0 or 1.99.1? No!! Please do not use such a weird meaningless version number. Curt, please think twice. I never want to buy 1.99.5 number at all. It doesn't have to be 1.9.0, but 1.99.5 is way too bad! Is it only me who thinks we are facing to very weird and confusing situation? And do you think that a different version number on FG/Mac is the cause of this? If many think so, I'm very very sad. If we are pushing for a more frequent release rate, maybe the -rcX thing should be skipped and fix bugs from release to release. That also means that the aircraft list should be frozen in order to capitalize on experience. If we have a release branch, I totally agree with this idea. Tat -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
Hi, So we three are all busy around the release date :-) I'm OK if it will be either Friday or Saturday, or even after that. I need to make some tests before the release, but this time it can be slow since my spare time for FG is very limited in a given time frame. So the Mac version will be released hopefully within a week after the source code release. Curt, please give the official version number until the release. And I wish all of you have a happy holiday. - Tatsuhiro Nishioka On Dec 17, 2008, at 5:02 AM, Durk Talsma d.tal...@xs4all.nl wrote: Hi Fred, On Saturday 13 December 2008 18:50:51 Frederic Bouvier wrote: I replied that the target is next Friday. After that I may have difficulties to build a binary from where I will be. -Fred How would your availability be after Friday. As it turns out, I have a Christmas dinner this Friday, so I won't be able assemble the final release by then. Saturday will be fine for me, so I hope to roll up the release then. Cheers, Durk -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/A6M2 a6m2-sound.xml, 1.1, 1.2
Hi, On Dec 16, 2008, at 6:05 AM, Frederic Bouvier fredfgf...@free.fr wrote: Hi Tat, - Tatsuhiro Nishioka a écrit : Update of /var/cvs/FlightGear-0.9/data/Aircraft/A6M2 In directory baron.flightgear.org:/tmp/cvs-serv3209 Modified Files: a6m2-sound.xml Log Message: Modified: to use p51d sounds in /Sounds for file sharing. Do you plan to add p51d sound files in $FG_ROOT/Sounds Yes, and these are already stored there. I've talked with Melchior and some others on this at IRC, and we agreed to place these files into $FG_ROOT/Sounds due to the following reasons: - these are used by more than a dozen of aircraft - p51d is not going to be included in the base package in 1.9.0 - we need to avoid duplicating the same files, as well as users' complaints about missing sounds. I left the original file names for clearly showing that these files are made for p51d. I believe it doesn't hurt anything, and is good to show the respect to the original author. This change requires some aircraft models (including p51d) to replace the paths of these with the ones in $FG_ROOT/Sounds. So I would like all authors of such aircraft model to update these paths. I'm mobile now so I'll list up the aircraft to be updated later. It's very helpful if anyone kindly lists these up for me. Ki-84 and j7w are already done. I also want to hear some better solutions (other than making new sounds for all these aircraft individually). Best, Tat -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] External sound dependency in A6M2
Great catch! I'll fix this soon. Best, Tat On Dec 15, 2008, at 8:26 AM, Frederic Bouvier fredfgf...@free.fr wrote: Hi Tat, do you noticed the A6M2 model use two sound files that are not in the base package : Aircraft/p51d/Sounds/p51d_rpm1.wav and Aircraft/p51d/Sounds/ p51d_startup.wav referenced in a6m2-sound.xml ? -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer --- --- --- - SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Correction to Input/Joystick/Saitek/X52.xml
Hi Laurent, I also have my own version of X52.xml that is more useful than that in CVS, I guess. I applied your patch to mine, so please give it a try. My prebuilt FlightGear for Mac OS already has this file, and some users have told me that this should be in CVS, and I guess this is a good time to think about it. If it works fine with Linux, and windows, I'll commit this to CVS. Best, Tat -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 1.99.5: Release Candidate
Hi Gèrard, Sorry for my late reply. I tested your hook and it seems working very good. I'll clean up as you suggested. Plus, the -test*.xml files should be removed since these are only for my experimental patch that I posted a while ago, but are not completed yet. Best, Tat On Dec 4, 2008, at 4:57 PM, gerard robin wrote: Hello Tat, I forgot to tell you, that, you may want to clean the hook.xml file, since their is some unuseful commented out part. That was a first attend to get the right hook animation. , YASIm compatible being replaced by a more elegant solution. I have included the feature in both jsbsim fdm files = jsbsim-test-set and jsbsim-set, in case of Cheers.. On jeudi 04 décembre 2008, Tatsuhiro Nishioka wrote: Hi Gèrard, Thank you very much!! I will test it tonight. On Dec 4, 2008, at 3:48 AM, gerard robin wrote: On mercredi 03 décembre 2008, Tatsuhiro Nishioka wrote: Done, i hope it will suit for you. Tested, by my test pilot, here the result: http://pagesperso-orange.fr/GRTux/Zero-Carrier-takeoff.jpg http://pagesperso-orange.fr/GRTux/Zero-Carrier-approach.jpg http://pagesperso-orange.fr/GRTux/Zero-Carrier-landing.jpg Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Concorde crash on 1.9.0-pre1; (was Re: FlightGear 1.9.0-pre1 release - for Mac OS X)
Hi there,
I found the crash with Concorde is caused by in JSBSim update on 12/01.
I made a reverse patch of JSBSim update on that date and applied to the fgfs
source on 12/07, then Concorde worked just fine.
So I suspect there are some inconsistencies between the update and Concorde's
configuration file.
I'm not so sure why this update causes crash on a sound related thread but
somehow these are related.
After the JSBSim update, the log shows tons of errors and warning like:
CullVisitor::apply(Geode) detected NaN,
depth=nan, center=(0 0 0),
matrix={
nan nan nan nan
nan nan nan nan
nan nan nan nan
nan nan nan nan
}
Warning:: Picked up error in TriangleIntersect
(-109.359 98.4674 -330.521, -55.9012 50.3336 -353.894, -139.955
45.4741 -330.521)
(nan,nan,nan)
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan nan nan nan segment ignored..
Then finally I got
OpenAL error (AL_INVALID_VALUE)
and fgfs crashed.
I'll investigate deeper on this, but I'm very happy if anyone tells me how to
fix this.
Tat
On Dec 4, 2008, at 10:58 AM, Tatsuhiro Nishioka wrote:
(2) Concorde crashes fgfs (SIGSEGV) when splash screen goes off.
log shows:
osgDB ac3d reader: could not find texture concorde-warning.rgb
snip
concorde systems started, version 2.5
snip
46: GEAR_CONTACT: LEFT_FWD 0
47: GEAR_CONTACT: LEFT_REAR 0
48: GEAR_CONTACT: RIGHT_FWD 0
49: GEAR_CONTACT: RIGHT_REAR 0
Updating adjusted fog parameters.
Stopping audio after 0 sec: engine 1 shutdown
Stopping audio after 0 sec: engine 2 shutdown
Stopping audio after 0 sec: engine 3 shutdown
Stopping audio after 0 sec: engine 4 shutdown
AICarrier: Inside Operating Box
AICarrier: Inside Operating Box
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Concorde crash on 1.9.0-pre1; (was Re: FlightGear 1.9.0-pre1 release - for Mac OS X)
Hi Gérard, and James, Thanks for the info, I tried some other JSBSim aircraft like A6M2-jsbsim, f18, f15, etc, and found many fall into either black out or white out, which never happens on fgfs without the JSBSim update. As this update is included in Durk's tarball, we definitely need to either cut out the JSBSim update on 11/30 or fix this issue before the release. I think latter is better but I don't know if we can fix this easily need many helps from you guys. I now feel very much that I wish we had a release branch for separating two things, concentrating on bug-hunting for release and actively committing new features that might be buggy but very attractive. Best, Tat On Dec 8, 2008, at 2:30 AM, gerard robin wrote: On dimanche 07 décembre 2008, gerard robin wrote: On dimanche 07 décembre 2008, James Turner wrote: On 7 Dec 2008, at 15:37, Tatsuhiro Nishioka wrote: Then finally I got OpenAL error (AL_INVALID_VALUE) and fgfs crashed. I'll investigate deeper on this, but I'm very happy if anyone tells me how to fix this. I see this 'somethimes' - not every day, always with JSBsim aircraft, and I have no explanation, sorry. It doesn't always crash, but I've also seen the OpenAL error (AL_INVALID_VALUE and the the crash without the 'nans' flooding. My feeling is that there is still a memory-corruption issue lurking somewhere. James Just a way to look for , not to solve , when working on some old aircraft (not in cvs, not yet ..) i noticed that additional tanks which are not declared feeding an engine gave these tons of message and a black screen. If i remove the tanks everything is coming back, right. However, since i split the flight_control in several systems components , (the flight_control , becoming empty in the main branch) i get again the Aircraft loaded and working with the additional tanks. Probably it is a misfit during the initialization of the FDM within JSBSim, which does not come up, with flight_control replaced by systems files Cheers An other complementary information, that problem, to me, is not new . i noticed the bug before the last update ( which is for piston engine, ). 2008-11-30 Modified Files: FGAtmosphere.cpp FGAtmosphere.h FGAuxiliary.cpp FGFCS.cpp FGMassBalance.cpp FGMassBalance.h FGOutput.cpp FGPropulsion.cpp Log Message: Sync. with JSBSim CVS I was unable to explain the error ( it could have been from me ) , and the files i am working on are not available on cvs, so , i shut up :) May be an addition of errors did make that Concorde becoming suddenly not usable. Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Concorde crash on 1.9.0-pre1; (was Re: FlightGear 1.9.0-pre1 release - for Mac OS X)
Hi Ron, Thanks for this wonderful news. I was also looking for the Leaky/uninititialized variables but was not found these yet, and am very glad to hear this. Great job Anders!, as always. Tat - Tatsuhiro Nishioka On Dec 8, 2008, at 5:38 AM, Ron Jensen [EMAIL PROTECTED] wrote: On Mon, 2008-12-08 at 03:44 +0900, Tatsuhiro Nishioka wrote: Hi Gérard, and James, Thanks for the info, I tried some other JSBSim aircraft like A6M2-jsbsim, f18, f15, etc, and found many fall into either black out or white out, which never happens on fgfs without the JSBSim update. As this update is included in Durk's tarball, we definitely need to either cut out the JSBSim update on 11/30 or fix this issue before the release. I think latter is better but I don't know if we can fix this easily need many helps from you guys. I now feel very much that I wish we had a release branch for separating two things, concentrating on bug-hunting for release and actively committing new features that might be buggy but very attractive. Best, Tat Anders found this bug. It was uninitialized variables in FGTank. The change is already in CVS, but here's the patch anyway: Index: src/FDM/JSBSim/models/propulsion/FGTank.cpp === RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/JSBSim/models/ propulsion/FGTank.cpp,v retrieving revision 1.6 diff -u -p -r1.6 FGTank.cpp --- src/FDM/JSBSim/models/propulsion/FGTank.cpp30 Nov 2008 10:44:30 - 1.6 +++ src/FDM/JSBSim/models/propulsion/FGTank.cpp7 Dec 2008 19:41:38 - @@ -59,6 +59,7 @@ FGTank::FGTank(FGFDMExec* exec, Element* Element* element_Grain; Area = 1.0; Temperature = -.0; + Ixx = Iyy = Izz = 0.0; Auxiliary = exec-GetAuxiliary(); Radius = Capacity = Contents = Standpipe = Length = InnerRadius = 0.0; PropertyManager = exec-GetPropertyManager(); --- --- --- - SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Concorde crash on 1.9.0-pre1; (was Re: FlightGear 1.9.0-pre1 release - for Mac OS X)
Hi, On Dec 8, 2008, at 7:55 AM, Jon S. Berndt wrote: From: Ron Jensen [mailto:[EMAIL PROTECTED] Anders found this bug. It was uninitialized variables in FGTank. The change is already in CVS, but here's the patch anyway: ... I'll consider my hands virtually slapped. My mistake. Thanks, Anders, for fixing that. I'm working on getting a Linux box at home where I can use several good memory/validation tools to make sure that code changes don't have memory leaks in them. haha, I can imagine your virtually slapping your hands. It happens on everyone so don't worry. The patch that Ron posted solved the problem, and now all JSBSim aircraft works fine as long as I've tested here. By the way, what kind of tools you are going to use? I'm more interested in these. I know Valgrind, but it doesn't work on Mac OS X. I also want to know some open source static analysis tools that tell us possible bugs like Prevent SQS does. Best, Tat -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Concorde crash on 1.9.0-pre1; (was Re: FlightGear 1.9.0-pre1 release - for Mac OS X)
Hi,
On Dec 8, 2008, at 10:11 AM, gerard robin wrote:
Anders found this bug. It was uninitialized variables in FGTank. The
change is already in CVS, but here's the patch anyway:
(snip)
I hope that solve the problem for you.
Here i have rebuilt FG with that patch and recovered one of my old JSBSim
Aircraft FDM which did not worked,
i am longer getting the same error , black screen and
CullVisitor::apply(Geode) detected NaN,
depth=nan, center=(-3.09272 -0.110464 -0.924417),
matrix={
nan nan nan nan
nan nan nan nan
nan nan nan nan
nan nan nan nan
}
Anyhow, as i told before i have solved it in a different way.
As I wrote in my last post, it solved the problem.
And I'll try your way when I encounter these errors.
Thanks a lot!
Tat
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 1.99.5: Release Candidate
Hi Curt, (are we going to release 1.9.0, aren't we. I'm a bit confused with our versioning thingies... We need to have more clear versioning pilocy, but this should be discussed some other time). Part of the confusion is my fault. It was my understanding from discussion a year ago that the 1.x numbers were for the plib branch (most likely 1.0 being the last real plib release.) And then the first OSG based release would be v2.0. I somehow missed the discussion and rational that arrived at a v1.9 version for the first OSG based release. So internally I had been marking the development version as 1.99.x and was up to 1.99.5 (nearing 2.0 in my mind) and had commited that to cvs Okay, I understand the background of this issue. I'll make a 1.9.0- pre1 package for mac os x tonight. Maybe I'll leave 1.99.5 in the version file at this moment. I'm working on a script to streamline the releases and have it mostly ready for SimGear, but I decided to hold off pushing that into production until I got a clearer direction of what we wanted to do with version numbers. I hope this doen't mean that we might have a different version number for the next release. I hate to have some fights/discussions on version numbers right before the release like 1.0.0 vs 0.9.11 again. Anyway, it is a good idea to postpone the script support before having a clear versionig policy and release process. I do want to discuss these, probably after this release unless many developers want to improve our release process and versioning policy. Best, Tat p.s. I hope you guys won't take this as a critisism. I just want to do some help. I do thank Curt, Durk, and so many developers for their efforts on this great project. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 1.99.5: Release Candidate
Hi Gèrard, Thanks for the offer!! I really appreciate it. Please add a hook capability to zero/jsbsim and get it committed. I think Syd will agree with me on this since it won't affect the Yasim part of zero at all. Best, Tat So If someone, who is familiar with JSBSim / external forces, is kind enough to add a hook capability to zero/ jsbsim, I'm very happy Hello, Tat Yes, i can do it It won't be difficult, and if you want i could include it in CVS. This won't break any of the existing files, only an an add on. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 1.99.5: Release Candidate
Hi Gèrard, Thank you very much!! I will test it tonight. On Dec 4, 2008, at 3:48 AM, gerard robin wrote: On mercredi 03 décembre 2008, Tatsuhiro Nishioka wrote: Hi Gèrard, Thanks for the offer!! I really appreciate it. Please add a hook capability to zero/jsbsim and get it committed. I think Syd will agree with me on this since it won't affect the Yasim part of zero at all. Best, Tat Done, i hope it will suit for you. Tested, by my test pilot, here the result: http://pagesperso-orange.fr/GRTux/Zero-Carrier-takeoff.jpg http://pagesperso-orange.fr/GRTux/Zero-Carrier-approach.jpg http://pagesperso-orange.fr/GRTux/Zero-Carrier-landing.jpg Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear 1.9.0-pre1 release (was FlightGear 1.99.5: Release Candidate)
Hi there, The FlightGear 1.9.0-pre1 has been released. Please download the package from: http://macflightgear.sourceforge.net/home/downloads/ Feedbacks are very welcome. Please consult ReadMe in the package before the flight. 1.9.0-pre1 looks like 1.0.0, but it actually is very different from 1.0.0. Best, Tat - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 1.9.0-pre1 release - for Mac OS X
Hi there, Oops, it is a pre release for Mac OS X. Anyway, I like to give a feedback on fgfs/mac os x to other developers. On Dec 4, 2008, at 10:53 AM, Tatsuhiro Nishioka wrote: The FlightGear 1.9.0-pre1 has been released. Please download the package from: http://macflightgear.sourceforge.net/home/downloads/ Feedbacks are very welcome. Please consult ReadMe in the package before the flight. 1.9.0-pre1 looks like 1.0.0, but it actually is very different from 1.0.0. There are some crash problems on 1.9.0-pre1. (I built it up with cvs as of 2 days ago since the tarballs is still being downloaded :-( ) Here are the problems and log. 1) fgfs crashes when quitting on splash screen: 0 org.OpenSceneGraph.osgText 0x00b8ec77 osgText::Font::~Font() + 501 1 org.OpenSceneGraph.osgText 0x00b978e6 osgText::Text::~Text() + 70 2 org.OpenSceneGraph.osg 0x0082fda6 osg::Geode::~Geode() + 246 3 org.OpenSceneGraph.osg 0x00860723 osg::Group::~Group() + 243 4 org.OpenSceneGraph.osg 0x008610c4 osg::Group::~Group() + 232 5 org.OpenSceneGraph.osg 0x009076d5 osg::Camera::~Camera() + 573 6 org.OpenSceneGraph.osg 0x00860723 osg::Group::~Group() + 243 7 org.OpenSceneGraph.osg 0x00860723 osg::Group::~Group() + 243 8 fgfs0x002f2e9d __tcf_2 + 83 9 libSystem.B.dylib 0x929d6fdc __cxa_finalize + 241 10 libSystem.B.dylib 0x929d6ed0 exit + 33 11 fgfs0x002fde11 fgExit(int) + 53 12 fgfs0x0030756a fgOSMainLoop() + 142 13 fgfs0x002e4a73 fgMainInit(int, char**) + 719 I think this has something to do with the order of destruction. -- (2) Concorde crashes fgfs (SIGSEGV) when splash screen goes off. log shows: osgDB ac3d reader: could not find texture concorde-warning.rgb snip concorde systems started, version 2.5 snip 46: GEAR_CONTACT: LEFT_FWD 0 47: GEAR_CONTACT: LEFT_REAR 0 48: GEAR_CONTACT: RIGHT_FWD 0 49: GEAR_CONTACT: RIGHT_REAR 0 Updating adjusted fog parameters. Stopping audio after 0 sec: engine 1 shutdown Stopping audio after 0 sec: engine 2 shutdown Stopping audio after 0 sec: engine 3 shutdown Stopping audio after 0 sec: engine 4 shutdown AICarrier: Inside Operating Box AICarrier: Inside Operating Box no suspicious things I saw... scenery loaded, and gui menu came up, fps showed, and then crash. According to the crash log below, it could be a driver bug or a problem in a sound file. I'll investigate it deeper crash log shows: Thread 3 Crashed: 0 audio.toolbox.AudioToolbox 0x91439205 TIntToFloatBlitterPCMUInt8, PCMFloat32::Convert(void const*, void*, unsigned int) + 197 1 audio.toolbox.AudioToolbox 0x913efa38 PCMConverter::ConvertBufferList(unsigned long, CABufferList const*, CABufferList*) + 104 2 audio.toolbox.AudioToolbox 0x913dfc52 CBRConverter::RenderOutput(CABufferList*, unsigned long, unsigned long, AudioStreamPacketDescription*) + 178 3 audio.toolbox.AudioToolbox 0x913df98c BufferedAudioConverter::FillBuffer(unsigned long, AudioBufferList, AudioStreamPacketDescription*) + 236 4 audio.toolbox.AudioToolbox 0x913dfb14 AudioConverterChain::RenderOutput(CABufferList*, unsigned long, unsigned long, AudioStreamPacketDescription*) + 100 5 audio.toolbox.AudioToolbox 0x913df98c BufferedAudioConverter::FillBuffer(unsigned long, AudioBufferList, AudioStreamPacketDescription*) + 236 6 audio.toolbox.AudioToolbox 0x913f5323 AudioConverterFillComplexBuffer + 275 7 com.apple.audio.OpenAL 0x007d4011 OALSource::DoRender(AudioBufferList*) + 397 8 ...pple.audio.units.Components 0x700355fc AUMixerEntry + 13292 9 ...pple.audio.units.Components 0x70035890 AUMixerEntry + 13952 10 ...pple.audio.units.Components 0x7003ae8d AUMixer3DEntry + 7053 11 ...pple.audio.units.Components 0x7003c9e0 AUMixer3DEntry + 14048 12 ...pple.audio.units.Components 0x70005fd2 0x7000 + 24530 13 ...pple.audio.units.Components 0x7003e7c0 SystemOutputAUEntry + 1216 14 ...pple.audio.units.Components 0x7000ea0b 0x7000 + 59915 15 ...pple.audio.units.Components 0x7000e164 0x7000 + 57700 16 ...pple.audio.units.Components 0x7000d4bb 0x7000 + 54459 17 audio.toolbox.AudioToolbox 0x913e01b1 AudioConverterChain::CallInputProc(unsigned long) + 209 18 audio.toolbox.AudioToolbox 0x913dfdf4 AudioConverterChain::FillBufferFromInputProc(unsigned long*, CABufferList*) + 84 19 audio.toolbox.AudioToolbox 0x913dfd94 BufferedAudioConverter::GetInputBytes(unsigned long, unsigned long, CABufferList const*) + 212 20 audio.toolbox.AudioToolbox 0x913dfc1d CBRConverter::RenderOutput(CABufferList*, unsigned long, unsigned
Re: [Flightgear-devel] FlightGear 1.9.0-pre1 release - for Mac OS X
Hi pooyan, Thanks for the report. I'm glad to hear it works on a mac with nvidia 7xxxGT. This means that by workaround patch against 7xxxGT bug works property. Please send me your crash dump so I can check if it is caused by the same problem. I'll exclude sound files one by one and see what file causes this problem. I'll be also going to test if it works on 1.0.0. If I works on 1.0.0, the bug is in our code. - Tatsuhiro Nishioka On Dec 4, 2008, at 1:15 PM, Pooyan McSporran [EMAIL PROTECTED] wrote: Tat, Thanks for making a new DMG. I've had a quick test and I'm getting the same crash on startup in AudioToolbox that you described, a snippet from my crash dump is below: Thread 4 Crashed: 0 audio.toolbox.AudioToolbox0x912b222d TIntToFloatBlitterPCMUInt8, PCMFloat32::Convert(void const*, void*, unsigned int) + 237 1 audio.toolbox.AudioToolbox0x91268a38 PCMConverter::ConvertBufferList(unsigned long, CABufferList const*, CABufferList*) + 104 2 audio.toolbox.AudioToolbox0x91258c52 CBRConverter::RenderOutput(CABufferList*, unsigned long, unsigned long, AudioStreamPacketDescription*) + 178 If it helps I can email you the full crash dump. This is a 2.33GHz Core 2 Duo iMac with NVIDIA 7600 GT. Thanks. --- -- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 1.99.5: Release Candidate
Hi, First of all, many thanks for your effort on this. I've been downloading the tar files but these are still being downloaded and will take about 24 or more hours My network is TFFH but it doesn't help me this time. Could you (or Curt) give a tag (like RELEASE_1_9_0_PRE1) to the source files and base packages in the cvs so I can check out instead of downloading the tarballs? (are we going to release 1.9.0, aren't we. I'm a bit confused with our versioning thingies... We need to have more clear versioning pilocy, but this should be discussed some other time). So far fgfs works fine except only a few problems (with code from cvs as of yesterday). I'll try to get these fixed until the official release date. Thanks goes to those who tested my binaries and reported bugs/improvements. Now it works on many Macs. By the way, I'm glad to have Zero in the base package. I'll also try taking time to improve it too but don't know if I can since I'm extremely busy right now. So If someone, who is familiar with JSBSim / external forces, is kind enough to add a hook capability to zero/ jsbsim, I'm very happy (Catapult launch is not needed since it does't have one). I also need to improve it's Jsbsim FDM but that will be done after the release due to lacking of time. Best, Tat On Dec 1, 2008, at 2:15 AM, Durk Talsma [EMAIL PROTECTED] wrote: Hi Everybody, I just placed the sources and base package for the pending FlightGear 1.9 release on my webserver: http://durktalsmal.xs4all.nl/SimGear-1.99.5.tar.gz http://durktalsmal.xs4all.nl/FlightGear-1.99.5.tar.gz http://durktalsmal.xs4all.nl/FlightGear-data-1.99.5.tar.bz2 Please note that I made an aircraft selection that was based on various suggestions made on the list, but that -as far as I'm concerned - this selection is not yet final. I've been trying to cut down the total number of aircraft in the base package, yet preserve the variety in feature richness that we originally had. Based on this, I came to the following list: 777ER : Fairly Complete Airliner B1900d : Very complete Commuter jet, Twin Turbo Prop. bocian : Our most complete SailPlane c17p: Light Single GA; our default aircraft dhc2: Versatile Tail Dagger, with Aerotowing Capability Concorde: Supersonic Transport Dragonfly : Nice ultralight. F14 : Omnipowerful Jet Fighter; has so many features, it is very well capable of representing the category Fighter Jet CitationX : Small Commuter Jet SopwithCamel: Historic Aircraft UFO : Classified Zeppelin NT : Airship Zero: WW-II Fighter Comments are welcome Cheers, Durk --- -- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Patch for unexpected view size on reset (was Z-near problem with new code)
Hi, Though I can't confirm the bug that you mentioned yet but I made a patch to fix the problem I reported in the last post. The cause is that restoreInitialState() overwrites the width/height of gui and camera views with the values at the launch time. This patch will save the following two nodes : - /sim/rendering/camera-group/gui - /sim/rendering/camera-group/camera and then restore these after restoreInitialState() is called. I confirmed that it is fixed with fgfs with single camera and with three cameras. This save/restore thing might have to be written as functions or methods in CameraGroup.cxx instead of directly written in fg_init.cxx::reINit() since save/restore thing can be more complex when you specify a configuration with more than one camera and/or with more than one window. Anyway, it is fixed at this moment. Please check the attached patch on some configurations (single camera, and multiple cameras), and commit it if it works. Best, Tat On Nov 23, 2008, at 5:01 PM, Tim Moore wrote: Tatsuhiro Nishioka wrote: Hi, I have similar problem, but a bit different (on Mac OS X) When launching with non 800x600, the splash screen is centered. no problem. but when resetting after resizing window has a clipping problem. Here is the screenshot: http://macflightgear.sourceforge.net/wp-content/uploads/800x600bug.jpg I launched fgfs with 800x600. When on runway, I resized window and then reset. I used fg/cvs, sg/cvs, plib/svn, and osg/svn as of 11 hours ago. I made sure the version of CameraGroup.cxx is 1.7 (the latest) It seems that the screen size (view size?) is also reset to the one settled at the launch time. If I specify --geometry=1024x768 option, the view size on reset always goes to 1024x768 no matter what actual window size at rest is. I guess we need to update the view size on reset. Yes, there is a bug when the actual window size doesn't match the requested window size; for example, 1024x768 on my laptop is too tall for the window manager menu bars. A workaround for now is to supply dimensions that you will actually get. resizeOnResetBugfix.diff Description: Binary data - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] heads up: Boost dependency
Hi, On Nov 21, 2008, at 10:08 PM, Tim Moore wrote: From Mac OS side, there seems no problem in using headers of any version of Boost as long as FlightGear works fine. I'll just grab it and build FG with boost headers. No difficulties. However, if we're going to use boost libraries before the next official release, I need to make sure the binary works on at least some Macs, including ppc/intel and OS X 10.4/10.5. Probably it needs some weeks to collect feedbacks. I've just checked a change to configure.ac that checks for a minimum version of Boost, looks for it in all the right places, properly supports --with-boost, etc. I know that you don't use configure for the Mac builds, but this should ease the vast majority of problems for Linux users. Yes, and configure.ac doesn't affect anything on Mac binary. I also built fgfs with boost header, and there was no build problems. So I want to hear Tim's (and others') opinion about: (1) what are the pros in using Boost especially in FlightGear. If that doesn't give us any improvement in quality (like maintainability, testability, usability, response, performance or whatever you name it) or functionality in a clear way, we can live without it, at least until the next official release (or until the next release branch is made). I've stated this before, a couple of different times. It provides many advantages in terms of convenience and cross-platform compatibility. In terms of maintainability and testing, I consider it a great advantage to leave those things to a much larger community where possible. The use of Boost in the currently checked-in sources is completely gratuitous, but in the future it will not be. I think it's a reasonable first step, and is certainly shaking out problems :) That is a good idea. cross-platform compatibility can reduce the time for debugging / testing. I also saw your proposal again and understood. it is a reasonable choice to me. (2) Are we going to use boost libraries in the near future? Hope not until the next release. Certainly not until after the release. If a library (as opposed to a header file) is useful, we should use it and solve the build issues. Excellent. It saves my time in checking if it works on many Macs. Best, Tat - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
