Re: [Flightgear-devel] OpenSceneGraph-3.0.1 released!
On 31 Jul 2011, at 09:59, ThorstenB wrote: a new OSG stable release is available. Changes only involves a list of fixes since OSG 3.0.0. Do we have a chance to update jenkins to use OSG 3.0.1 for the windows installers (already using 3.0.0 right now)? Seems a good idea to include those OSG patches in our release(-candidates). For Linux and Mac it's trivial - since Jenkins build those, anyone with Jenkins access can adjust the SVN tag we pull for OSG. For Windows, it depends on Fred updating the 'third party packages' zips he produces. James -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Improved forests
On 28.07.2011 00:30, Stuart Buchanan wrote: The patch does the following: 1) Fixes the longstanding bug where the first set of tree definitions in a tile were used for all forests within that tile. 2) Re-introduce a feature to fade in trees by distance And, after doing a few circles at LOWI, the new forests really prove to be a very nice improvement! cheers, Thorsten -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] A few more screenshots from today's AI/ATC work
hi all, Today, I started working on a fairly major overhaul of the inner structure of the intelligent side of the AI system. although phase one of this operation is nearly complete, I did end today's coding session with a segmentation fault, so obviously it still needs more work. :-( My main goal is to simplify the interaction between the AIModels and the ATC part. In doing so, I already managed to bring more stability to the way the AI system responds to user input, and I'm close to being able to implement the handoff between the ground and tower controllers (the underlying infrastructure more or less works, it still needs to be animated, and translated into appropriate phraseology. Since the code itself isn't ready to be committed yet, I thought I'd update my set of screenshots. I particular, the last two screenies are interesting (on page 2): http://www.dropbox.com/gallery/7455889/1/GroundNetVisualizations?h=1f4147 While taxiing onto the runway, other traffic waits; and while taking-off, the next #1 for the runway is about to line up and wait. Unfortunately, the last image was the one that I took immediately before getting the segmentation fault. Cheers, Durk -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] startup crash in SimGear (with patch?)
It seems there's a memory management issue in SimGear that may cause a crash under certain conditions. (Actually I'm not totally sure why it ever works at all, but that's another matter.) In the routine sgLoad3DModel_internal (scene/model/SGReaderWriterXML.cxx) there's a prop_root variable of type SGSharedPtrSGPropertyNode. At some point, it may be passed to Particles::appendParticles. appendParticles (scene/model/particles.cxx) implicitly copies the value into a newly allocated GlobalParticleCallback's field modelRoot, of type SGPropertyNode*. So, when appendParticles return, there's a persistent non-reference-counted pointer to this structure. If there are no other references, the prop_root is automatically destroyed when sgLoad3DModel_internal returns, causing the memory to be freed. So, later on, when OSG wants to do something with these particles, the freed memory is referenced and causes a crash. I didn't see a fix for this in your git, so I've attached a quickfix, but perhaps you prefer other solutions. And perhaps it's not the only issue of this kind (especially since I see fgfs still crashes at exit), but this is all I have time for right now. Ove Index: simgear/scene/model/particles.hxx === --- simgear/scene/model/particles.hxx (revisjon 138) +++ simgear/scene/model/particles.hxx (revisjon 148) @@ -99,7 +99,7 @@ private: static osg::Vec3 gravity; static osg::Vec3 wind; -const SGPropertyNode* modelRoot; +SGSharedPtrconst SGPropertyNode modelRoot; static SGConstPropertyNode_ptr enabledNode; static bool enabled; }; -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
