Re: [Flightgear-devel] [Flightgear-commitlogs] SimGear branch, next, updated. 83124e0c056b13bf8150d74fdc2d139122f697bb
On 27 Feb 2011, at 20:09, Flightgear-commitlogs wrote: >There is no reference to anything defined in props.hxx, so remove >the dependency here. Great work Torsten, a very useful split. James -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
On 21 Mar 2011, at 11:15, thorsten.i.r...@jyu.fi wrote: > rgb: filesize 1.7 MB, time to appear 12 s, framerate for rendering 32 fps > png: filesize 0.8 MB, time to appear 135 s (!), framerate for rendering 21 > fps > dds: filesize 1.1 MB, time to appear 13 s, framerate for rendering 20 fps > > I have also tried other dds options, some didn't even render properly, and > none was better than the bc3 shown here. Maybe you already did this, but this needs a 'average of 3' (or 5) tests, because I would be very surprised if the input file format changes the final frame-rate after loading - it's all uncompressed to the same format in GPU memory, as far as I know. The PNG loading time also seems suspicious - decompressing a PNG is certainly more work than RGB or DDS, but decompressing a 1MB PNG shouldn't take even one second on a computer of the past few years. James -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on LinuxTag 2011
On 28 Apr 2011, at 20:40, Martin Spott wrote: > Does any of the non-German crowd plan to serve as booth staff or attend > LinuxTag as a visitor ? Unfortunately this year I have a work commitment, but hopefully next year! James -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata merge request 91:Animated Jetways
On 22 May 2011, at 22:11, Martin Spott wrote: > Now, since the most recent version of the ground network files are > distributed via TerraSync, I'd propose to place the jetway files in the > same directories. This would indeed require your scripts to look into > the custom scenery directories as well - which would be the preferred > option, because, as already mentioned, I'd like to reduce the > dependency of Scenery from the Base Package. > > The preferred way of referencing custom scenery data would be to have > some sort of variable as a reference for all subsystems/routines which > would refer to these directories, but I have to admit that I'm not > entirely certain about the current state. I'd say this is something > worth checking before we proceed. I talked to Ryan on IRC last night, and we discussed this. I've some local mods to commit+test that basically do exactly what is described above; they allow Nasal (or really, the loadxml command) to hook into my existing 'find a file for an airport, in the scenery locations' code we use for the other 'airport scenery data' files. I'll hopefully commit this tomorrow, then Ryan can test, and then hopefully jetways can live in the airport scenery data happily. James -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata merge request 91:Animated Jetways
On 24 May 2011, at 03:20, Ryan M wrote: > Excellent- thanks James. :) While you're at it, could you also publish > the $FG_SCENERY paths to the property tree? (Don't use my patch, it > turned out to cause a build error (which shows how good of a programmer > I am), and the pastebin link is probably expired now. ;) ) Yep, that's part of the changes, since I need to add FG_SCENERY dirs to the nasal IORules policy. (Read-only, of course) > > The jetways make a very noticeable impact on FlightGear's frame rate, > particularly at large airports such as KSFO, where up to 120 models > could be loaded at a time. Perhaps they should be disabled by default. That's ... unfortunate. As ever, our poor performance in these situations is caused by inefficient scene-graphs (too many nodes, not enough data in each) - but since the jetways are articulated, it's inevitable they will have transformation nodes. Not sure what the answer is here. James -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] multiplayer change, testing needed
If you have time, and run Git, please merge this to your local tree: https://gitorious.org/~zakalawe/fg/james-flightgear/commits/topics/mpreinit And let me know if you see any regressions to multiplayer. It mostly affects multiplayer *sending*, so you might need a friend or another machine to verify :) The change makes multiplayer well-behaved as a subsystem; especially it can be shutdown and re-inited - which enables some useful features - you can start/leave MP mid-flight, and switch servers too. There's a follow-on patch to add a GUI dialog to control this, but the above is the C++ changes, and should work with current .fgfsrc / command line switches for MP exactly as before. Cheers, James -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Hudson Mac
On 3 Jun 2011, at 22:58, HB-GRAL wrote: > I see that FlightGear-next-mac fails since some days because of some > missing plib headers. Is next-mac not followed anymore on hudson, is > FlightGear-mac-cmake reference now ? The problem is I switched to the MacPorts PLIB, because it was easier, but I'm using the universal variant - which doesn't include PW, since PW requires Carbon, and a 64-bit build can't use Carbon. I keep forgetting there's anything in the FG tree that still uses PW - my preferred work-around would be skip the layout-test on Mac, which is effectively what the cmake build does. James -- 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] FlightGear development entered state "feature-freeze" until July, 17th 2011
On 17 Jun 2011, at 20:47, Torsten Dreyer wrote: > Thanks for supporting our effort to create the next FlitghtGear release Woo-hoo, release process! Thanks to Torsten for driving the release, and ThorstenB for already doing a huge amount of bug-fixing. If you've previously filed bugs in tracker, now would be a good time to re-test them, update the comments, and so on. Similarly, taking an open bug, or one that's stalled, and re-testing is a great help. And of course, if you find new bugs, file them in the tracker too. James -- 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
Re: [Flightgear-devel] FlightGear development entered state
On 20 Jun 2011, at 21:18, Stuart Buchanan wrote: >> No, not generally. Obvious fixes are ok, major overhauls are not, in >> case of doubt I'd propose that the changes in question should be >> reviewed (which is a darn good idea anyway ;-) > > Well, I _was_ planning to review the changes. :) > > Both of the changes in question are major model overhauls to the respective > models (c172p, c150). > > I'll refrain checking them in until after 17th July then. Given this is the first time we're running the new release process, I'd personally support accepting aircraft updates on a case-by-case basis, after a review of course. Of course sticking to a release schedule is also important, and this is just my opinion. Equally the C172p is most people's first impression of FG, and we're only three days into the freeze, so I think a little bit of 'slush-iness' is reasonable. Regards, James -- 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
Re: [Flightgear-devel] FlightGear development entered state
On 20 Jun 2011, at 21:52, Martin Spott wrote: > This is the first time we're aiming at having one release every six > months and not everything will be perfect on the first attempt. Anyhow > I'm still proposing to let us familiarize ourselves with the > implications of having a release plan instead of making exceptions from > the rule right from the beginning. Fair point, I agree we ned to establish the rules before we break them :) James -- 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
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On 25 Jun 2011, at 22:59, Alex Perry wrote: > . Does anybody know offhand how much trouble it would be for our > source code to have all loaders of aircraft files go through a library > that understands what a relative URL is? If we can cut that over, > anybody can develop and host an airplane simply by sticking some > static files on the web somewhere. Which can reference components of > other airplanes. This is 'doable, but quite a bit of work'. What' I've been idly hacking up is a helper tool/library that would process aircraft catalogs (basically the first part of the -set.xml files, slurped together into one or several files, with the aircraft id, metatadata fields, thumbnail URL, a download URL, and an MD5 sum), and use that info to download aircraft from 'a backend' - the default backend being .zips on a HTTP server, but with the option to support an SVN repo, Git URL or whatever if the backend can be glued in. (So you'd have a stable version of the 744 pointing at an HTTP server, and a separate entry in the catalog, with a 'development' metadata flag set, pointing at the live Git repo, potentially - and could switch between them) (If the catalog entries encode the min- and max- compatible flightgear versions for a particular aircraft variant, this also gives us a way to keep the '2.0.0 compatible' archives available for legacy users, which I am sure they would appreciated) The tool code then does the work of fetching updated catalog XML files (eg, daily), and checking for updated version of aircraft, supporting multiple concurrent variants of aircraft, and crucially, placing the extracted/downloaded zip/Git repo in a place fgfs can find it. The reason I'm building this as a library/command line tool is, obviously the various GUI launchers might want to use it, but as Vivian pointed out, there are good reasons to be able to download/manage from inside FG - as was just proved with terrasync :) It *is* possible to go to the next step, and keep the .zip files as compressed blobs, like Java .jar files - but that means a lot more FG hacking to get the OSG file loaders and other places we load files, using a different stream backend. Entirely possible, but I'd sooner establish the core concept - aircraft are pulled as blobs from HTTP - before worrying about the niceties. Code wise, I have about 30% of this prototyped - but not at a point where it can be tested. Since it appears to be a hot topic, I am thinking i should revisit it for 2.5 :) James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On 26 Jun 2011, at 07:17, James Turner wrote: > Code wise, I have about 30% of this prototyped - but not at a point where it > can be tested. Since it appears to be a hot topic, I am thinking i should > revisit it for 2.5 :) I've tried to capture my current design/plans here: http://wiki.flightgear.org/Aircraft_deployment#Proposal_from_James It's only a proposal, and some prototype code, at this point - nothing final yet. James -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Current Weather System...
On 14 Jul 2011, at 12:46, thorsten.i.r...@jyu.fi wrote: > Nasal has a garbage collection problem. One solution to it is - we avoid > Nasal code wherever possible and try to hard-code everything. But Nasal > crops up on a lot of places - complex aircraft such as the Concorde come > to my mind, interactive AI models, lots of really nifty and useful > applications... - so instead of fixing things in a lot of places, one > could also think about it the other way and fix just one thing, i.e. the > garbage collection such that it doesn't hit a single frame. Indeed, and I've looked into this - it's a tough problem, but not an impossible one - and well contained - the current Nasal GC is a single source file. As you point out, the amount of scripted code is going to continue increase irrespective of local weather, so we need to bite the bullet sooner or later and fix the GC to be incremental. Fortunately, garbage collection is pretty well researched - the trick is finding an incremental algorithm that's 'simple enough' James -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Improved forests
On 27 Jul 2011, at 23:30, Stuart Buchanan wrote:
> Within the patch is the code below. The (*j)-> just looks ugly. Surely
> there's a better way?
>
> I'm sure those of you who write C++ more regularly than me will
> immediately be able to tell me where I'm going wrong!
As noted elsewhere, you can't avoid the double indirection, but you could use
foreach (from Boost):
TreeBin* bin = NULL;
bool found = false;
BOOST_FOREACH(bin, randomForest)
{
if ((bin->texture() == mat->get_tree_texture()) &&
...
{
found = true;
break;
}
}
--
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] SimGear branch, next, updated. 3ac5ff0cac4dfecc62e6deb440bb0aa309ff42c9
On 30 Jul 2011, at 15:25, Melchior FRANZ wrote: >> -headerData << "X-Time: " << requestTime << "\r\n"; > > And, ironically, going to break METAR proxy service ... It's okay, that line will be making a recurrence elsewhere :) 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] 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] Future Weather System
On 30 Jul 2011, at 20:31, Stuart Buchanan wrote: > So, I quickly wrote an alternative to the current Nasal system geodinfo(), > using the groundcache instead of the current scenery method. I'm working on a new (C++) navigation display instrument, which I hope to add a proper EGPWS terrain display layer too - replacing Skyop's Nasal version, with his full and happy consent :) I already reviewed the ground cache code, but I wan't sure how performant it would be, to scan the ND range (eg, 80, 160 or 320nm) at, say, 10 or 50m intervals. The problem is the EGPWS needs relative altitude to the aircraft, but in real-life the update isn't instantaneous, especially at longer ranges, so I expect to perform the scan incrementally over a few seconds. 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] startup crash in SimGear (with patch?)
On 1 Aug 2011, at 12:30, Csaba Halász wrote: > Indeed, I have been unable to run FG with particles enabled since a > long time due to random crashes in the particle code. Call stack > frequently included functions your description mentions, so I hope > this patch will fix that issue. Can anyone think of a reason particles are fine for some (many?) people without this patch? Of course the patch should be applied, I'm just wondering what would affect the ref-counting logic to hide the problem in some machines / environments. 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] Future Weather System
On 1 Aug 2011, at 22:35, Stuart Buchanan wrote: > In both cases, are you not going to be limited by what tiles have been loaded? Yes - I have wondered about separately loading the BTG files, but that seems like a world of pain. In the first instance, simply having the tiles loaded in the cache would be a reasonable start. James -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shadows
On 2 Aug 2011, at 15:38, Emilian Huminiuc wrote: > I thouhg someone knwledgeable with OSG, and the way we use it might take a > look, and see if it's worth the efort, or if it's possible to plug into our > code. Last time I asked, the problem is not the shadows code itself (OSG has several solutions), but integrating that with the way FG uses OSG - and as you said, it needs someone knowledgeable with OSG, and the way we use it, to do the actual plugging. James -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [SPAM] Re: [SPAM] Re: Proposal: Move airplanes to an SVN repository
On 12 Aug 2011, at 13:03, Emilian Huminiuc wrote: > On the pros side, maybe some sort of automatic solution similar to terrasync > could be implemented for aircraft, this solution would then benefit from a > centralized location (although that is not necessary, repository location > could be added as a tag in the aircraft -set.xml file). Already been discussed, and I have it 30% coded up - and it definitely does *not* benefit from a centralised repository! James -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. 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] Simgear - netinfo/in.h not available for windows
On 22 Aug 2011, at 10:28, Alan Teeder wrote: > Thanks for the fix. That was quick ! But not sufficient - I've reverted the whole set of changes until I have a chance to go over them again, since everything seems to have broken. Bah. James -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: 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] FG hangs while waiting for METAR data?
On 24 Aug 2011, at 08:57, Viktor Radnai wrote: > I could be wrong but it appears to me that FG will hang if the METAR > server is unreachable. I was using FG while connected to the Internet > via my phone (through wifi). Whenever my phone reboots or connectivity > is lost, FG would produce a square wave pattern on my CPU meter. It > would run for 10 sec and block for 20 sec with CPU use on 0, then run > again for 10 sec, etc. Disabling live METAR data would make this go > away. I presume this only happens if the connection to the METAR server > times out, but would be highly annoying to any user. Yep, this is known, I'm working on a fix, but the first attempt to commit it caused other problems - working on fixing the issues at the moment. See: http://code.google.com/p/flightgear-bugs/issues/detail?id=401 James -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear - netinfo/in.h not availablefor windows
On 25 Aug 2011, at 15:21, Alan Teeder wrote: > I understand that MS had fixed this particular bug back in Windows 2000 days, > but it seems to have crept back in – on my system at least. Should be fixed (in a different way) by an imminent FG commit. James -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear - netinfo/in.h notavailablefor windows
On 25 Aug 2011, at 19:44, Alan Teeder wrote: > Well, that fixed the compilation, but at run time I see: > > mismatch in socket address sizes > Error: connect() failed in make-client_socket() Pushed a Simgear change to hopefully fix this, or at least give more information when it fails - let me know what you see. James -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear -netinfo/in.h notavailablefor windows
On 26 Aug 2011, at 09:49, Alan Teeder wrote: > It compiles and run now, but I still see the error messages (mismatch in > socket address sizes etc... ) mentioned in yesterday´s post ;-( You should be seeing a bit more debug information, about why it's failing - relating to the size of the address structures, and the address family. James -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear -netinfo/in.h notavailablefor windows
On 26 Aug 2011, at 10:45, Alan Teeder wrote: > Here you are:- > > mismatch in socket address sizes: got 28, expected 16 > family: 23 Interesting, that's an IPX (as in, Novell Netware!) address - I've committed some additional changes so we're IP4 only for the moment, IP6 can be added fairly easily now though :) James -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear -netinfo/in.h notavailablefor windows
On 26 Aug 2011, at 12:21, Alan Teeder wrote: > Your latest fix seems to have cleared the error messages. And, it works, I hope? :) James -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The future of FlightGear's support programs
On 4 Sep 2011, at 07:05, Durk Talsma wrote: > If not, I might consider moving the taxidraw source over to gitorious and > incorporate it as a subproject of fg. > > Any thoughts / ideas would be welcome. I think this is best answer - for programs the original author wishes others to maintain / bugfix / enhance, they should live in the fg Gitorious project (not necessarily the flightgear repository, of course). This could potentially be done for Atlas, mpserver, and so on, if that helps development. Are there reasons *against* moving support programs into the fg project? Assuming the original developer is happy with other people on the flightgear committers list potentially apply patches / bugfixes, of course. Presumably we're require all such code to use the same license as FG or SG (i.e either GPL or LGPL) to avoid headaches and confusion. James -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Cmake
Hello everybody, Following some discussion at LinuxTag, and since, there is a rough consensus from the active C++ developers, to switch the FlightGear build system to Cmake (instead of automake / custom VisualStudio projects). To avoid having multiple build systems maintained in parallel, and code contributors feeling obliged to keep them all working, the plan is to actively remove automake and VisualStudio projects from the tree, so that everyone is using the same build system. Cmake isn't a perfect build system - but having a single build system that works everywhere, is more valuable than having several 'perfect' solutions that all need to be kept in sync. (Of course, CMake can generate Makefiles, Visual Studio projects, XCode projects, Eclipse and Code::Blocks projects) The plan is to drop automake and Visual Studio support around October 17th, so between now and then we need to fix any missing cases in the CMake support, eg lesser used platforms such as FreeBSD & Cygwin+gcc, and ensure any obscure configure options also exist in the CMake world. (Updating the build instructions documentation on the wiki, and scripts to refer to cmake would also be good!) If you regularly pull+build 'next', please try a cmake based build, and report any issues you encounter - CMake should work 'out of the box' on Mac (Makefiles or XCode), Linux (32- and 64- bit) and Windows (VisualStudio 2008 and 2010 - mingw and cygwin may need some fixes). CMake's packaging tool, CPack, also adds the possibility of automatic .deb and .srpm creation - I've done some limited work on support this, but if anyone on Fedora/Debian/Ubuntu wished to move this forward, it should be relatively easy to get working. Regards, James -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
On 5 Sep 2011, at 17:10, Curtis Olson wrote: > So I have nothing against cmake, it sounds like it offers some nice features. > But I assume those that want to push this change forward, will take some > time to write up some basic howto's so that people who have never used it as > a developer can get up to speed without too many problems? > > Right now when I poke around on the wiki and I'm sure the getstart manual, > all the instructions are automake based. Hopefully we can do some proactive > hunting of automake references in our instructions scattered around and get > those cleaned up in advance? > Are there any cmake based build instructions available anywhere? I'm not > seeing them. Yes, absolutely - Brisa's helper script also needs to be updated. We're at the start of that process now, but I don't want to document things if they are about to change, which brings me too: > > When building OSG, you run "./configure; make; make install" like any other > project. However, ./configure is an automake/conf generated in flightgear. > For a cmake dummy, how do you even go about building flightgear with cmake? > (I of course know everything, but I do have a friend who's a little > inexperienced with cmake.) OSG supply a 'configure' script for sue with Cmake, and we can do the same, to keep things more familiar for people. I'll look into borrowing the CMake one :) > Is there a way to do the equivalent of "make dist" in cmake to generate > .tar.gz source releases? Has this been tested to see if it includes all the > necessary files? That's what CPack does - I've tested tar.gz creation, and there is some supported for Slackware TGZ / .deb / .rpm creation too. I'm sure the rules need some improvement to catch all the docs / utils / data files that the current make dist captures. > We have some extra automake rules to help create the data archives (which is > important because this officially defines what goes into the release > installer for both Mac and Windows as well as the data archive for people > building from source code (who aren't doing 3Gb of git for the data tree.)) Indeed! > I'm just hoping the cmake jocks will put themselves in the position of > non-cmake jocks and help ease the transition from multiple fronts for many of > our different classes of users/developers. Yes absolutely, and feedback (like above) is the driver for that. james -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frame rates in git version?
On 12 Sep 2011, at 18:47, Mathias Fröhlich wrote: > May be anybody is willing to write something down in the wiki? > I guess this googles well too ... I've started a wiki page for Cmake, anyone can improve it, and some of the information is already out of date as Mathias and Fred improve stuff. James -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mac 2.4 binary crashes
On 13 Sep 2011, at 19:53, Adam Dershowitz, Ph.D., P.E. wrote: > I just downloaded the new 2.4 release for Mac. If I try to launch the app, > it just immediately quits. > I can successfully run this version of FlightGear from the command line, so > the problem must be with the launcher. I am not sure the best way to report > this, so I am starting here. > Running on Macbook Pro 10.6.8. I'm guessing you don't get any kind of crash report? Check Console.app for the system message log, hopefully there's something there about RubyCocoa (which the launcher is built upon) Regards, James -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Repeatable random seeds
On 14 Sep 2011, at 12:00, Stuart Buchanan wrote: > OK. We've got something similar already in the C code for exactly this > purpose. Might be more efficient to simply expose that over Nasal, but > I'm not sure how easy that would actually be. Pretty trivial, for a function such as sg_random, unless I'm missing something really subtle. Basically add a f_random wrapper in NasalSys.cxx, add an entry to the static table at the bottom of the file, and you should be done. Oh, except you need to pick a name that doesn't clash with any internal Nasal rand/random. James -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] navinfo()
On 14 Sep 2011, at 14:34, Scott wrote:
> I'm playing around with extending the NasalSys.cxx navinfo() function that
> torsten wrote.
> >From what I can tell it calls navlist.cxx findByIdentAndFreq(position,
> >ident, freq, type)
> which then calls findByIdentAndFreq(ident, freq, type) and does a distance
> filter on the result.
>
> The problem is the findByIdentAndFreq() methods require a partial Id, and
> this isn't always the case.
> I'd like to be able to call navinfo() with a position and radius distance,
> and to get back a list of all navaids within the radius range.
>
> Is there another method that I haven't seen that would return the nearest
> navaids items from the database?
There is, one of the FGPositioned spatial queries, which could be exposed via
Nasal. However, I already exposed these via an alternate method - I didn't want
to add lots of Nasal proxies for each item we have. You can issue a search via
a regular flightgear command, and the resulting navaid(s) can be stored into an
arbitrary property tree location.
The command is called 'find-nearest', it takes a maximum search radius in NM, a
search position, and list of types to search on (NDB, ILS, VOR, or anything
else in the positioned DB).
Eg, from Nasal:
fgcommand("find-nearest", props.Node.new({type: "vor", max-results:10,
results:"/some/node/path"}));
Will load the ten closest VORs to the current aircraft lat/lon below
/some/node/path
(or as many as possible within the default search radius, 400 nm)
James
--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
Learn about the latest advances in developing for the
BlackBerry® mobile platform with sessions, labs & more.
See new tools and technologies. Register for BlackBerry® DevCon today!
http://p.sf.net/sfu/rim-devcon-copy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mac 2.4 binary crashes
On 15 Sep 2011, at 21:24, Adam Dershowitz, Ph.D., P.E. wrote: > /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/shell.rb:43: > warning: method redefined; discarding old debug= > /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/shell.rb:107: > warning: method redefined; discarding old debug= > /Applications/FlightGear.app/Contents/Resources/SearchableOptions.rb:46: > warning: instance variable @table not initialized > /Applications/FlightGear.app/Contents/Resources/SearchableOptions.rb:46: > warning: instance variable @table not initialized > /Library/Frameworks/RubyCocoa.framework/Resources/ruby/osx/objc/oc_wrapper.rb:17:in > `NSApplicationMain': NSApplicationMain - > RBException_OSX::OCMessageSendException - NSCFString#+: - methodSignature is > nil. (OSX::OCException) > from /Applications/FlightGear.app/Contents/Resources/rb_main.rb:38 > > Does that help at all to make sense of the cause? Sadly not really - just to explain, the Mac launcher was written by Tatsuhiro, the Macflightgear.org maintainer - while I can just about understand RubyCocoa, problems like you're experiencing are some way beyond my comfort zone. Hopefully Tat will respond to this thread, but he's generally quite busy. James -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Segfault after hostname lookup failed
On 16 Sep 2011, at 10:37, Andreas Gaeb wrote: > I just tried to run with real weather fetch, but the network cable was > not plugged. This produced a segfault after about a minute, see below. > Somewhere the information that the lookup has finally failed seems to > get lost. After re-plugging the cable, everything was fine. Whoops, nasty bug by me! Thanks for the report. Fix to follow. James -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] proposal: new keybing to show map
On 20 Sep 2011, at 19:35, Francesco Angelo Brisa wrote: > something like ALT + m to be added to the keyboard.xml. > I have found the map useful, specially for a short look out, which if > best used using a key press. > > Here my xml adding to the keyboard.xml if ok. > > > m > Show map > > > dialog-show > map > > > Sounds fine to me, the only reason I didn't add a binding originally, was worry that every possible key combination was assigned by someone to something already :) James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with compiling Flightgear
On 22 Sep 2011, at 09:07, Jason Cox wrote: > I am having an issue with compiling the lattest git version due to a > lack of a libhal on my system > > after check the web site for libhal > (http://www.freedesktop.org/wiki/Software/hal) I found that it now in > maintenance mode and they are switching to udisk,upower as a > replacement. > > This in turn make lib hal unsupported on my system as Gentoo has already > gone to upower and disabled both hal and upower on the same system. Yep, I'll flip back the logic for this in Git (unless someone beats me to it). Unfortunately this probably means switching to a less portable way of accessing the information on Linux. James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fix for missing references to SGThreads/SGMutex
On 24 Sep 2011, at 09:04, Mathias Fröhlich wrote: > Yes, I can see that libGL and libz is just pulled indirectly which no longer > works on very new linux ld variants. Arrgh, really? That's news to me. James -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] latest Git next, endless loop from FGATCMgr and missing JSBsim fuel-used property
On 25 Sep 2011, at 08:36, Scott Hamilton wrote: > 2. After about 1hour of flying, FG seems to go into a endless loop; the > sound continues to play, however the screen is frozen (goes to black if you > minimise then re-maximise it), and all network activity drops off (ie: you > disappear from multi-player) > I ran it with gdb and notice the following stack; We've seen issues like that before, when _geo_inverse_wgs_84 is used over large (eg, half the planet) distances. The workaround / fix has been to switch range checks of this nature to convert coordinates to cartesian space (earth centred) and then use cartesian distance - not appropriate for navigation, but fine for a range check (and quicker too). James -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] pthread error compiling simgear under ubuntu 11.10 (beta2)
On 27 Sep 2011, at 09:00, Francesco Angelo Brisa wrote: > ok, now I will "cmake" fgfs too and send the new script to Thorsten. > > Thaank you ! That's good news indeed! James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] latest Git next, endless loop from FGATCMgr and missing JSBsim fuel-used property
On 25 Sep 2011, at 09:10, James Turner wrote: >> 2. After about 1hour of flying, FG seems to go into a endless loop; the >> sound continues to play, however the screen is frozen (goes to black if you >> minimise then re-maximise it), and all network activity drops off (ie: you >> disappear from multi-player) >> I ran it with gdb and notice the following stack; > > We've seen issues like that before, when _geo_inverse_wgs_84 is used over > large (eg, half the planet) distances. The workaround / fix has been to > switch range checks of this nature to convert coordinates to cartesian space > (earth centred) and then use cartesian distance - not appropriate for > navigation, but fine for a range check (and quicker too). I just pushed a tweak to make this code work in cartesian space, thanks for the bug report. James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric haze modelling
On 28 Sep 2011, at 21:14, Curtis Olson wrote: > I suppose it would make sense to grep through the code, but as far as I know, > the primary uses of the visibility value is to properly set the OpenGL fog > parameters and determine how many rings of tiles to load centered on the > current location. >From a software engineering perspective, it would be great to have a >centralised, explicit place where visibility is managed, and especially the >purpose of visibility - since what's needed for scenery loading vs 'fog' >(atmosphere effects) vs weather loading vs AI / multiplayer ranges may not all >agree, but most of those things currently look at the global visibility >property and make some guesses, or apply some heuristics based on that number. Unfortunately, going through the code to find out what will break, is an ugly job - as you have probably realised. In the short term, I think most systems need a 'how far away do I conceivably need to load / simulate items' metric - not necessarily in meters - but really that should be dependent on the observer position of course. Hopefully ThorstenB will have some comments, since he's the person who most recently touched the tile-loading code, which is by far the most sensitive thing (in terms of system performance) for how we compute visibility. James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On 30 Sep 2011, at 11:56, Martin Spott wrote: > Hah, I managed to find the web page I've been searching > for weeks, Bruce did a pretty nice writeup of the problem: > > http://www.cullam.com/flightgear.htm A very useful description, yes! James -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Query about groundradar Instrument module
On 30 Sep 2011, at 19:52, Michael Robson wrote: > Essentially what I am looking to do is create some instruments of my own with > some detailed generation of graphical entities that are being continually > updated. I am therefore assuming that a 'dynamic texture' is the way to go > with this. If there is another way, perhaps better, then I am open to > suggestions! Correct, basically. Also note i just added a 'NavDisplay' instrument to Git, which is another kind of dynamic texture, along with ground-radar. It's new, untested code (that's part of my plan for this weekend), but is designed to show navigation type info (route, waypoints, traffic, airports, navaids) in a customisable way, and hence be used to simulate the navigation modes of various modern cockpits. Depending on what you want to do, you might be able to use the code as is, or certainly use it as an example (along with the other render-to-texture instruments) But, be aware I'm still shaking the bugs out - and then I need to write some docs :) James -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On 1 Oct 2011, at 03:33, Curtis Olson wrote: > That could very well be true ... and I don't think it would be a huge coding > change ... but it should be done in a way that bumps up the btg version > number and picks a new packet id so as to maintain backwards compatibility > with all the existing scenery out there. Just looking at the relevant Simgear code - it already runs through GZip, so I'm not worried about overhead there - and the versioning system looks pretty sane to deal with too. There's already the version check for short-vs-unsigned-short counts, adding a new version increment and making the values longs looks pretty easy. BUT, if I modify the current Simgear code on 'next', is that the only place that needs to be changed, or is there another copy of this code somewhere in the terragear repo? I know terragear depends on simgear, but I've not looked at which code is actually shared. James -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On 1 Oct 2011, at 15:37, Curtis Olson wrote: > We need to modify the loader in simgear as well as the format generation code > in terragear. Right now the indices are packed as 2-byte short ints in the > binary .btg file so of course making a change only to the simgear side will > do nothing to fix the problem. > > Whatever we do needs to happen in close coordination with the terragear code > in order to make sure that the changes match and are sane and reasonable from > both perspectives. > Okay, but the relevant source file (sg_binobj) appears to contain both the read *and* write code paths - which is really what I was asking - is the write logic in sg_binobj.cxx the one terragear uses, or 'something else'? James -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On 2 Oct 2011, at 19:00, J. Holden wrote: > Still, as a scenery developer and not a programmer, I'm still wondering what > the limit is before the "swirlies" start floating around. Is it vertices? > Fans? Triangles? It's 65536 vertices per BTG, in total. Strictly, this isn't true - the BTG format already supports 2^32 vertices / normals / colors in the file, but any object (tri / strip / fan) can only specify any index from 0..65535, so the higher vertices can't be used in any meaningful way. The good news is, I have the code to read a newer version basically done, which will make all the indices 32-bit, while of course keeping compatibility with existing BTG files of the current versions. Bad news is, we also need to update the writer code, and then measure how much the file size increases, after gzip compression. James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On 4 Oct 2011, at 13:34, Curtis Olson wrote: > Here's a random idea on the writer side: > > Would it be possible to do something like: > > if (size of any of my structures are > 65535) then > write_32bit_index_btg() > else > write_16bit_index_btg() > endif > > Then we'd be spending are larger index bits on the files that need them, but > not paying the penalty across the board on every scenery file. Entirely possible, yes - however I *suspect* it's unnecessary since gzip will compress the larger indices back down to a few % larger than what we currently have. Of course, I can't confirm or deny that suspicion until I upgrade the writer code path too :) James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of issues
On 6 Oct 2011, at 18:17, ThorstenB wrote: > However, when someone writes to the tied property using the "normal" > property interface (setprop in Nasal or via the C++ SGProperty::setValue > methods), then property's change listeners should fire normally. > So, it depends on how a value is changed. But generally listeners aren't > guaranteed to work with tied properties... Except, it's possible to manually fire the listeners on such properties, eh, during subsystem::update. Of course, this means there's little point in having a listener, since you may as well have used a Nasal timer and just read the property each time. James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On 4 Oct 2011, at 13:53, James Turner wrote: > Of course, I can't confirm or deny that suspicion until I upgrade the writer > code path too :) I've committed an updated BTG reader/writer to simgear/next, which supports the current format, and a higher-versioned format with 32-bit indices. Based on some conversions, 32-bit indices (all zeroes so far) compress down with gzip -9 to a tiny size increase over 16-bit indices (less than 4%), but I've also added code on the write path to check the maximum index size, and select the output format - so tiles will be in the current format until they exceed 2^16 vertices. If someone could incorporate the revised sg_binobj.cxx from simgear/next into simgear-cs, and verify the results with terragear, I'd be fascinated to know if the 'swirlies' are gone! (Or, of course, if you encounter any issues - perish the thought) James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cloud shadows
On 7 Oct 2011, at 09:47, thorsten.i.r...@jyu.fi wrote: > Sorry, I'm just getting a bit touchy about reading 'we need' - I've had > too much of that recently. In my experience, for a happy life in open-source development, work on what *you* *enjoy*, not what 'we' 'need'. At least, some of the time. More than 50%. :) James -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New environment properties (Was: A collection of issues)
On 8 Oct 2011, at 09:40, Lauri Peltonen wrote: >> Is there a way of putting things to the GPU such that they're only >> computed once per frame? Given the structural issues in how FG uses the GPU, I really wouldn't worry about this code running on the GPU - just do it on the CPU for the moment. I.e, we need to be using the GPU/OSG smarter / more efficiently, not overloading it doing tasks we have CPU spare to do occasionally. James -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On 7 Oct 2011, at 19:24, Martin Spott wrote: > This is what happens when running 'genapts' with a modified > 'simgear-cs' on a _really_ simple airport layout (EDKA, consisting of > just one runway and two windsocks): > > Starting program: /home/martin/install_headless/bin/genapts > --input=/home/martin/landcover/EDKA.dat.gz --work=/home/martin/workdirs > --clear-dem-path --dem-path=SRTM2-VFP-3 --dem-path=SRTM2-Africa-3 > --dem-path=SRTM2-Australia-3 --dem-path=SRTM2-Eurasia-3 > --dem-path=SRTM2-Islands-3 --dem-path=SRTM2-North_America-3 > --dem-path=SRTM2-South_America-3 --dem-path=DEM-USGS-3 --dem-path=SRTM-30 > --nudge=20 --min-lon=2.8 --min-lat=49.8 --max-lon=8.2 --max-lat=54.2 Ouch, that's bad - I was testing by 'transcoding' existing BTG files (read in, write out, read in again, verify everything looks sane) - since I didn't (yet) attempt to build or run terragear. What's the easiest way for me to get enough data to run gen-apts? Can I rsync / download a small set of data, or do I need to setup a complete terragear environment? But maybe it's time for that, anyway :) James -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear branch, next, updated. b16338598afd886e8aed8da2da5085d65effbc28
On 11 Oct 2011, at 21:09, Flightgear-commitlogs wrote: >Reduce AI/MP lags when removing models >Move load of removing OSG objects to the OSG pager thread Excellent, nice work Thorsten. (Thread-safety for the win :) James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On 14 Oct 2011, at 23:42, Jason Cox wrote: > I then did a git pull just to make sure that it wasn't a file that i > missed but it reports that i am up to date. I've been doing some TerraGear hacking recently, so I'm the most likely person to have caused this, but on both my systems (Linux and Mac) this builds with problem, so I'm not sure what to say! James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On 15 Oct 2011, at 15:22, HB-GRAL wrote: >> I think the only solution is to make GPC obsolete - either by replacing >> GPC by something different but functional equivalent or "simply" (TM ;-) >> by avoiding any polygon clipping in 'fgfs-construct' overall. >> >> Martin. > > Hi Martin > > Are there any concrete suggestions ? Yes, it's being actively hacked on and tested, I believe, because the clipper is the most numerically sensitive part of the whole process, and performance sensitive too. One candidate is being tested already, and there's other options available, but it's really important not to regress the core functionality, so some caution is required! James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Cmake (soon)
It's been a month since I announced the intention, to switch all the main FG platforms to use CMake, and to deprecate and remove the other build systems from Git. There's been many small improvements in the Cmake files since then, which I hope have eased some people's concerns about the switch. (Notably Brisa' compile scripts have been updated to use Cmake!) I still have some work to do, to ensure the 'make dist' rules are handled property in CMake, so we don't get a shock when releasing FG 2.6 in a few months. Are there are any other issues people have, areas they think should be tested, etc? I'd love to know the status of cygwin and mingw, but only people who run those environments can test or improve them. Barring last minute surprises, my intention is to declare the other build systems 'dead' next weekend (the 21st), and then gradually start disabling Jenkins jobs, removing files, and so on. The idea is to force everyone who runs FG from Git, to definitely be testing and using CMake, in plenty of time for the 2.6 release. Regards, James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake (soon)
On 17 Oct 2011, at 18:38, Curtis Olson wrote: > Would it be possible to write a quick "howto" for doing some basic > coding/developer things in cmake. Like: "how to add a new source file to the > project." Or "how to add a new module/library to the project".Maybe a > few quick summeries of "how to install in a custom directory", how to build > with custom compiler options, how to configure for debug vs. release build, > or some the more subtle build options that invoke different levels of > optimizations or warnings. I've written this up, at least a first attempt, will commit it later today, and people can review it for sanity / correctness / omissions :) > Either that, or our cmake experts need to be willing and ready to respond to > frustrated "dumb" questions in a timely manner -- and do that over time if we > don't have central place to find this information without investing the > required time to become cmake experts ourselves. I'm assuming that's true regardless :) James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On 18 Oct 2011, at 23:21, dave perry wrote: > 2. Assuming the answers are no, yes, to #1, will all these repositories > be centrally located so one can track new or modified ac of interest? > > 3. Is there any interest in creating repositories by ac class/type? > e.g. historical, military-fighter, military-transport, > civilian-light-ac, airliners, etc. Jus tot keep repeating (forever, until I have time to write the code) - don't confuse development and deployment here. The package system I'm working on includes the notion of aircraft catalogs (each an XML feed), listing aircraft. It's up to the catalog maintainer which aircraft he adds to it (or authors he allows to add to the catalog), and it's up to the end-users which catalog(s) they subscribe too. I'm also trying to force some metadata as part of this, about era / type / usage, so someone could create a '1950s Military' catalog, or alternatively use a 'all-aircraft' catalog, and then do a filter by era / class / license / rating / something else. James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On 19 Oct 2011, at 10:15, Edheldil wrote: > Is there any written spec on this system? I got frustrated when looking > for a specific aircraft in fgrun :) and so I suggested something similar > several days ago on IRC, but it got confused with a/c rating. > > If I understand you correctly, "submit a/c to a catalogue" would mean > that the information would not be kept in the a/c data - which has its > pros and cons. I rather think that the metadata should be in the a/c > itself. Maybe some combination would be the best of all worlds? http://wiki.flightgear.org/Aircraft_deployment One thing has changed since I wrote that - I'm probably going to put the metadata in a *separate* file from the -set.xml (but still part of the aircraft zip / distribution) because it means the system can handle 'non-aircraft' packages (eg, shared Instruments) that lack a set file, and it also simplifies handling multiple aircraft variants (set files) in one package. For encoding the metadata, I'm assuming an open-ended scheme, using properties, but with a standard ontology defined on the Wiki. I don't really what the ontology is, but obviously it will include era (1930s, 1950s), type (fixed-wing, glider, heavy), role (general aviation, commercial, bomber, fighter, etc), and so on. It could an arbitrary number of rating systems too, eg: 1950 fixed-wing-jet commerical beta/alpha/production GPL/freeware/CC-SA-nonsense 5 56 ... and so on Again, I'm not worry about the onotology until I have enough code written that it matters, which will be a few months time, probably. James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear aircraft repository
On 19 Oct 2011, at 11:53, syd adams wrote: > while the central repository is a fine > idea , after the move to git , I lost any commit rights to my own > work, so after a time i gave up on the idea of maintaining them and > started my own repositories . I would have happily continued to > maintain/upgrade them , and I,m hoping this change might make things > easier Hmm, that's a straight technical oversight - myself or any other the admins would have added you in 10 seconds, if we'd know there was an issue. My understanding was that all people with CVS access were granted commit access after the move to Git - that was certainly the intention! This is orthogonal to your points about courtesy to authors when making changes to their aircraft, which I also agree with - I just wanted to be clear we don't confuse an administrative screw-up with a 'policy change' that never in fact happened. James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear aircraft repository
On 19 Oct 2011, at 12:27, thorsten.i.r...@jyu.fi wrote: > Most of us are adult people, and most of the time we are able to act like > civilized people, i.e. we can work out things in a reasonable way without > invoking the law and waving license around. There are some rules for > emergency cases necessary though. So, I'm pretty sure no one will go ahead > and modify your stuff without asking you first as long as you're around > and participating. Hasn't ever happened to me (and the temptation must > have been there...). +1 to all of this, thanks to Thorsten for expressing it very nicely! James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On 19 Oct 2011, at 16:27, Curtis Olson wrote: > Right now we've replaced a one-line command with several weeks of manual > work. (Or so it appears.) I understand the reasons, and we need to move > forward, but I think this is a logic gap here -- an unforeseen side effect, > and a problem we (someone) needs to scramble on to address. The intention is create a super-module which has each aircraft as a submodule. Eg an 'all-aircraft' repository, for people who want this. Ideally someone with some scripting skills would automate creating that repository, and then we're back to a few steps: clone init submodules pull (which will recursively pull, and take ... some time) James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On 19 Oct 2011, at 17:47, Curtis Olson wrote: > One more super module question: if I start plowing through 350 aircraft by > hand, and then next week you come out with a super module, will that require > me to redownload everything, or can that be retrofitted on top of the modules > I've already fetched? I think you need to re-download everything, I'm afraid. But maybe a Git expert can correct me. James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On 20 Oct 2011, at 09:48, Jason Cox wrote: > I am trying to test some builds around YWLM and just need to know if the > changes for higher detailed scenery that you spoke of is in the repo? > > How do I tell the changes that were made to sg_binobj.cxx as I do not > understand how to drive GIT to change to a branch? Yep it's all committed, and even tested! However you do need a tearrgear compiled against latest simgear, *not* against simgear-cs. James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] CMake, tomorrow (Sunday 23rd)
Hello again, Barring last-minute objections, I would like to declare CMake 'the' build system, from tomorrow onwards. Since my last email I've added a README.cmake to flightgear, and I'm working on ensuring the 'make dist' features of automake are replicated in CMake (via CPack) so when 2.6 time comes around, we don't have too many surprises. My plan is to disable the automake builds on Jenkins tomorrow (Sunday), and then start removing the automake build machinery, and the projects/ subdirectory, from the simgear and flightgear source trees. (I can create a Git tag prior to removing any files, if that's of interest?) If there's lingering queries about Cmake, or requests on the 'best' way to handle the transition, please let me know. Feedback on the README file would be appreciated too, or even commits / patches to improve it! Regards, James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
On 22 Oct 2011, at 16:09, Curtis Olson wrote: > It might be a bit extra work, but it would be good to take the source.tar.gz > files that cmake creates, unpack them in a new directory and just make sure > we can do a clean build from them. This always seems to expose a file or > two, or a header that someone forgot to add to theautomake.am so it never got > included in the source distribution. (i.e. you could build from git just > fine, but things were missing in the source distribution.) These are usually > easy to fix, but it's good to catch them earlier rather than later. Will do! Although, the CPack approach to this is rather different from automake - basically it packages *everything* in the source dir. I've added exclude rules for .git and .gitignore, but aside from that, everything from Git goes into the source tarball. Is there anything else that ought to be excluded? I can't imagine what that might be, but suggestions welcome. James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed
On 22 Oct 2011, at 16:26, S Andreason wrote: > Is there any recommended way to reference instruments outside the > aircraft's directory? > Currently I am using > ../../../Instruments-3d/alt-2/alt2.ac > and > ../../../Generic/Effects/smoke.png > etc. Please use: /Aircraft/Instruments-3d/alt-2/alt2.ac /Aircraft/Generic/Effects/smoke.png OR Instruments-3d/alt-2/alt2.ac Generic/Effects/smoke.png Either way is fine, and will work for the future. (Thorsten B, should we recommend one or the other as 'best practice'?) Note relative paths are fine 'inside' an aircraft's directory, still. It's just 'cross-aircraft' paths that should be defined as above. James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On 23 Oct 2011, at 00:41, Jason Cox wrote: > I can now build more scenery but still hit the "spaghetti network" > around YSSY. > Was the change that you made only to a 32bit int? > What do i need to do to change to 64bit int? I'd be pretty suspicious of this - much more likely, there's a bug in my code, than you actually need 64-bit indices. I won't say 'impossible', but I don't think GPUs or OSG actually support indices larger than 32-bits anyway, and even if they did, you'd still bring your GPU to its knees before hitting that limit. I have tests for > 2^16 vertices / texture coords, which are all working, which suggests there's 'something else' going on. (Or my tests need to be extended) Can you make available, a zip/tarball with your work directories, so I can test locally? Or the produced btg? James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed
On 22 Oct 2011, at 23:20, S Andreason wrote: > I know you'll say everybody must upgrade, but I still see a lot of > downloads of my models for older Fg versions. (Which does make sense for > older graphics hardware.) Yep - I would say upgrade - but I understand there's reasons not too. If possible, I'd suggest maintaining multiple versions of the download (2.0 compatible and 2.4 compatible), but of course that's more hassle for you. Fundamentally, we want aircraft to do things they previously did not (work outside FG_DATA), and without introducing too many hacks, so there has to be a compromise somewhere. James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
On 23 Oct 2011, at 09:31, Erik Hofman wrote: > CMake worked like a charm but I did notice that the special purpose > FDM's don't get included anymore. I believe I did see it mentioned in > the CMake configuration but leaving code out on a development system > might introduce a chance of bit-rot. > That said, I think some of the SP FDM's can be removed entirely since > they've been superseded. The special purpose FDMs are disabled by default, it's one line to make them enabled by default of course! Actually, one of my post CMake build plans, is to make all the FDMs switchable at build-time, partly because I'm sick of all the compiler warnings from the UIUC / larcsim code, but also because at some point in the future we want the FDMs to be more 'modular' to the rest of FG - eg in their own thread or HLA-process, potentially. Knowing that the code builds cleanly with, for example, *just* the Null/UFO FDM selected would be interesting. So we will have ENABLE_YASIM, ENABLE_LARCSIM, ENABLE_JSBSIM and so on. Obviously I will keep the defaults for those to match the current expectations (well, maybe Larcsim could be off by default? Does anyone ever use it?) But you've convinced it's a good idea to have a Jenkins build, which has all the FDMs enabled, to avoid bit-rot in the special ones! Thanks for your feedback, James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
On 23 Oct 2011, at 18:47, Geoff McLane wrote: > Sorry, what am I doing wrong? I'm not sure *exactly* what you're doing wrong, but in general I would say you're over controlling things a little. I'm not clear why you are installing each component in a subdir of install - that's making your life complicated. If you simply installed OSG to /home/geoff/fg/fg16/install (as CMAKE_INSTALL_PREFIX when configuring OSG) then assuming you have (from Git) /home/geoff/fg/fg16/flightgear /home/geoff/fg/fg16/simgear you should simply need: cd /home/geoff/fg/fg16/ mkdir fgbuild mkdir sgbuild cd sgbuild cmake ../simgear -D CMAKE_INSTALL_PREFIX=/home/geoff/fg/fg16/install -D CMAKE_BUILD_TYPE=Release make install cd ../fgbuild cmake ../flightgear -D CMAKE_INSTALL_PREFIX=/home/geoff/fg/fg16/install -D CMAKE_BUILD_TYPE=Release make install Of course you can set CXXFLAGS or CMAKE_VERBOSE_MAKEFILE is you need, but I would avoid setting OSG_DIR, SIMGEAR_DIR or SIMGEAR_LIBRARIES unless you need something very special - just use a common destination prefix and everything works out easily! (And there's no need for a LIB_POSTFIX, it defaults to empty for Release builds) Does that help at all? James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Skydome and Terrain shader with haze - some helprequired
On 24 Oct 2011, at 08:46, thorsten.i.r...@jyu.fi wrote: > I've now tested a few more things: There are still some issues with ocean > tiles left - I *think* throwing in more vertices will fix this, or > Emilian's hack of testing point altitude against layer altitude rather > than doing trigonometry. I've committed the first part of the code changes to SGOceanTile to increase the number - I"m still deciding the best place to control the value. In the short term, you can hack the default values in SGOceanTile.cxx (right at the bottom, latPoints / lonPoints default to 5) and see if this magically improves things or not. James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Skydome and Terrain shader with haze - some helprequired
On 24 Oct 2011, at 10:09, thorsten.i.r...@jyu.fi wrote: > Yes, the angles between eye and sun are constants per frame throughout the > scene :-) So is hazeColor. My problem is not passing the value from the > property tree, my problem is getting it there - I'm not a C++ coder, I > have no clue where to look for gl_LightSource outside the shader, I have > no idea how (lat/lon/alt) property coordinates map into (x,y,z) in the > rendering process and I have no real idea how to make a vec3 out of > property values. I believe that's an area I / Mathias / Tim can help with, if pestered sufficiently :) In my case mostly re-using other people's code - thanks to Mathias we have a good library of functions to map geodetic/geocentric coordinates (lat/lon/elev) to various cartesian reference frames - earth-centered, the 'local viewer frame', which is pretty close to the OpenGL XYZ, and others besides. James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fgpanel and ubuntu 11.10 build linking failed on libz, solved.
On 24 Oct 2011, at 11:54, tuomas.kuosma...@gmail.com wrote: > Hi folks, and a quick hello, myself being new to this list. :) > Hello, and welcome! > Here's just a quick note when compiling from git on ubuntu 11.10, I had to > add SIMGEAR_LIBRARIES to the linking section on utils/fgpanel CMakeLists.txt, > it would fail on missing symbols on libz otherwise. > > After this fgpanel (and the whole flightgear) built fine. Now, I am not very > familiar with cmake, but I just compared fgpanel files with fgadmin and this > was the first difference I noticed (as fgadmin built ok). This is strange - libz should be part of 'SIMGEAR_CORE_LIBRARY_DEPENDENCIES' - we don't want to use SIMGEAR_LIBRARIES in fgpanel, since that makes fgpanel depend on OpenSceneGraph, which it should not. Also, there is something configuration dependent happening here, since other people have reported a similar issue (also with Ubuntu 11) on IRC, but I don't see the issue on my Ubuntu install. Anyone else seeing this problem (on any other distribution?) James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
On 24 Oct 2011, at 13:17, Geoff McLane wrote: > > In my case I like to be able to compile > against different versions of say OSG - like - > > OSG301=1# stable release 3.0.1 - default > OSG283=0# general release 283 - option > OSG299=0# another development release > OSGTRUNK=0 # option, for 'trunk' version > > I have yet to try the idea from Mathius, using > a semi-colon set of paths, maybe replacing some > or all the 'export' items, like - > -D "CMAKE_PREFIX_PATH=/path/to/osg;/path/to/simgear;..." > - this seems a good idea to try... maybe cmake > will like it ;=)) Okay, *but*, for your own sanity, you need to keep the Simgear-built-against each of these separate too (anf FlightGear). By all means install each OSG somewhere special, but then you need to build FG and SG against the same version - so you may as well share a prefix for that build config (this is what Jenkins does to build trunk OSG vs stable) Put it another way - you need to reconfigure and rebuild SG & FG entirely, when switching OSG version, so I don't see any problem with installing to the prefix for that OSG build too. I'd do: mkdir osg-build-301 cd osg-build-301 cmake ../path/to/osg-301-source -DCMAKE_INSTALL_PREFIX=/path/to/install/dist-osg-301 make install cd .. mkdir sg-build-with-osg-301 cd sg-build-with-osg-301 cmake ../path/to/simgear -DCMAKE_INSTALL_PREFIX=/path/to/install/dist-osg-301 make install cd .. ... and repeat once more for FlightGear Mathias' suggestion also works, BTW - specify CMAKE_PREFIX_PATH, with one (or several) paths to search - I tested that this morning and updated the README. As you guessed, manually setting the the detection variables (SIMGEAR_VERSION_OK, etc) is a bad idea, unless you set *all* the generated variables correctly - not impossible, but a lot of work. The error you report looks like it's happening because the detection script has got confused, but I need to see the arguments / environment passed to CMake, to understand why. James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On 25 Oct 2011, at 03:03, Geoff McLane wrote: > You can find it here - > http://geoffair.org/tmp/5426688.btg.gz > > So tomorrow to try to discover is the problem in > the fgfs-contruct output, the write, or in the > fgfs read and rendering... I'll take a look too :) All the info above looks very sane - nothing anomalous in the vertex/tex-coord counts. James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
On 25 Oct 2011, at 09:39, Adrian Musceac wrote: > Hi James, and thanks for updating the readme. I may be blind or just stupid, > but I can't find a way of setting CMAKE_PREFIX_PATH in KDevelop that works. > Adding it to environment variables does not do anything, and cmake fails to > find the libraries. Do you, or anybody else, know how to get KDevelop to use > custom paths the way cmake does with > -D CMAKE_PREFIX_PATH ? > I'm using KDevelop 4.01 on Debian Squeeze. It's a cmake variable, not an environment one, so I guess all I can really say is 'set it the same way you pass any other variable to cmake in Kdevelop' - but that's not much help, I appreciate! Note from the command line, you must not include a space between the -D and the cmake variable name, i.e I need to do: cmake ../source/dir -DCMAKE_PREFIX_PATH="/path/one;/path/two" (the quotes are necessary if specifying multiple paths for me, otherwise bash treats the semi-colon as a command separator - depending on how Kdevelop invokes cmake, that may or may not be necessary for you) James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft split
On 25 Oct 2011, at 14:30, syd adams wrote: > I haven't thought it out too deeply , but > maybe in this format : > > Aircraft: Citation-X > Author: Syd > Licence: GPL > URL: git clone or download url > Splash: path/url to thumbnail > > It would be up to the aircraft developers to fill it in and maintain > it, and possibly a nice little GUI could be created to automate the > viewing and downloading. > Just a thought. I'm working on pretty much exactly this, only with a bit more intelligence - version numbers, mirrors, other metadata. It will happen, but there's quite a few parts to get working - including the GUIs as you mention. James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
On 25 Oct 2011, at 15:20, Geoff McLane wrote: > > >> need to see the arguments / environment >> passed to CMake, to understand why. > But in each case I have explicitly given you > the exact exports and cmake commands used... > > What more do you need? The problem is you've confused me, with all the discussion :) So it would help, to be able to see exactly the commands, all of them, in one place - maybe upload your scripts to someplace? Then I can get an overview of what you're doing. > 1. can NOT compile sgsound due to NOT finding > > > Of course I can manually fix this in the > MSVC IDE, *OR* I could COPY AL/al.h to the > '3rdparty/include' I am using, that already > contains many other of the 3rd party > dependents... > > But the 'correct' fix would be for the > CMake GUI ask where to find it... > > How can I do this? Seems like a bug in the FindOpenAL module (we use the standard CMake one) - might need to report it upstream. We can fork the script locally, and add support, but I wonder why other Windows users didn't report this. Maybe they all use Fred's standard dependencies package? > > 2. It fails on linking test_binobj, > Configuration Debug, with link error > LNK2005: LIBCMT.lib conflicts with LIBCMTD.lib... > > But this does not make sense. It is building > the Debug configuration, so why has it linked > also with the NON-Debug version... > > Why did it NOT apply that rule in this > case? Is there something I can change in > the CMakeLists.txt files to make this > happen? The problem is library detection, not generation (so changing the postifx won't help - it only affects the libraries that are produced). Again it may be an issue with the FindZLib module on Windows - I don't run Windows so not really able to say. On Unix, CMake will use both the debug and release versions if it finds them, otherwise it will use the release (no suffix) version for everything. That's fine on Unix, but obviously not on Windows, since the runtimes clash as you described. > > 3. Question of library output directory > > > But at present it is outputting the libraries to > C:/FG/30/simgear/build/simgear/io/debug/sgiod.lib > and > C:/FG/30/simgear/build/simgear/io/release/sgio.lib > > Ideally I would 'like' it to output them all to > C:/FG/30/3rdparty/lib/sgiod.lib and > C:/FG/30/3rdparty/lib/sgio.lib > > That is the whole purpose of using this 'd' > for the Debug, to keep the names separate... > thus do NOT want them placed in > .../build///[d] > > So again, do you know of a way to 'teach' > cmake this little trick ;=)) Can't you just run 'make install'? The build locations are correct, if you want them to end up in their final home, you need to actually perform the install step. Assuming I understand what you're trying to achieve. James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear now sans plib
On 26 Oct 2011, at 13:13, Martin Spott wrote: > Apparently directory path handling has been changed recently in a way > which prevents 'terrafit' from recursively walking the given directory > tree. > This issue is with cmake-integration/CMake, cmake-integration/Autoconf > but master/Autoconf is fine. I'm also observing a similar behaviour at > 'raw2ascii' with cmake-integration/CMake (didn't test Autoconf). This is certainly my fault, as part of the changes to switch to using the simgear path/directory handling, instead of PLIB. Can you describe / give me a minimal test setup? My inability to easily test such changes is the main reason I don't want to merge to master yet :) I've been relying on Chris to test some pieces, but there's a lot of different tools in TerraGear. James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear now sans plib
On 26 Oct 2011, at 13:34, Martin Spott wrote: > I was interrupted when writing the above As an addition I'd > propose to separate the de-PLIB-ifying from the 'cmake-integration' > into a separate branch/topic/whatever because the move to CMake as a > build system appears to be successful. A fair suggestion! I originally combined them because it was easier not to worry about PLIB when creating the CMake files, but I wasn't expecting the slightly-complex changes to de-PLIB the file handling code. Let me see how hard it would be, to un-pick the changes. James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear now sans plib
On 26 Oct 2011, at 18:43, Martin Spott wrote: > I've tested various pairings of > 'simgear' and 'terragear-cs', unfortunately without getting a 'hgtchop' > creating subdirectories and/or files. Anyhow I'd like to hear from > others being more successful with using recent versions of the > 'terragear-cs' tools. Just pushed a fix (to SimGear) - I changed the behaviour of an SGPath method, a few weeks ago, thinking no one would be relying on the 'old' behaviour ... turns out several places in TerraGear rely on exactly the behaviour I thought was crazy :) I've pushed a fix to Simgear, updated the tests, and now I can run hgtchop happily with latest simgear and terragear. James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata: Important note
On 27 Oct 2011, at 01:28, Gary Neely wrote: > The #1 reason I haven't added my projects (MD-81, Grumman Goose, > Edgley Optica, Velocity XL RG) to the repository is that I have no > ability to perform my own commits. Possibly I haven't earned the right > and I can understand that. But I would like to learn and understand > the procedure for how one earns these rights, and maybe others would > too. The procedure is to ask :) Actually, that's not quite accurate, but, the procedure is to ask, *having demonstrated yourself to be a sane and reasonable person who's likely to stick around longer than four weeks*. I'm a bit more liberal in this regard, but essentially anyone who's contributed a moderate quality aircraft, or provided 10+ 'good' patches to existing aircraft, I'd be happy to grant them access. I'm aware that the bar *appears* to be set higher than this, but personally I'm happy to liberalise it a bit - the problem is keeping the sense of etiquette that other contributors assume and rely upon. So a period of indoctrination is good, of submitting merge requests and getting some feedback, but it can become a habit, when it doesn't need too. 'we' (the infamous FlightGear we) should probably write a wiki page of aircraft-contributor-etiquette, so we have grounds to revoke people's access if they break the rules. Though just about the only rules I'm aware of : keep it GPL; don't modify other people's work without asking, or trying to ask; try to avoid copy-and-pasting when you can share files or scripts between aircraft ... and I only stuck the last one in because it's a pet hate of mine :) James PS - Gary, in case it wasn't obvious, send me your Gitorious username details, and I shall sprinkle the magic fairy dust... -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata: Important note
On 27 Oct 2011, at 12:58, Jari Häkkinen wrote: > Sorry for the rant-like appearance of this message. No need to apologise, I'd say it's 100% accurate - including the lack of a single leader, the fact that project does 'okay' without very tight central leadership, mostly, and the attendant responsibility on the people making the decisions :) James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata: Important note
On 27 Oct 2011, at 10:35, Heiko Schulz wrote: >> The procedure is to ask :) > > Aha, really?- in the 5-6 years I'm contributing to FlightGear-Project I did > this twice. I never got an answer. And until now I can only guess what was > the reasons for. Problem is, as you already realised - *I* don't know who you asked, or what their reasons were. And I (me, personally) would like to make it easier for people to contribute. So you know the criteria *I* use, but there is no formal policy or document. > That are your rules. And what rules does the other FGFS-Project-maintainer > has? > And what do you understand under moderate quality? What do others understand > under? Exactly as you say, it's a problem to agree such things. > Submitting merge requests wasn't bad, in fact that gave the chance to get the > work reviewed and checked. But very often no one felt responsible for! And > sometimes it needed more than 4 weeks until a merge requests was handled. And > then it was already not up to date anymore Yes - in your situation I would ask repeatedly - in fact that's exactly what i did, to get commit access a couple of years ago :) >> try to avoid copy-and-pasting when you can share files or scripts >> >between aircraft > > Excuse me, what do you mean with the last one? Aircraft A has one feature > which developer of Aircraft B wants to use in his project as well. He copy > and paste it but makes sure that it works on his aircraft as well- that > wouldn't be allowed? I guess I misunderstand something here. Sorry, of course in the case you describe it's fine to copy. My problem is often 80% (or 99%) of the file is the same, and really the solution is to make three files - a new 'generic' version that lives in Generic/, and then two (tiny, the 1% that's not generic) aircraft-specific files that customise the generic version for each 'installation' in a particular aircraft. Of course, this means changing the original aircraft, and hence, communicating with its author, which is slower, and more work than just copying the file! This is a recurring problem in all software development :) Anyway, this is a side discussion. > And who makes sure and decides that those people really keeps to all those > rules? Always the problem - 'no one' and 'everyone' and 'the people who shout loudest'. But hopefully in the end the result is acceptable, or people will complain. James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
On 26 Oct 2011, at 19:24, Geoff McLane wrote: > Maybe, as you have suggested, this is over kill, > setting BOTH SIMGEAR_DIR in the environment, > AND passing SIMGEAR_INCLUDE_DIR to cmake, > and when I feel comfortable, I will eliminate > one or the other for further testing... > > BUT now I have reached another wall... > fgjs will not link ;=(( I think all these problems are related. I would suggest: - use CMAKE_PREFIX_PATH to get FindSimGear working. - don't set SIMGEAR_DIR, at all - it's simply not required once the prefix is set - don't set the variables which FindSimGear is supposed to set (VERSION_OK, etc), because you're only setting *some* of them, and hence your linker error in fgjs. Referring to your script, I'd make the following changes: - the ':PATH' here looks suspicious to me FGCM_OPTS="$FGCM_OPTS -D LIB_POSTFIX= -D CMAKE_INSTALL_PREFIX:PATH=$INSTALL_DIR_FGFS" I think it only needs -D CMAKE_INSTALL_PREFIX=$INSTALL_DIR_FGFS - omit the 'ADDSGVOK' and 'ADDSGDIRS' pieces, which are defeating the FindSimGear module, and hence breaking your link commands - omit the OSG_DIR / SIMGEAR_DIR setting completely - set prefix path roughly like this: FGCM_OPTS="$FGCM_OPTS -DCMAKE_PREFIX_PATH=$INSTALL_DIR_SIMGEAR;$INSTALL_DIR_OSG" Depending on what level of quote escaping is going on, you might need to quote that argument, but I'm not enough of a shell guru to be sure. You need the embedded semi-colon to be passed to cmake, though, not interpreted by bash. Hope this helps! James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] unusual behaviour, possibly missing cmake options?
On 29 Oct 2011, at 02:37, Scott wrote: > SimGear > $ cmake -DCMAKE_INSTALL_PREFIX=/opt/SimGear/simgear-2.6/ > -DCMAKE_PREFIX_PATH=/usr/ ../simgear/ As far as I know, /usr should be on the prefix path automatically, so I'm surprised you needed that, trailing slashes or otherwise. H > So with everything compiled, linked and installed, when I run fgfs I get; > > $ bin/fgfs --fg-root=/opt/FlightGear/fgdata --log-level=DEBUG > fgfs: xcb_io.c:507: _XReply: Assertion `!dpy->xcb->reply_data' failed. > Aborted > $ > > > This looks like something to do with X11, anyone got any ideas on what could > possibly be missing? Do the OSG demos run okay? We shouldn't be doing anything different from the osg examples, in terms of interaction with X11 and OpenGL. James -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Time option --start-time-gmt broken?
On 29 Oct 2011, at 18:36, Durk Talsma wrote: > I think that it's a fairly recent commit that broke this: I'm using the > --start-date-gmt option quite frequently, and it wasn't until earlier this > week that I noticed an inconsistency (although I hadn't conciously noted any > time shift yet, I did notice that startup patterns for traffic were fairly > inconsistent). On a more general note, I have reason to believe that this is > a more general time issue: I just found out that --timeofday also gives the > wrong result: I just tried running --timeofday=dawn, and that put me at > approx: 2011-10-29T:17:30 for Amsterdam (EHAM). Given that we're currently 2 > hours behind UTC, this is not dawn, but already after sunset. While I recently touched the options.cxx code, I would be 'surprised' if that's broken the options above, given that other single-value options work. (It's just passing a string through, and the functions that process the args are unchanged) What's more likely, is that some of my refactorings in the TimeManager code would have upset it, *except* that I made all those changes pre 2.4, as far as I can recall - and certainly more than three months ago. Durk, it sounds like the window of this occurring is quite 'tight' - less than seven days - so I'm really unsure what it might be. James -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Time option --start-time-gmt broken?
On 30 Oct 2011, at 10:38, ThorstenB wrote: > Durk, for me, it does still work. However, it's all a bit fragile. The > are no error messages and any typo warps you to some random time. Also, > we're using signed 32bit integers for the time offset - so things will > break on 2038:01:19 ;-). > > I have a patch which cleans up the time/date option parser, adds proper > checks and messages, also extends the time type to 64bit. Also makes it > possible to use partial dates/times. "--start-time-gmt=2010" would only > change the year then - but keep the current month/day/time. > > I could push that right away - but I'll delay that for later today, to > not complicate your current hunt ;-). I'm offline until 6pm (ish) UK time (which is now back to GMT!), but if you guys haven't tracked it down by then, I'll pitch in. James -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Time option --start-time-gmt broken?
On 30 Oct 2011, at 11:49, Durk Talsma wrote: > It turns out that I had the option --time-match-local included in my .fgfsrc > file. Commenting out this option from .fgfsrc makes both --timeofday=dawn, > as well as --start-date-gmt work again. Originally, the order of precedence > was that command line options specified in .fgfsrc should be overridden be > values specified on the command line, so in this particualr case, --timeofday > should override --time-match-local. I haven't tested --start-date-gmt yet, > but I assume that a similar problem occurs here. My tests sofar point to > commit b1c7495 (Sunday Oct 16: 19:35), as the commit where overriding the > --time-match-local option stopped working. I had a quick glanch at the > changes but haven't been able to determine how this may happen. I hope that > James has some ideas. Right, and that's definitely still the case - the 'code' order has changed, but the end result should be identical - .fgfsrc over-rides system.fgfsrc, and the command line over-rides either. And I did quite a bit of testing of that before committing the changes - admittedly using --aircraft and --airport, but it 'should' be the same for any other option. Clearly my 'should' is not working out as planned :) Just to be clear, this isn't a case of specifying the same option in multiple places - you're using two different options, but relying on one to cancel out the other? James -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 66, Issue 23
On 30 Oct 2011, at 16:07, BARANGER Emmanuel wrote: > About maps ZKV1000, I sincerely believe that the use of osgearth solve > many problems. Unfortunately, for a long time when I suggest something, > no one is listening. And I'm tired of fighting. I don't know about your other suggestions, but 'using osgEarth' isn't exactly straightforward - unless you can get someone skilled in osgEarth interested. So it's not a case of 'not listening', more of not being able to do anything constructive with your suggestion, unfortunately. James -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Time option --start-time-gmt broken?
On 30 Oct 2011, at 20:13, Durk Talsma wrote: > Yes, that's right. I think (but it's been ages since I last looked at this) > that the functions could each be called multiple times, but that the one > highest in the priority should always give the right result). > > Somehow, it appears htat if this is done in a different order, than the > result is messed up. I'll try to have a look at the functions doing the > actual calculations, and see if I can come up with a suggestion. Just so everyone knows, I'm testing a fix for this, but this is a very delicate area of the code, so I want to wait (and test more) tomorrow, since late night commits might cause even more problems :) James -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Automake removed from Git/next
Hello, A bit later than planned, the automake build system has been removed from Git. There's very likely some edge cases and unusual combinations that the Cmake system doesn't handle still, so please report any problems or omissions you encounter, and we'll do our best to fix them up. If you need to setup a Cmake build environment, Brisa's script has been updated, or there's instructions in Git (README.cmake) and on the wiki. Improvements and feedback on all those documents are also welcome - there's already been some additional improvements today. The documentation already states it, but, PLEASE build outside the source dir, as recommended - it will simplify your life. Regards, James -- RSA® Conference 2012 Save $700 by Nov 18 Register now! http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear now sans plib
On 2 Nov 2011, at 18:33, Martin Spott wrote:
> In normal operation, "raw2ascii" should almost immediately start
> writing lots of files to "${WORKDIR}/SRTM-30-ASCII/e020n90/", but with
> current simgear/terragear-cs I'm just getting an insane number of
> lines:
Thanks Martin, will take a look.
James
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear now sans plib
On 2 Nov 2011, at 18:51, James Turner wrote:
>> In normal operation, "raw2ascii" should almost immediately start
>> writing lots of files to "${WORKDIR}/SRTM-30-ASCII/e020n90/", but with
>> current simgear/terragear-cs I'm just getting an insane number of
>> lines:
>
> Thanks Martin, will take a look.
Fixed now, at least, it generated a ton of .dem files for me.
(Minor tweak to the config.h creation - I suspect there's actually a more
subtle bug in rawdem.c, but that's not a file we've actually changed at all, so
the CMake behaviour matches the automake behaviour now)
James
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear now sans plib
On 2 Nov 2011, at 19:48, Martin Spott wrote: >> Fixed now, at least, it generated a ton of .dem files for me. > > Really ? And you're on simgear/next and terragear-cs/cmake-integration > without local changes ? With some local changes to Simgear/next, but I am 'fairly sure' they don't relate to path/file/string handling. (Some changes in the SGOceanTile handling) James -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear now sans plib
On 3 Nov 2011, at 13:19, Christian Schmitt wrote: >> That's stock Debian 6 alias Squeeze, the current stable, GCC-4.4.5 and >> Glibc-2.11.2, if it matters, > > Ok, I observed the following: compiling the raw2ascii as "Release" leads to > the error (on Debian). When compiling as "Debug" it works here. Ahh, I was trying Debug, will test Release tomorrow. Thanks Christian! ... going to be something really obscure when we track this down, I guess James -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
