[Flightgear-devel] Changelog for Release 2.8.0
Hi everybody, we are very close to our release date, just a few days left until we hopefully ship our latest-and-greates-ever FlightGear version. Please check the changelog at http://wiki.flightgear.org/Changelog_2.8.0 and make sure every new feature is noted at a prominent place there. These are not only core features but also new/updated aircraft, scenery improvements, usability changes - whatever made FlightGear better since the last release. The changelog is often copied by online media and might help to attract new user, so please help creating a persuasive advertising for FlightGear 2.8.0! Thank you Torsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory issues
On 11 Aug 2012, at 18:21, Tim Moore wrote: > This is what osg::PagedLOD does, though we often forget that the > paging of the higher LODs is triggered in the cull phase. >> I can't recall what scene modifications are / are not permitted inside a >> cull-callbacl, however. > You would want to let the OSG loader mechanism and the database pager > do their thing. Geometry doesn't have to be loaded from files... Could you outline the pieces of machinery needed for this to work? Given that we already create LOD nodes, I assume it's switching those to be PagedLOD, and setting the filename / extension / reader-writerOptions to some magic, and creating a loader which matches that, which creates the buildings geometry. If you could point to an example of such a loader, I'm pretty sure Stuart or I could adapt his code. James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] MSVC build slave..
...is back online! Many thanks to Curt for donating a replacment drive! g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Buying desktop hardware and installing a server OS doesn't make a server-class system any more than sitting in a puddle makes you a duck. [Cipher in a.s.r] -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Usability
James Turner wrote: > On 12 Aug 2012, at 20:44, Martin Spott wrote: > >>> But it's not an either/or. There could be an FGCom binary that uses the >>> same >>> code as the built-in FGCom. >> >> Which environment would be set up to build this separate binary ? > > The fgfs one, but I don't think that's a particularly onerous > requirement to build fgcom. No ? FGCom is a perfect match for BeagleBoard-style computers and I know this actually had been one of the development goals, so you could have your radio comms in a neat interface box, no matter which hardware is running FlightGear. As a preparatory step, if you're really planning to shift FGCom into FG, then it's probably worth considering the 'cost' of porting FlightGear, at least those parts of the build system which would be required to build FGCom, to a stripped-down Linux on ARM ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Usability
On Sun, Aug 12, 2012 at 4:48 PM, James Turner wrote: > On 11 Aug 2012, at 22:52, Martin Spott wrote: >>> 3) Scenery. Terrasync is now built into FG, and we have nice UI to >>> configure it in-sim. However, it still requires users to set up a >>> separate directory and configure FG_SCENERY before it can be used. It >>> would be great if the standard installers created an >>> $FG_ROOT/WorldScenery directory with the appropriate permissions, and >>> added it to $FG_SCENERY by default. >> >> As far as I can tell, the value of "/sim/terrasync/scenery-dir" was >> already supposed to be added to the Scenery path, but I don't know at >> which priority. > > Right, this is all automatic now - has been since before 2.6 I think. At > least on Mac I set a 'correct' directory - in Library/Application > Support/FlightGear/Terrasync. Of course this is only a default, but for most > users it's enough. That's great. I will test the windows release candidate to see if that is the case there as well. > Usability was the main reason for making terrasync be available as in-process > option, and I'm strongly considering doing the same thing for fgcom, although > that has a few extra complications. > > BTW, usability is also the reason I made the network options configurable > inside the sim, and have been making more subsystems support a clean reset, > so that it's possible to sanely control more behaviours with direct results > in the sim. I'm a big fan of both of these changes. I very much like the idea of in-sim FGCom, though we should be prepared for the default frequency at KSFO becoming as congested as the in-sim chat! Of course, with an integrated FGCom, the MP chat function becomes much less relevant. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Usability
On 12 Aug 2012, at 20:44, Martin Spott wrote: >> But it's not an either/or. There could be an FGCom binary that uses the same >> code as the built-in FGCom. > > Which environment would be set up to build this separate binary ? The fgfs one, but I don't think that's a particularly onerous requirement to build fgcom. I can't imagine there's a large use case of people who really want to build fgcom standalone, but haven't already built fgfs from source. I do absolutely agree there are reasons to keep a separate /binary/, to run on a separate machines or similar, as an option (as we do for terrasync), but again for a large number of users the easiest solution would be an 'in process' one in terms of setup, configuration - and the easiest way to achieve that is to make the (tiny) amount of fgcom code live in the fgfs source tree. Anyway, it's only an idea, and not one I have time to work on in the short term :) James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
