Re: [Flightgear-devel] [Flightgear-commitlogs] SimGear branch, next, updated. 8e75c6be5047bdb0deacc385decc4ff4187c4990
On 13 Oct 2013, at 12:04, Flightgear-commitlogs mar...@hypersphere.calit2.net
wrote:
+catch(...)
+{
+ naRuntimeError(c, Unknown exception in method call.);
+}
+
I am slightly concerned about catching all exceptions this way - I agree
catching std::exception is worthwhile, with the specialisation for sg_exception
since we can provide better logging and reporting, but I really hope no-one is
throwing arbitrary objects not inheriting from std::exception. We used to have
some bad cases of people throwing std::string but I cleaned those up years ago.
I guess it's not that this does any harm (except for more exception handling
overhead, which is probably very low), I just dislike the idea such a thing is
ever needed for us - it's not like we are calling into arbitrary plugin code
which might throw anything.
Kind regards,
James
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue list
On 13 Oct 2013, at 12:02, Renk Thorsten thorsten.i.r...@jyu.fi wrote: 1) rain layers still do not drift with the wind and will be eventually displaced from their cap clouds. I've discussed this previously with James who suggested that a generic way of spawning AI objects (which can get a velocity) from Nasal rather than the current way of spawning non-AI models from Nasal which can not drift would perhaps be a solution. I don't know what the status of this is. I keep forgetting this one, but it would be a good improvement generally. Can you re-specify what you need in terms of API and I promise I'll look at it before 3.0? Kind regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear ,mathlib.c line 1 65
On 9 Oct 2013, at 10:23, Vivian Meazza vivian.mea...@lineone.net wrote: It’s now getting on for a week since the build on Simgear was broken for Win 64/MSVC by this mistake. Any chance of a fix sometime soon? Yes, was just about to push one - however you can always push such a fix yourself! Regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear ,mathlib.c line 1 65
On 9 Oct 2013, at 12:05, Alan Teeder ajtee...@v-twin.org.uk wrote: Sorry, but the patch failed. It also needs the change suggested by Gijs, with “double x,y;” e.g. Ah, I really hate C89 :) Fix coming up. James-- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Built-in Svn client code crashing
On 4 Oct 2013, at 19:29, Markus Wanner mar...@bluegap.ch wrote: That smells like trouble from a packaging standpoint. It's usually not acceptable, because most of the time, the integrated library isn't getting the amount of support the original does. For Debian, I'll certainly have to consider reverting that change. Well, that might be quick tricky - the replacement code is a tiny subset of what the libsubversion code does, and behaves differently - which enables various features and different APIs which I'm planning to use going forwards. Just to be clear, I've replaced libsubversion, which is a full, read+write svn client library with support for history, logging, setting SVN properties and so on, with what is essentially a download engine which happens to speak the SVN protocol. (Which is the part of SVN we actually use). I haven't taken a copy of the libsubversion and forked/edited/trimmed it - it's completely unrelated code. Does that still cause problems under to policies described above? Regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Built-in Svn client code crashing
On 3 Oct 2013, at 12:38, Saikrishna Arcot saiarcot...@gmail.com wrote: Just to check, is the built-in SVN code effectively replacing the external SVN code (from libsvn-dev), or does it add something? Replaces it - one of the big motivations is that the libsvn dependency is becoming increasingly complex to support. (Since libsvn depends on APR, amongst other things) In Git now, all references to libsvn are gone - we always use the built-in code, and based on some limited feedback the crashes are gone. More testing is of course welcome. Regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS - merge request
On 3 Oct 2013, at 17:35, Dirk Dittmann dirk.dittmann@gmail.com wrote: The improved-issue1164 is ready. https://gitorious.org/fg/dirks-flightgear/source/778cc8c6a0abb88a1238850376ea2374358fd887: Thanks, looks good and pushed. Unfortunately I now need to fix the route-path code to subdivide long legs along the great-circle course, since currently the map shows a visible difference at the midpoint of legs. But, that's a bug I'm glad to have :) Kind regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear ,mathlib.c line 1 65
On 3 Oct 2013, at 22:20, Alan Teeder ajtee...@v-twin.org.uk wrote: Sorry, but MSVC does not have a round function. ;( Yes, C99 is a cutting-edge spec :) I'll add a replacement for MSVC, thanks for spotting my mistake. Kind regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS - merge request
On 30 Sep 2013, at 08:47, Dirk Dittmann dirk.dittmann@gmail.com wrote: branche fix-issue1164 @ my clone https://gitorious.org/fg/dirks-flightgear/source/85592ec45db2866a15197c051d97cb4014537b4b: Hi Dirk, this is looking pretty good, just some small nitpicks: - please make a helper function for the great-circle XTK error function, with some sane name like 'greatCircleCrossTrackError'. And please include a full URL to the aviation formulary link, for future readers of the code. (You already did this in one place I think) - where you only want course OR distance, SGGeodesy has some convenience wrappers (I realise in most places in this patch you do want both). This is just to improve readability right now (avoids useless 'az2' declarations), but in the future we might be able to do less work if only one value is needed. - Please squash commits, rebase -i is your friend - so all the evolution of the LegController should probably be squashed together. Similary the adding and removing of _mode_node will disappear with some squashing. - Avoid UTF-8 degree symbols in comments, it might upset some compilers. We recently had an issue with the older GCC on Jenkins rejecting UTF-8 BOM marker. - I would prefer arithmetic terms in conditions to *always* be parenthesised, we've had some bad bugs due to this, so: if (a (b + c)) NOT if (a b + c) - Where boolean conditional get complex, I often like to create explicit bools, so instead of: if ((some complex test) (some other complex test) ((another thing) || (still more))) I think it's more readable to do: bool answerOfTest1 = some complex text bool answerOfTest2 = some other complexTest … if (answerOfTest1 answerOftest2 …) The compiler will get rid of the bool vars, although you might force evaluation of more terms depending on how smart you the optimiser is, but you force yourself to give each boolean expression a name, like 'isWithinOverflightDistance' or 'isWithinInterceptAngle'. As a result it becomes much easier for someone else to evaluate the conditional logic and decide if they agree with it or not. If the boolean test is used more than once, make it into a helper method - grep-ing for methods names is*() and has*() in the codebase points to many of these. In general it looks pretty good though, let me know if you're happy to make the above changes or need any help (especially if you're new to git rebase -i, it can do terrible things) Kind regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS - merge request
On 1 Oct 2013, at 22:34, Dirk Dittmann dirk.dittmann@gmail.com wrote: I understand and will make the improvements. Thx for the hind ! I squash the commit and improve readability. Is there any code convention documentation ? Which I could read? No, there's rules, since the codebase contains quite a mixture. We could start a wiki page, only things I really care about: m_ or _ prefix for members (_prefix is widely used but technically illegal by ISO C++, m_ is my slight preference now) fully brace conditions, even single line. This one is a pain but we've had several bugs with nested ifs-without-braces being modified and introducing logic errors. In several cases people forgot C++ is not Python: if (you do this) if (you keep do thing) if (you then do this) printf(terrible things can happen); else printf(This is not python!); :) I personally prefer lowerCamelCaseWithoutUnderscores for method and variable names, but you will find plenty of other places in the code which use all_lower_case - usually try to follow the style of the code you're working in/near. Regarding naming, longer names and fewer comments are better. Don't do: double m_vXr; /// the velocity tachyon flux better do: double m_velocityTachyonFlux; Of course only people with auto-completing editors agree with this! Shorter names are fine for locals or arguments but still aim to be descriptive. Kind regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS - merge request
On 30 Sep 2013, at 08:47, Dirk Dittmann dirk.dittmann@gmail.com wrote: Improved the Cross track error according to the great circle. http://williams.best.vwh.net/avform.htm#XTE. Great,. And make the overflight sequence configurable for the aircraft. The default is the same. /instrumentation/gps/config/over-flight-arm-angle-deg 90 /instrumentation/gps/config/over-flight-arm-distance-nm 1 /instrumentation/gps/config/over-flight-distance-nm 0 over-flight-distance-nm : - distance to waypoint - overflight - next waypoint over-flight-arm-distance-nm: - distance to waypoint over-flight-distance-nm + over-flight-arm-distance-nm - overflight arms the cone over-flight-arm-angle-deg : - the cone left/right from LEG pointing on the waypoint - when armed and the aircraft leafs the cone - next waypoint. Great, although I do wonder if anyone will ever really adjust the cone angle. Doesn't do any harm though. branche fix-issue1164 @ my clone https://gitorious.org/fg/dirks-flightgear/source/85592ec45db2866a15197c051d97cb4014537b4b: Who should I ask for merge ? Me, only query is that the above don't really seem to relate to issue 1164, which is about initial behaviour of the GPS when entering leg mode away from the active leg. Are you happy for me to pull from that branch to review, or would you rather send a patch, or make a merge request on Gitorious. All of those are fine with me, your choice. Regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS - merge request
On 30 Sep 2013, at 12:29, Eric van den Berg evan_den_b...@hotmail.com wrote: It actually does solve issue 1164 (which I started). When one switches to the next waypoint, the active leg course and x-track-error relate to the leg between the previous and active waypoint of the flightplan (as it should in LEG mode). Previously the leg (-course and x-track-error) was formed between the active waypoint and the position of the aircraft at the moment of switching. Okay, the issue then is the behaviour with GPSs which build an 'entry leg' when activating but off-route, which was the intended behaviour of the current code. I'm fine with supporting both, the question is if we really need a distinct intercept mode for leg, and indeed radial, capture in the GPS, and a config option to control how that works. The other stuff I asked Dirk to add as it makes our extra500 (GPSS) AP design a lot easier. Yes, no problem. BTW Dirk I would prefer separate commits for these areas of course. Kind regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS - merge request
On 30 Sep 2013, at 12:29, Eric van den Berg evan_den_b...@hotmail.com wrote: The other stuff I asked Dirk to add as it makes our extra500 (GPSS) AP design a lot easier. Incidentally if you (Dirk) are looking at this code, the really great thing would be to get the turn-anticipation code enabled. All the pieces are there (compute a standard rate turn based on inbound / outbound leg courses, compute time before WPT to start turning based on ground-speed), but it's always been disabled because I couldn't figure out a stable formula for CDI deviation / XTK in the turn, and especially when transitioning between turn-anticipation and normal leg modes. (So there was an ugly wobble when turn anticipation starts and ends, with the AP did not like). Any comments, or contributions to this, would be great, since a few people have ended up implementing kludges at turn-anticipation in Nasal, when this code should really do it all from C++ nicely. Kind regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mipmapping of liveries
On 26 Sep 2013, at 07:18, Renk Thorsten thorsten.i.r...@jyu.fi wrote: Mipmaps for textures are pretty generic for the rendering process. If you would not mipmap textures, they'd create flickering Moire patterns whenever the texture resolution is higher than the screen resolution as (leaving antialiasing aside) the pixel color is determined from a single texture lookup, and the point for that lookup is ill defined when many texture pixels are mapped to a single screen pixel, i.e. the pixel color would flicker frame by frame (that is a problem for procedural texturing). Whenever a texture is loaded into the GPU memory, it is mipmapped if it isn't already. One advantage of dds is that it can contain pre-generated mipmaps - in this case the mipmaps can just be loaded with the base texture, otherwise the mipmap generation is part of the texture loading process. If uncompressed dds is used, the final result is the same - a mipmap tower resides in GPU memory, but the time to load the texture is shorter for dds at the expense of having a larger file. So non-dds textures may generate a short to long (dependent on system) frame delay, whereas dds works a bit smoother. dds can also be compressed, in which case it saves GPU memory, but since that requires proprietary graphics drivers to work, it is not considered an option for FG. The main difference between hires and lowers textures is not lookup speed (that's taken care of by mipmapping) but memory - if the GPU memory is full, system memory needs to be used (which is slower), if that overruns, virtual memory must be used (which is even slower) - I have managed at some point to fill the whole 11 GB of my combined GPU and system memory, and the performance degradation was quite substantial. Quite recently there was a discussion about 2048x2048 textures for scenery, and I'm sure they are mipmapped, otherwise it won't fly. A typical plane fits all of its exterior into at most a dozen hi-res textures, so the added cost of mipmapping those is negligible I think. Scenery textures are typically mapped to 2000x2000 m areas, so you get about 4x4 m per pixel with a standard 512x512 terrain texture, assuming a 60 deg FOV, you get a good graphical impression only for view distances of 2500 m and more. That's okay for airliner cruise altitude, but really lousy for low leve flight. Going to 2028x2048 improves the optimum view distance down to ~800 m, which starts to make it okay for private aviation in single-engine planes, but still lousy for low level flight. So for scenery, there's not only a need for high resolution, but it's also something that you tend to see quite often (almost all the time) at less than optimal resolution. And the whole scenery doesn't need more than two dozens of such textures at any given time - according to your calculation, that's just the performance footprint of two MP planes. In contrast, planes typically map to areas of 10x10m, so using a 2048x2048 texture gives you a 5 mm resolution. Assuming a FOV of 60 deg, you need to be closer to 4 m to the MP plane to actually get to see the hires texture. I think it's fair to say that you'll almost never reach that distance, so you're spending lots of memory on things which you'll never get to see in flight. Assuming you see MP planes from at best 40 m distance, a 256x256 sheet is quite enough. For the same reason, it makes a lot of sense *not* to render the plane interior of MP planes. So, not only would hires MP liveries be insanely expensive as compared to scenery if you just have a few planes in the scene, they would also be utterly useless because you can never get close enough. Hope that answers the question conclusively. Just to say, Thorsten has in this case saved me writing an email, thanks. To re-iterate - GPU VRAM is a precious commodity, so we should spend it on texels you can actually see. While rivets on other aircraft (or static ground vehicles) look cool for demo screenshots, they come at a huge cost in terms of texels being stored. The mapped texel size calculation that Thorsten is making above is one every modeller should be doing, to estimate what detail is actually needed. Eg for a building, even an airport terminal, you're rarely closer than 50m, often more than 250m for a building outside the airport boundary (there are exceptions of course, mostly involving helicopters). Save the texels/VRAM for your cockpit interior models, they're much closer to the camera and occupy a much larger portion of your field of view :) Regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See
Re: [Flightgear-devel] Mipmapping of liveries
On 26 Sep 2013, at 11:22, Stuart Buchanan stuar...@gmail.com wrote: One further point to make is that we do have the AI/Aircraft directory specifically used for low-poly/resolution models. So, if there are specific aircraft that are causing problems, arguably the correct way to resolve them is to create an AI version. This would be quite a good task for someone wanting to get to grips with modeling, as it's easier to remove things than add them. Perhaps we should mandate that aircraft over a certain size should have an AI version created? +1 on all counts. Some of the folks on the fourm have been doing greta work up the AI models of our transport-category aircraft, mostly to improve appearance of Traffic. The A320 and A330 have had overhauls and now look great, and I believe the Boeings are next on the list, which is good because the current AI 744 and 777 look pretty bad. But revised A320 is exactly the kind of model we want for MP - a realistic silhouette and nice liveries when parked without going crazy in any one area. Regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Moving menus (aka, usability)
I was reviewing the current menu structure and would like to propose a couple of changes. Partly because we have too many menus, all quite short, but also to remove some bad terminology. Each of these changes is independent, comments explicitly requested: - merge 'Autopilot' into the Equipment menu, as a section (probably the first section) Autopilot is just another piece of equipment, and route-manager and GPS are really parallel features, since route-manger is basically the FMC. The combined menu is still a reasonable length. Aircraft without the default autopilot (including the C172) would need to disable just those menu items, but that's ok - potentially rename 'Environment' to 'World' This is less of an issue, but makes sense with the next one: - Move the AI items elsewhere -- Traffic / Scenarios move to 'World' menu -- ATC services mode to World or Equipment (opinions requested) -- All the 'controls' for tanker/carrier/wingman also move to world (or somewhere even smarter … unfortunately PUI doesn't support sub-menus) The rationale here is that 'AI' is a completely meaningless term for most users, and the way we use it in FlightGear has long since ceased to be accurate. 'AI objects' are really what is normally called a 'mobile' or 'actor' in most game engines. So the menu needs to either be removed or renamed, and I don't think there's a sane meaningful new name, compared to relocating the items. If most of the AI stuff moves to 'World', I think that name makes sense - it's about things outside your aircraft, which does include tankers, carriers and scenarios, as well as the weather and time/season. A separate step, much harder to make happen, would be to explicitly reserve the Ctrl (Command on Mac) keybinding space for menu/non-aircraft keyboard shortcuts. I would really like to do this so we can have user-friendly key-bindings for dialogs and standard items, such as Ctrl-Q to quit, Ctrl-A for autopilot dialog, Ctrl-P for pause, Ctrl-R for reply, etc. [And the entire normal key / key + shift / key+alt ranges available FOR aircraft functions, of course) The problem is right now we have aircraft using Ctrl- shortcuts for many things (usually because they're the only choice), and I can't decide a sane way to migrate to this split without lots of breakage and frustration. Any ideas welcome. Regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Static B737 at SFO (Was: Mipmapping of liveries)
On 26 Sep 2013, at 11:33, Erik Hofman e...@ehofman.com wrote: On that topic, there's a static 737 on the taxi tracks that's there since the old days when there was no AI traffic, it is probably a good idea to remove it from the scenery now. Mostly i agree, but it's sort of a piece of FG history now, like Durk's roof-parked Fokkers. Which was such a good idea that EHAM copied it in real life. No sign of KSFO placing a 737-200 at that location in homage to FG yet, clearly we have more fans in .NL :D James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving menus (aka, usability)
On 26 Sep 2013, at 16:21, AJ MacLeod aj-li...@adeptopensource.co.uk wrote: That's exactly what the word environment means though, isn't it! I really don't think there's any point at all in changing the name of that menu entry; the current one perfectly accurately describes things around you and avoids having to change documentation etc. Okay, to me 'World' sounds a bit less technical, and it's also a shorter word. But either work, I agree. Regarding the control key mapping restrictions, I'm definitely not too keen on that for this reason; the control key is usually one of the easiest modifiers to find on a keyboard, and if anything I personally think more flight-related functions should be accessed using the control key as you often want to access those rapidly, perhaps even by feel without hunting around the keyboard. Program related functions on the other hand are rarely needed in a hurry and could be mapped to any modifier without making much difference to functionality. Just my opinions, possibly strange ones :-) Hmm, the problem is the OSs have already decreed that Ctrl (Command on Mac) is the standard shortcut key, so lots of Ctrl-something have standard meanings which FlightGear deviates from. Though we escape the worst of it since we don't support file or edit operations. Keep in mind if the GUI things such as dialogs were moved to Ctrl-blah, that frees up lots of normal keys for use, which are currently taken up by simulator things. While I agree Ctrl is probably the easiest modifier to access (except maybe shift, since there's two, so it's more friendly for left-handed people), I think by this logic a shortcut with *no* modifiers is even easier to access, and that's an argument in *favour* of such change :) I still don't have a good technical way to migrate this, so it's not a big deal anyway. James-- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] spelling fix: compatability
On 22 Sep 2013, at 22:06, Markus Wanner mar...@bluegap.ch wrote: standard checking procedures on Debian revealed a spelling error: compatability occurs a couple of times in the sources. I'm a bit worried about the kt70-compatibility boolean flag, but corrected its spelling for the Debian release. Attached is a patch fixing all occurrences. Thanks, this is 100% my fault, I can't spell compatability. Compata… Err.. You get the idea :) (I've just realised I spell it wrong because I mentally think of it as 'compat - ability' - but that's not how the word is constructed. Anyway) And the kt70- flag is new, so we're pretty safe there. Thanks, James -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] spelling fix: compatability
On 23 Sep 2013, at 10:18, Markus Wanner mar...@bluegap.ch wrote: Of course, I did a quick grep in the 2.12 fgdata, but didn't find anything relevant. (Navaids/ReadMe.FG226.txt was the only hit.) The affected aircraft isn't in the base package, but /is/ in fgdata Git. So wearing the 'Debian maintainer' hat you did the right thing, but from the terms of flightgear patches, we check /all/ aircraft, not just those included in the base package. Regards, James -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] spelling fix: compatability
On 23 Sep 2013, at 10:46, Markus Wanner mar...@bluegap.ch wrote: On 09/23/2013 11:27 AM, James Turner wrote: The affected aircraft isn't in the base package, but /is/ in fgdata Git. So wearing the 'Debian maintainer' hat you did the right thing, but from the terms of flightgear patches, we check /all/ aircraft, not just those included in the base package. Oh, I see, thanks for explaining. Actually, I spoke too soon - the ZLT-NT /is/ in the base package. I just check the official FLightGear-2.12.0 tar.bz and the ZLT-NT is there (good) and the reference to kt70-compatability is also there. So I'd suggest to check your files or workflow at your end, something strange is occurring. Regards, James -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS 2.12 UBUNTU
On 23 Sep 2013, at 12:31, Saikrishna Arcot saiarcot...@gmail.com wrote: I've updated my PPA to FlightGear 2.12. See my forum post for instructions on how to install 2.12. I guess .deb has no support for a 'replaces' list like RPM, so you can't name the old packages and hence make upgrade work? James-- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat.gz and TerraSync
On 23 Sep 2013, at 13:58, Tomash Brechko tomash.brec...@gmail.com wrote: I use fgdata from git repo and so have a fresh copy of apt.dat.gz. I noted that apt data is actually ahead of what is fetched with TerraSync: some airports (at least UHPB, UIAE, UIUB, UIIB, but likely much more) present in apt.dat.gz (and thus shown in Atlas) but not in the scenery (fgfs --airports=UHPB starts in the woods, etc.). I also suspect that as of now TerraSync repo hasn't been updated yet. I wonder if there's a dev version of TerraSync SVN that is updated more frequently than once per release, and is in sync with dev fgdata? TerraSync is supposed to in-sync with fgdata I think, but hopefully Martin will respond with more details. On a side note, recently I put together Perl script ( https://github.com/kroki/fg-navaid , still work in progress) to query internal navdata cache (SQLite database) for various info. Front page has examples of currently available information outputs. Mention it as an easier way than digging through .dat.gz. I would greatly prefer you NOT do this, because the internal format of the cache (eg, the fact it's a SQL DB) is deliberately opaque. There are no guarantees made about the format of the file, the SQL scheme or anything. There is a version field of course, and I'm not planning or expecting any changes, but I really don't want to be tied to the current scheme if we discover problems or want to add something else in the future. Kind regards, James -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Fwd: apt.dat.gz and TerraSync
Begin forwarded message: Could it be some special format comments in the C++ code and an extraction script to update http://wiki.flightgear.org/List_of_Nasal_extension_functions ? Wouldn't recommend Doxygen though, I think something grep-able would be enough. Would be fine with me, yes - and ideally also to a textual page we could include with binary. I don't care if it's Doxygen / Javadoc or anything so long as the documentation can be written close to the function/method definition. Text processing in that way is definitely not my area of expertise or happiness, so if you want to hack something up be my guest. Only problem is we are moving towards using Thomas' cppbind based template classes to expose new (and eventually, all) functionality to Nasal. This means much less code needs to be written, but I suspect complicates machine-drive documentation of the methods available on classes. Of course we don't need a perfect solution - having someone simply shout at me every time I add new methods / functions and fail to update the Wiki would probably work quite well too :) Thanks for magvar() pointer, will look throught the code to see what other goodies might be hiding :). Quite a few goodies, although many are access by crazy argument overloads, which makes for very, uh, delicate calling syntax on the Nasal side. Incidentally the Nasal console in 2.12 is deliberately improved to make interactive experimentation a little easier - the Nasal console output is collected for you instead of buried in all the other log messages. Kind regards, James -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat.gz and TerraSync
On 23 Sep 2013, at 15:19, Tomash Brechko tomash.brec...@gmail.com wrote: Sure I'm aware of this, and please feel free to change the internals at any moment without notice (as a last resort I can add an option to the script to create its own DB based on navdata - just don't see the reason for this at the moment). Moreover I view the script as a temporal stub until the information is available somewhere inside FG, my current knowledge of FG internals is insufficient to implement it there myself, and having it dirty way is better than nothing. Well, if you need the information *inside* FlightGear, you can ask for an accessor to be added …. But, yes, if you're happy with the risk of it all changing, indeed it's easy to extract information. Related to this, it would be nice if the function to query magvar for arbitrary location would have a Nasal binding (or magvar field in the output of geodinfo() or airportinfo(), but this is less efficient if one needs only magvar (and less flexible in the case of airportinfo(), though in most cases you need to know declination exactly there)). This will allow reporting magnetic runway headings in the Airport dialog which I presume is implemented in Nasal. I think you should investigate the magvar() function: var x = magvar(); # at present aircraft pos var y = magvar(lon, lat); # guess what this does …. var z = magvar( some object retrieved from airportinfo() / navinfo() / one of the other DB query functions ) As ever, the problem here is we have no way to auto-document what's exposed to Nasal. In general reading NasalSys.cxx / NasalPositioned.cxx is a good hint, though. At this point I've exposed every piece of data that anyone has requested, I think - there's no backlog of non-exposed data (but, if I have, adding accessors is easy and low-risk) Kind regards, James -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] spelling fix: compatability
On 23 Sep 2013, at 16:49, Markus Wanner mar...@bluegap.ch wrote: Any other aircraft that users might download which would fail if I patch this one as well? Given that 2.12.0 was released with compatability, are you going to change this for a potential 2.12.1 or for 3.0? I'd prefer to leave as-is for 2.12, and fix for 3.0 - there should only be a small number of aircraft affected I hope. Regards, James-- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Updated 707
On 20 Sep 2013, at 22:16, Stuart Buchanan stuar...@gmail.com wrote: Possible candidate for default aircraft for V3.0? Just had a quick flight around the Bay Area with this, it's a fantastic piece of work, I'm amazed by how beautiful, but also legible, the cockpit it is, a real pleasure to work in. Kind regards, James -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Upcoming Random Buildings changes
On 20 Sep 2013, at 11:04, Stuart Buchanan stuar...@gmail.com wrote: The original random buildings implementation (2.8.0) use basic OSG primitives, and so had collision detection and Rembrandt shadows for free. In 2.10.0 this was changed to a shader-based instance approach based on the tree scheme to reduce the memory footprint which was ridiculously high in places like LA or Tehran. With the shader-based approach, collision detection isn't possible as the building doesn't really exist in the scenegraph. Rembrandt should be possible at the cost of running another shader IIRC. I think I had Rembrandt working for trees, but the cost was absolutely huge. Now, the basic OSG primitive approach has some advantages: - doesn't rely on shader support - allows for more variety in the buildings as one isn't instantiating a small set of buildings multiple times. - the code is simpler - more flexibility in adding complicated buildings such as signage, extensions. If I implement a PagedLOD approach, it might reduce the memory footprint sufficiently that we could switch back to the OSG primitives. That would be my hope too, BTW. Ideally we'd set a total memory use (or vertex count, which is a proxy metric for the same) for trees+buildings and setup the PagedLOD to keep things loading (really, generating) and unloading based on that target. Then it becomes a fairly clear memory-burn vs popping tradeoff which I think most people would accept as reasonable. You don't like the pops, you buy more [V]RAM :) Instancing would help the memory burn, but OSG makes it very complex, we need to bypass large chunks of the PrimitiveSet and Arrays APIs until they get a real API internally, possibly not until OSG 3.4 (This is on the assumption that even though the buildings are random, across a tile you could have quite a few which differ only in transform and some other shader uniforms, but have the same width/breadth/height/roof-pitch/number-of-floors, and hence could be drawn using the same instance data) Regards, James -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Built-in Svn client code crashing
Hello, A few people have reported crashes when using the built-in SVN client code, especially on Linux (and potentially Windows too, which would be a problem, as we shall see). Thomas identified something strange relating to whether we were using built-in or the system Expat XML parser, and I finally realised the dumb thing I'd done, and have cleaned up the problem. Hence the refactoring that occurred in SimGear last night, so that we cannot (anymore) end up in a situation where we get the Expat headers and symbols from mismatching locations. The guess/hope is that this was previously causing subtle memory corruption due to internal differences in Expat. However, it can only have been an issue on Linux, not Windows - since Windows will never have a system-supplied version. So, as I've previously asked before, I really need people running from 'next' to try with -DSG_SVN_CLIENT=1 when configuring SimGear, move their existing TerraSync dir out the way, and test, test, test. I'm sure the new code isn't 100% trouble free (in particular I think there is still the occasional time when it gets stuck not doing any more downloads until FG is restarted), but I really don't want to move forwards with the code until I have a bit more assurance it's not going to make everyone's setup crash 80% of the time, which is what some people have reported. Note this applies even if you 'don't use' terrasync since the SVN sync engine is going to be used for other pieces of data as soon as it's stable. (I will be adding a new preference to globally control whether FG works in online/offline mode, of course) Kind regards, James -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] --jpg-httpd command line option
On 17 Sep 2013, at 19:47, Rick Armstrong rick.armstr...@urbanrobotics.net
wrote:
Indeed, PNG would be ideal!
- if you have any interested in
doing this, I can point you at examples since the screenshot code was
converted to do the same thing recently -it's probably a couple of hours
hacking at most)
I'd be happy to take a crack at it. This would be my first foray into the
FlightGear source tree, so a pointer to some sample code would be great.
Okay, various pieces:
gui_funcs.cxx has the screenshot dumping code, especially the logic to
run things safely via an OSG GraphicsContextOperation. Its run() virtual
contains a call to: sg_glDumpWindow
which is defined in SimGear and does the actual reading of the frame-buffer and
writing via:
// dump the screen buffer to a png file, returns true on success
bool sg_glDumpWindow(const char *filename, int win_width, int
win_height)
{
osg::ref_ptrosg::Image img(new osg::Image);
img-readPixels(0,0, win_width, win_height, GL_RGB,
GL_UNSIGNED_BYTE);
return osgDB::writeImageFile(*img, filename);
}
The trick will be to interface this with the jpg-httpd infrastructure. There's
a problem I can see here - the osgDB API is very file orientated, but I assume
you need the image data in memory to send down the HTTP socket. We might need
to ask on the OSG mailing list if this can be done, otherwise you'd have to
read the file back after writing it. This is little ugly but the file should be
in the cache so probably no actual disk access happens.
Most of jpgfactory.cxx is irrelevant, I'd ignore it completely since it only
deals with the tile-rendering (not needed these days since we can render big GL
viewports natively) and the mechanics of running the image compressor. If you
can plug the stuff you need into line 227 of jpg-httpd, I think you're good.
That's a very rough sketch based on ten minutes reading of course.
Note if you want actual good performance from this system, there's much smarter
things that could be done, such as grabbing the frame buffer each normal
rendering frame, instead of re-rendering the scene each time an HTTP get is
received. That would need much more drastic changes to the system however.
As ever, any further questions, just ask.
Regards,
James
--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Upcoming Random Buildings changes
On 18 Sep 2013, at 17:05, Stuart Buchanan stuar...@gmail.com wrote: I did take a look at the PagedLOD approach - Matthias' code made a great template to work from. Yes, that is exactly the model I would follow, and I am sure Mathias can be asked for additional hints on the best way to integrate it. His SPT system replaces the tile-scheduling logic with the osgDB Pager, which improve various things, since osgDB would be fully in control of deciding what is loaded, and unloaded when, based on the camera(s) - no more arbitrary dealing with rings of tiles based on visibility parameters. One thing I wasn't clear on is whether this would move generation of the trees/objects/buildings from a scenery loading thread into some other thread. I'm not sufficiently familiar with our threading to know if there would be any impact. The ReaderWriters run in the osgDB pager thread, which is exactly where the current ReaderWriterSTG runs (which ultimately does the current tree/object/building placement, I think) - so the threading should not change at all. Indeed, the more I think on it, the more it feels like this should be a very small restructuring of the code, just requiring some slightly delicate PagedLOD plumbing to make it work. We're already doing the right work (building an osg::Node) and doing it in the right thread, we just need to change *when* we do it. BTW, I would also hope this means the fixed osg::LOD elements in the quadtrees could go away, or at least the layering reduced (to one layer of LODs instead of two) My gut feeling is the LOD-tree is preventing sufficiently large batching for both trees and random buildings. But of course the optimal batch size is very hardware dependant. Regards, James -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] --jpg-httpd command line option
On 17 Sep 2013, at 10:41, Rick Armstrong waitingfortheelectric...@gmail.com wrote: -DJPEG_FACTORY:BOOL=ON in CMake. My question: before I go down that road, does anyone know if the JPG HTTPD functionality works? If yes, does it work well? The fact that it's turned-off by default makes me think that it might not be ready for prime-time. Any advice is greatly appreciated. It's turned off for build reasons, not because it's new or untested. I believe many people have used it exactly the way you describe. If you encounter problems, they should be easy to fix and patches are welcome! (The build reasons could actually be solved by using OSGDB to write out the files instead of using libjpeg directly - this would mean the feature could be enabled all the time, i.e removed from CMake, and also we could write out PNGs instead of JPEGs if desired - if you have any interested in doing this, I can point you at examples since the screenshot code was converted to do the same thing recently -it's probably a couple of hours hacking at most) Kind regards, James -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Textures separation, cleanup
Hello, For the next release (3.0, I think), I want to reduce the size of the installers by making parts of the base package optional. Some are easy, like AI Traffic and ATC chatter - the first time you enable that feature, we'll download (well, terra-sync, really) the relevant files. If you don't use the feature, you don't download the files ever. One large piece (480MB of the base package / fgdata at current counting) is the Textures and Textures.high directories. Originally I believe Textures.high was a partial subset of Textures, at higher resolutions, but that's no longer the case (nor has it been for a long time, I think) What I'd like is: - a baseline texture set that is of adequate, but not high quality (e.g. max 1024x1024 size for landcover, or something else agreed to be good enough) to be included by default in the installers (this would also be friendly to people on older hardware with limited VRAM) - high res (and even, ultra-high res) sets, plus a DDS set for those who want it, which can be downloaded + updated later via terra-sync. (of course we can have discussions about if the default set should be really low quality or quite high - but the point is to have levels we can switch between centrally ) However, my impression is the current switching is done at the effects / material level (especially between DDS and PNG). I.e C++/Nasal code is not involved in any such switching. (Which will need to be changed, assuming it can be) I'm not clear where the texture file names are being referenced from, and how the paths are being searched. E.g, do the shared Models reference these textures, or do they include their own (my impression is the latter, but maybe it's a mix?). If it's not the models, is it 'just' effects/shaders and scenery materials? Do aircraft reference them? And if so, is it via an arbitrary mixture of Textures, Texture.high and DDS paths? I am assuming we would fallback to the Textures/ dir, so I hope the only fixing of aircraft / scene models required would be replacing any references to Textures.high or DDS files. Any hints on how the mechanism is currently working, and how it could work in the future would be interesting. This is a 'look at in the next few months' task, not something I'm planning to tackle next week, so there is no rush. Indeed, if it turns out to be more complex than I realise, it might even be too big to tackle for 3.0, but the first step is to understand how it does work, and how it could work :) Regards, James -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Updated Mac release candidate
On 15 Sep 2013, at 19:37, James Turner zakal...@mac.com wrote: I just realised the Windows release is using our 'stable OSG' builds on Jenkins so I'm experimentally bumping them to 3.2.0 too - I'm not aware of any downsides to using the newer versions, and if we discover any it's trivial to rollback. Will follow up here assuming it works, once the new EXE is uploaded. After a minor issue, the updated Windows RC is available now, I've just had a quick check and it seems to be working as expected. James -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Updated Mac release candidate
Hi, I've made a couple of changes which only affect the Mac RC: - OSG is now 3.2.0 instead of 3.1.3 - There is no longer an XQuartz dependency (phew!) The latter issue was very annoying, and stems from osgsb_freetype using the X11 libfreetype on the build machine (runs 10.6), but hence hitting the 'special' logic in dyld when referring to that symbol on a 10.8 machine without XQuartz installed. I've now built a custom freetype on Jenkins (it's included in the Mac 3rdparty-dependencies tarball which Jenkins generates) and link this statically into the osgdb_freetype plugin on Mac, so we avoid any strange issues when deploying on 10.8 (or 10.9, soon). (This build is already available from fgfs.goneabitbursar.org) I just realised the Windows release is using our 'stable OSG' builds on Jenkins so I'm experimentally bumping them to 3.2.0 too - I'm not aware of any downsides to using the newer versions, and if we discover any it's trivial to rollback. Will follow up here assuming it works, once the new EXE is uploaded. Regards, James -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] portability of simgear
On 11 Sep 2013, at 10:16, Markus Wanner mar...@bluegap.ch wrote: I think some of the more recent patches didn't flow upstream, yet. I'm focusing on getting it working properly on Debian, first. And getting 2.12 in. Just a matter of time. Sorry for the lag. Okay, but if any of them are portable fixes, it would be better to get them in 2.12 itself. Usual practice is that whatever a single file's copyright line states overrides any kind of project-wide license file or agreement. Thus, I recommend asking the authors if they agree to change the license. However, I'm fine however you do it, as long as we're safe from complaints. Given the history of the files, I believe we are safe. There are a few files which I have included which need to remain with their very explicit license (MD5 calculation, expat), but definitely several which have been moved from FG and not updated. There's also a large collection from David Megginson which he placed in the public domain originally, I will ping him and ask his opinion. so we can run parts of the stack on Pis, Pandaboards and so on. This would be materially useful for various add-on functions, especially the canvas and fgcom. (I spend an increasing amount of my work time on OpenGL on ARM platforms, they have plenty of power to run graphics, depending on which GPU is on the SoC) Oh, I didn't think about these, yes. So, can I run flightgear on my RPi? Under what OS are you working on the Pi? I'm currently busy on other areas but it will be either Raspbian or a custom buildroot Linux deployment. Although, since my current buildroot uses ulibc, that would mean discovering all the places in SG+FG where we've assumed glibc. Note we can't run FG itself without major work, since these platforms only support GLES1 or GLES2, and there's many legacy areas of the renderer which would not work. (BTW I believe OSG compiles out of the box on ARM targets now, Android at least, but I didn't try it myself yet) Regards, James -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] portability of simgear
On 8 Sep 2013, at 17:34, Markus Wanner mar...@bluegap.ch wrote: I'm aware of the upcoming release, eagerly awaiting it, and have already started packing. Given the decision to slip the 2.12 release, I decided to move on with 2.10 rather than wait another month, though. I'll certainly focus on 2.12 as soon as it's released. I don't think it changes a lot WRT portability, though. Do you? Not that I'm aware of. There are a few areas where I could need help or need to feed patches back. You could take a look at the patches currently applied to 2.10. I was under the impression all patches had been up streamed - the correct process here is to file merge requests and email here (since unfortunately Gitorious merge requests don't notify people) Or you can simply email diffs here / to me, but either way the patches can be applied. Another issue I run into was the mixture of GPL vs LGPL in simgear. I personally don't care much, really. As a packager, though, I'd appreciate if at least all the files that are under copyright by the flightgear authors were released under the same license. (IANAL, but given there are GPL files in simgear, my understanding is that the entire library can only be used under the terms of the (more restrictive) GPL, rather than LGPL). This is a bug in our code. We have files with missing licenses, files which were moved between FG and SG, and files which were contributed public domain. However 'the license' for SimGear is LGPL and for FlightGear, GPL version 2 (or later at discretion, but we don't require version 3). Patches to clean up the situation are welcome. Given the license file and docs have always been clear which license each project is under, I think it is safe to consider file-level discrepancies as bugs and standardise. Another thing I'm not sure about is the versioning policy. My understanding is that minor versions are not compatible between each other (i.e. 2.10 vs 2.12). How about the patch version? Is a (hypothetical) simgear 2.10.1 compatible with flightgear 2.10.0? Or vice versa? (FWIW, the former packager (Ove) took the pessimistic approach and I didn't change that.). We very rarely do patch releases, but thanks to Jenkins is at least possible. Patch releases should be compatible I would hope, eg when I made the 2.10.1 patch of FG it still used SG 2.10.0 Minor versions are incompatible. According to Debian's popularity contest, we're closer to 98.4% of the participating systems being i386/amd64 (including the kfreebsd ones). And given that the next best two, i.e. ARM (arm, armel, armhf, together 0.8%) and PowerPC (0.5%) can hardly be considered gaming platforms, we're reasonably close to 100%. However, I like diversity and given the successes on sparc and mipsel give me hope of an easy fix... Personally I wouldn't spend your time, far more useful would be to get ARM working so we can run parts of the stack on Pis, Pandaboards and so on. This would be materially useful for various add-on functions, especially the canvas and fgcom. (I spend an increasing amount of my work time on OpenGL on ARM platforms, they have plenty of power to run graphics, depending on which GPU is on the SoC) Regards, James https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Howto download aircraft ( and others data ) from Git
On 3 Sep 2013, at 14:13, grtuxhangar team hohora...@gmail.com wrote: How could we have FGData split in several part which can be downloaded easily ? Or is there any other way with Git which is similar to the old way with snapshot. ? For 3.0 I will be making FGData significantly smaller, since the size of the Git repo is indeed a big problem. Some pieces will become truly optional, and others will be downloaded in different ways. However this is all for the future, I'm afraid I don't have a short term answer. Regards, James-- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Howto download aircraft ( and others data ) from Git
On 3 Sep 2013, at 16:57, Stefan Seifert n...@detonation.org wrote: I hope with the reorganization we don't lose the simpleness of doing a git pull to get the latest and greatest of all aircraft. Having to look for scattered repos would be a severe drawback. The repos will be disjoint, but there will be automated ways (both GUI and command-line based) to update from all of them. Indeed, the intent (and the code is already in Simgear, but not used because there are no front-ends yet) is to improve the situation of finding aircraft, because different hangars can be searched (including by tags), the system is aware of which aircraft work / do not work with your active FG version, and so on. The other major goal of the system is to make the user-experience of dealing with aircraft installation much better, so that users don't need to mess with Git, extracting tar files, or aircraft search paths, in order to get aircraft not shipped in the base package, or have to figure out if a particular zip is for FG 2.6, 2.8, or whatever. There's some other complementary steps which again are mostly in place but need to be developed, again post 2.12. James-- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Howto download aircraft ( and others data ) from Git
On 3 Sep 2013, at 18:19, Stuart Buchanan stuar...@gmail.com wrote: On Tue, Sep 3, 2013 at 6:07 PM, Alan Teederwrote: Not everyone lives in a big city with fast broadband and the powers that be seem to bury their heads in the sand when the topic is bought up - as it has been and will be – again and again and again. Can I refer you to Jame Turner's posts at 2:28pm and 5:37pm indicating that he is planning to address this for V3.0 at the end of the year? I may have got lost in the other comments. And also, well, all the commits relating to SVN and aircraft packages, and the code for multiple-aircraft dir support, and the HTTP engine, and its support gzip compression, and …. so on :) The topic is not being ignored, it's just very complex to fix, there are multiple conflicting requirements, and so on. Many of the pieces are now in place but others remain so further patience is needed. (And now I shall return to debugging the SVN code so we can reliably use it to download and update portions of FGData dynamically, which will reduce the size of both the installers and the data repo…..) Regards, James -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release candidates
On 29 Aug 2013, at 10:02, James Turner zakal...@mac.com wrote: No, rsync is not available as a direct Jenkins plugin (we could run it manually of course from a command-line step, but that becomes more work to deploy across different slaves). However I've found a different SFTP plugin (does SSH as well as SCP) which can execute remote commands after copying artefacts - which should do the job nicely. Just testing that out now! Right, the alternate plugin does the correct thing - the copy in releases/ should always be a complete build now. I've also moved past versions to 'previous' subdir. These builds seem sane to me, so I think some wider testing is warranted! Regards, James -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release candidates
On 28 Aug 2013, at 21:13, Edheldil fg...@eowyn.cz wrote: Can't you use rsync instead of scp? It can upload to a temporary directory and move the files when they are successfully transfered, and uses temporary files anyway. I believe it also deletes the temporaries if the transfer is interrupted. No, rsync is not available as a direct Jenkins plugin (we could run it manually of course from a command-line step, but that becomes more work to deploy across different slaves). However I've found a different SFTP plugin (does SSH as well as SCP) which can execute remote commands after copying artefacts - which should do the job nicely. Just testing that out now! Regards, James -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Release candidates
Hello, After fixing a dumb mistake of mine, we now have automatically generated installers / files for Linux, Mac and Windows. Get them from here: (updated automatically) http://fgfs.goneabitbursar.com/releases/ (The 2.12 versions, obviously) I've done a quick test and things look good on both Mac and Windows - at least, I can start the C172P and the About box info looks good. The server above can handle plenty of people downloading (unlike Jenkins itself), the only catch is if you grab a download while Jenkins is uploading new versions, you'll get a corrupt file. File bugs in the tracker or report them here. Regards, James -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release candidates
On 28 Aug 2013, at 16:56, Scott Berry sb356...@gmail.com wrote:
Is there a way to make Jenkins where it will notify people when it
uploads or just have a page where it says Jenkins is uploading please
wait a while and try this download again. This way we don't get
corrupted files?
Quick answer is there's a way to make Jenkins do anything, longer answer is I
don't know of an easy way that's trivial (or I would have done it already)
Ideally Jenkins would upload to a non-public ('incoming') dir and trigger some
operation on the server to link / copy the files when the upload succeeds, I
just didn't come up with an easy way to make that happen yet.
I run the server, and it can run arbitrary PHP / Perl / cron scripts, it's just
a question of what is low complexity to set up. The SCP uploader plugin for
Jenkins is quite simple so I can't do much with that - I can run another build
action *after* it, the question is what it should do.
James--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.12 is branched
On 21 Aug 2013, at 15:28, Stuart Buchanan stuar...@gmail.com wrote: On a related note, once the build problem is resolved, could we generate a full installation RC package for testing? It would make it easier for testers not familiar with Git to use it, and would be quite handy for people like myself who do their development on Linux, but have Windows systems available for testing but without the git infrastructure or the time to download the entire git fgdata repository. Once the build is fixed, Jenkins should do exactly that - that's part of the automation work I did for 2.10 - Jenkins will produce the complete install EXE, someone just has to grab it from Jenkins and upload / mirror / seed it as they see fit. Of course, Jenkins only does what it's told by the scripts (mostly in fgmeta besides the CMake files) - so we're still at the mercy of missing files in the installer description and so on - I didn't yet automate a 'smoke test'[1] on Jenkins, since that would mean keeping a clean environment to run test installs, and involve several expensive operations since we'd be launching the sim. That's all doable but requires VMs and more energy than I have. In general I've been hoping to get enough people using the nightly builds that an automated smoke-test would be unnecessary but that's probably optimistic :) James [1] 'where there's smoke there's fire', this is old terminology from the Netscape/Mozilla TinderBox engine. -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.12 is branched
On 21 Aug 2013, at 16:03, Stuart Buchanan stuar...@gmail.com wrote: Now all we need is someone with enough Windows knowledge to fix the build. I've put some cash down to buy a cheap PC box for running Windows+Linux so I can debug these issues (and a few other Windows ones which are bugging me). Probably won't have everything up and running in the 2.12 timeframe, however. [1] 'where there's smoke there's fire', this is old terminology from the Netscape/Mozilla TinderBox engine. I'm pretty sure the smoke test predates Tinderbox. I came across it when working for Xilinx in reference to hardware testing where the first test is to attach a power feed and check that nothing started giving off smoke :) Haha, brilliant. James-- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Updated 707
On 14 Aug 2013, at 21:23, Stuart Buchanan stuar...@gmail.com wrote: Marc Kraus (CC'd as he's not on the -devel list) has produced a (very) significant update to the 707, a model that Innis Cunningham developed a number of years back. It's available from http://gitorious.org/boeing/707 and is well worth a look, particularly for the fine cockpit and engineer station with extensive start-up tutorial. Given that Innis has given the all-clear, what is the next step? I'm happy to simply checkout a particular branch from the repo above and commit the files to fgdata, but there are other options. James-- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear voice communication
On 16 Aug 2013, at 09:25, Adrian Musceac kanto...@gmail.com wrote: If you'd use my new radio propagation code, which is an improvement over what's already in git, range would be as close to reality as possible for all type of radio comms, be they VHF voice, VOLMET, ACARS, ADS-B, VOR/DME, radar, etc. My code takes into account not only terrain obstruction, altitude, distance, but also frequency and standard equipment capabilities. Now, IMHO, for the future it would be desirable to integrate voice comms into Flightgear itself, without the need to use Asterisk or other external tools. Some other simulators have this as default, minus the realistic propagation of course. Hmm, as far as I'm aware every other simulator and game which includes voice comms does so via some kind of helper library (or process) - whether it be TeamSpeak or Roger Wilco or whatever. I don't think the choice of VoIP technology is really important so long as the price is right (free), it supports our target platforms and is well maintained. Unfortunately iaxclient2 is a little lacking in the last part but at least it's open source so we can hack on it. (Of course right now the intergation between FlightGear and FGCom is a bit ugly, but that's exactly what Clement's code fixes, once I merge it) Having the centralised Asterix servers seems to work pretty well, and we've had no problems (so far) finding someone to host them - a purely P2P solution would be much more unreliable I think, in terms of NAT, people in different real-worl locations talking in the same simulated location, and so on. Of course getting the very accurate range modelling would be good, but it's quite tricky to reconcile that with modelling frequencies as a conference call - to be truly accurate we need each transmit / receive pair modelled as a distinct audio stream in terms of signal effects (as I suspect your code is capable of doing!), but that would either place massive loads on the server (especially as number of concurrent clients in a room increases, e.g. KSFO GND or BAY APPROACH), or bring us back to P2P solutions which are flaky. All my opinion of course, but I've some experience with trying to do arbitrary P2P between home connections (i.e NAT at both ends) and it very ugly to support. I'm always amazed how trouble-free our iaxclient + Asterix solution is. James -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.12 is branched
On 14 Aug 2013, at 21:57, Curtis Olson curtol...@flightgear.org wrote: I think the main initial hurdle here is to get the Mac Windows releases sorted out on Jenkins (if they aren't already). We've done the code freeze and branch on schedule so we are mostly down to the mechanics and time of actually building and pushing the release out the door. The lovely folks at Virgin Media have my broadband up and running now, I plugged in the Mac slave and it's happy, and indeed a Mac release build has rolled off the production line smoothly. Now to see if it actually works - testing appreciated. Regards, James -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Updated 707
On 14 Aug 2013, at 21:23, Stuart Buchanan stuar...@gmail.com wrote: Marc Kraus (CC'd as he's not on the -devel list) has produced a (very) significant update to the 707, a model that Innis Cunningham developed a number of years back. It's available from http://gitorious.org/boeing/707 and is well worth a look, particularly for the fine cockpit and engineer station with extensive start-up tutorial. Marc has asked if it would be OK to replace the existing 707 with this new one. Innis (if you're around) - are you OK with this? If Innis is not around, does anyone have any problems with adding this? If replying - please Reply-All to include Marc in this discussion, This is a lovely piece of work - the panel modelling and texturing is superb! Hopefully Innis will respond and we can get these improvements into the main repo. Regards, James -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New release date for 2.12
On 15 Aug 2013, at 09:46, Torsten Dreyer tors...@t3r.de wrote: Curt and James, what would you think about publishing the release during the weekend Sept. 14./15.? Or would you prefer to stick to the 17th (a Tuesday)? I'm actually returning from a weeks holiday that weekend, so the Tuesday is better. James -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.12 is branched
On 15 Aug 2013, at 10:50, Gijs de Rooy gijsr...@hotmail.com wrote: Is http://flightgear.simpits.org:8080/job/Windows-release/ the build that we should look at? Correct. James -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.12 is branched
On 13 Aug 2013, at 21:42, Stuart Buchanan stuar...@gmail.com wrote: I propose pushing out the release by a month. I've got a bit more time available for FG right now, but not as much as I did 12 months ago, and it sounds like James and Thorsten R are similarly time limited. I think it will take longer than usual to address any issues found in the RCs. If we are going to slip the release, we should only do so once :) +1 on all counts. James -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.12 is branched
On 13 Aug 2013, at 12:58, Renk Thorsten thorsten.i.r...@jyu.fi wrote: On the risk of making myself really unpopular, but would now be a good time to defer the release? It seems James is caught in the middle of moving, Stuart indicated some other private things piling up, I have the maddest travelling schedule I've ever had in my life this fall, and I haven't seen a number of other folks around for a while, we don't have release candidates out which will have impacts on bugfixes, assuming there'd be anyone around capable of doing bugfixes,... It seems we've hit a fluctuation where pretty much everyone is occupied with something else at the moment (?) - if that's the case, should we still go ahead? That's possibly a fair suggestion. I am scheduled to get my new broadband connection up and running tomorrow (Wednesday) so the Mac build slave will be available at that time (with decent upstream bandwidth again). However my time is a bit fragmented and likely to remain so for a few weeks - I'm happy to merge patches or anything else anyone explicitly requests, but I'm not focused enough to start chasing other people to get things done :) Once the Mac build slave is back, the biggest obstacle to an RC is getting the Windows build slaves to behave; if anyone on Windows could look at the Jenkins logs and shed any light, it would help. Kind regards, James -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata space in filenames
On 10 Aug 2013, at 15:13, jean pellotier jean.pellot...@wanadoo.fr wrote: i finally did a merge request with the correction to the offending files, tell me if this a thing to do, or i should wait for the maintainers to react (but some are not actif anymore). https://gitorious.org/fg/fgdata/merge_requests/114 Seems entirely reasonable to me. Regards, James -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] internal telnet weirdness
On 9 Aug 2013, at 10:59, Adrian Musceac kanto...@gmail.com wrote: I'm writing an application which uses a socket to connect to Flightgear's telnet interface, and I have encountered the following issue: Writing to Flightgear is fine, but while reading the socket, some properties have weird values, and some characters are getting replaced (L is sometimes replaced by 0 etc.). I am using data mode to read from the socket. I have noticed that the Python Flightgear telnet interface uses prompt when reading. I'm wondering if someone else has encountered this, or is this some Qt socket issue I have to sort out on my own. Qt sockets are very thin wrappers around BSD / Windows sockets. More likely to be a character set / encoding issue? Remember you need to be explicit about encoding when going from 8-bit representation to a QString. That said I've no experience with the FG telnet code. If you want to post your client code I'm happy to quickly look at it. James.-- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.12 is branched
On 8 Aug 2013, at 15:15, Saikrishna Arcot saiarcot...@gmail.com wrote: Erm...shouldn't there be a RC version released sometime around now, since the final version will be released in just over a week? Unfortunately, I'm in the middle of moving house, so rather busy. The release branches exist, and the autobuild is running - someone can take the source ball or binaries (unfortunately the Windows slave is down, someone needs to ping Gene) and test it. James-- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata space in filenames
On 5 Aug 2013, at 21:17, Gijs de Rooy gijsr...@hotmail.com wrote: Fixed those that I'e touched throughout the years, will leave the others to their respective authors/comitters. I think I'm sufficiently motivated to see if I can write a pre-commit hook which rejects names containing spaces. (Not sure how to install hook-scripts on Gitorious, but it must be documented somewhere) If anyone can postulate the shell-fu to detect file (not directory) names which differ only in case, I could add that too. James -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Building Older versions of flightgear on updated operating systems
On 3 Aug 2013, at 13:11, Pat pat.callah...@gmail.com wrote: I won't do any work on this unless its agreed in advance that the patches should be merged and what tags should or should not be updated. Does anyone care about 2.10 at this point? What are your thoughts on updates to previous versions to keep them viable? We've never done this in the past - I don't have any objection to it per-se, if someone is happy to do the work, though I do question the value in doing it for any version prior to $CURRENT - 1, i.e 2.10 but not 2.8. So yes I'm happy to merge and update tags I guess, with the understanding that we won't run the release machinery again or similar. I am assuming the target audience is the download-and-compile script which doesn't care about the release side of things. James -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.12 is branched
On 3 Aug 2013, at 04:27, Saikrishna Arcot saiarcot...@gmail.com wrote: Actually, scratch that; it seems FlightGear allows the --fg-aircraft switch to specify multiple root aircraft directories, although the man page needs to be updated to specify this (it currently says it's only used by UIUC). I added that feature quite a few versions ago, looks like the man page needs to be refreshed :) James-- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.12 is branched
On 30 Jul 2013, at 21:25, Stuart Buchanan stuar...@gmail.com wrote: James - if it's convenient could you pull this to the 2.12.0 release branch please. Done. James -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear build fails
On 31 Jul 2013, at 01:16, Patrick Callahan pat.callah...@gmail.com wrote: Check this out: http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2013-June/063519.html I believe we've dealt with this issue - at least, I have tweaked Jenkins to build the 3.2.0 release candidate and everything is green. Regards, James -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] making sign of side-slip consistent between fdm (bug 901)
On 29 Jul 2013, at 13:54, Jon S. Berndt jonsber...@comcast.net wrote: Beta is positive when the wind hits the right side of the vehicle. This is the only standard convention I have ever seen. I would recommend strongly against artificially changing the sign of this parameter as output from JSBSim. Which raises the question, why does Yasim use the opposite sign? Does it use the opposite sign for Beta too? James -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot filters
On 26 Jul 2013, at 20:11, Alan Teeder ajtee...@v-twin.org.uk wrote: I have added a washout/high-pass filter and an integrator to the XML autopilot. Also I have added aliases to the exponential filter so that it may be also called low-pass or lag and an alias to the noise-spike filter so that it can also be called rate-limit. README.digitalfilters is updated to match, as well as incorporating the undocumented derivative filter and mentioning the use of expressions. How should I submit these for review? Please don´t ask me to use git, as I am very good at screwing my own repos up and would not like to do the same to fgdata. I would greatly prefer you to use Git, possibly after a discussion about workflow and suchlike. If that's utterly impossible you can post a diff or patch here and we can review it. Note that if you use Gitorious' merge-request system, and you can't screw up FGdata, but of course that doesn't help with making a glorious mess of your own... James Alan -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Mac build server
The Mac build server is temporarily down since I'm in the process of moving home. It should be back tomorrow - the hardware is fine, I've just packed away a piece of kit I need to update its IP address to the Jenkins Master can find it. James -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TerraSync libSVN replacement testing
On 21 Jul 2013, at 13:45, Alan Teeder ajtee...@v-twin.org.uk wrote: What is the status of this on Windows 64 bit? Up until now I have kept with 32 bit builds on Windows due to the lack of a 64 bit version of libSvn. The replacement code is disabled by default on next, and 2.12 will certainly not use it. My plan is to enable it (and require it) for 3.0, but I won't make that change until after 2.12 is released, since I'm aware of some intermitted issues with the code, where it gets stuck 'not doing anything'. This is happening for some people erratically, but is annoying, and obviously precludes enabling the code by default! Gijs also reported a crash on Windows - help tracking that down would be most welcome. Regards, James -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Download_and_compile.sh
On 20 Jul 2013, at 15:06, Pat pat.callah...@gmail.com wrote: Eventually I'd like to have a maintainable version on each branch. What we have in fgmeta master and fgmeta 2.10.0 is script version 1.9.4 The one on 2.8.0 is even older, 1.31. None of these work, mostly because of the osg svn url change and maybe other things. Someone would have to test to find out. Script version 1.9.10 which is currently on next does work as is for next and 2.8.0. You could merge that version back to master and the download_and_compile.sh instructions on the wiki will work again. I can backport the -B and -V options from the new script to a 1.9.11 based on 2.10.0. This minor change would mean the existing script could support next/master, 2.12.0, 2.10.0, 2.8.0 and maybe even 2.6.0. Let me know if you want me to do that. To be honest I'm not sure. In general, we don't touch the branches for prior releases (although of course we could). Of course the versions on master and next need to be kept up-to-date. Personally I don't see any value in encouraging people to run older versions of the sim; if people experience problems with newer versions, I'd far rather they reported that than kept using 2.6 or 2.8. There may be valid reasons to stick with a particular version for a dedicated project or similar, but for the kind of users download-and-compile is aimed at, supporting the current and previous stable releases seems sufficient to me. (Possibly as a Mac user my opinion on this is a little distorted!) However, download_and_compile is a little special, in that it supports multiple versions in a single file, so if you can create a compatible version with some small tweaks, then go for it, I guess. I would expect, ideally, that the version on master would build the current official release by default, and the versions on release/2.12.0 and next would build that explicit release, and next, by default respectively. Hopefully this is a one line change in the script when branching fgmeta? James -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug#716834: libfltk1.3-dev: --ldflags should contain -ldl
On 18 Jul 2013, at 02:28, Erik van het Hof h...@hofcom.nl wrote: Patches are git merge-requested on flightgear (#1572) and fgrun (#3). Thanks, will take a look. James -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Download_and_compile.sh
On 18 Jul 2013, at 12:45, Pat pat.callah...@gmail.com wrote: Francesco Brisa, the maintainer of download_and_compile.sh has not reviewed the changes so this remains on the tean repo for now. I'm using this version on a regular basis, but I need others to test this version and give feedback before I'll ask Francesco to approve it. Please let me know if you'd like to help. I'm happy to merge this is into fgmeta's 2.12 branch once it has had some testing, BTW - it would obviously be nice to have this file in sync with the rest of the 2.12 release. James-- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGRun improvements
On 16 Jul 2013, at 21:46, Gijs de Rooy gijsr...@hotmail.com wrote: Anyone? Please... I'll apply it. James -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 2.12 is branched
Hi, I've just created the release branches for FG, SG data (at Torsten's request, since he's on holiday in the wild, Internet-less north of Sweden). Hopefully I didn't screw anything up :) This means 'next' is open for unstable work, and that bug-fixes should be applied to both next release branch and next as appropriate, preferably after a code-review cycle. I've set the version files on 'next' to be 2.99, on the assumption the next release will be 3.0 as discussed. Regards, James -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Changelog 2.12
On 15 Jul 2013, at 00:45, Vivian Meazza vivian.mea...@lineone.net wrote: POI on the map are disabled in Windows (well they are here). Otherwise quite an impressive list. That's because of strange performance problems loading the file on Windows, which someone on a Windows box needs to investigate if they want this feature enabled. There's a one-line #ifdef to enable if you wish to experiment. Regards, James -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] some models updates available
On 12 Jul 2013, at 14:40, Gijs de Rooy gijsr...@hotmail.com wrote: What I always do when I get update packages instead of merge requests is to delete the aircraft locally (not in Git) and then add the new package. That way you will clearly see all deleted files, renamed case-insensitive files etc. Yep, that's what I have learned to do when updating the AI aircraft too. James -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Saitek radio and multifunction panels
On 9 Jul 2013, at 20:54, Durk Talsma durkt...@gmail.com wrote: Also just a quick note from me. At the last FSWeekend, I got a sample radio panel from the Saitek Guys. IIRC, James Turner is/has been working on providing some of the groundwork and we agreed that while he was doing that, I'd put my efforts on getting the device working on hold. It's been a while ago since we last chatted about this, so I'm not really sure what the current status is. I've done some work on it, and will return to it once 2.12 is shipped. (My interest is in supporting the GoFlight hardware, which I've purchased several modules of, but it's all USB-HID in the end) The issue is basically about finishing Torsten Dreyer's event-input code, but also about potentially making that use hidapi (which would greatly simplify the code on the FG side), /if/ I can get the hidapi author to accept a patch adding HID descriptor parsing to the library as an extra. I've also separately had my GoFlight hardware working on Mac using the existing Mac event-input code, but encountered some issues, to do with the rate we pull data out of IOKit; essentially it's too easy to miss events which for certain inputs on the GoFlight panels (rotary encoders) causes odd behaviours. So yes, lots of these pieces exist, it needs some integration work and further development after 2.12. Torsten's current code is also incompatible with the current joystick config XML, which I think probably needs to be addressed in an adapter layer. Regards, James-- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] some models updates available
On 3 Jul 2013, at 22:58, Stuart Buchanan stuar...@gmail.com wrote: Thanks for spotting and sorting this out Gijs. My thanks especially, since it causes me terrible problems on Mac - git thinks my tree is always dirty, so I can't rebase, which I how I normally pull. If I had the script-fu I'd write a pre-commit hook for our Git which checks for files differing only in name-case and rejecting the commit. (And assuming Gitorious supports custom pre-commit hooks) James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG 2.12 RC Broken ?
On 30 Jun 2013, at 19:26, Clement de l'Hamaide clem...@hotmail.fr wrote: For the record , the last development version is *OpenSceneGraph-3.1.5, released on 12th March 2013* at http://trac.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases For your information http://trac.openscenegraph.org is the old OSG website. So you are looking for wrong information. The last dev version is 3.1.8 and even 3.1.9 has been already tagged in trunk : http://www.openscenegraph.org/index.php/download-section/developer-releases Another bug that I've just reported : http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40378.html OSG seems to bring some big changes for now... I think we shouldn't add the patch about Ensure compatibility with OSG 3.1.8 for the 2.12.0 release and simply announce that FG 2.12.0 require last stable OSG 3.0.1 Once 2.12.0 is released we could spend some time to look at updating our code in compliance with last OSG. Actually we can fix that a little better, and detect the OSG version at compile time. I will need to check exactly which #ifdefs are needed for that. James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear build fails
On 26 Jun 2013, at 23:05, Thomas Geymayer tom...@gmail.com wrote: Thank you Alex! I've just commited your patch. Yes thank indeed Alex, it's a relief to know someone is keeping bleeding-edge OSG working, since the rate of change over there seems to be increasing (for the better) James-- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
On 26 Jun 2013, at 08:42, Vivian Meazza vivian.mea...@lineone.net wrote: Makes sense to me, Yep, works for me too. James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
On 25 Jun 2013, at 22:48, Stuart Buchanan stuar...@gmail.com wrote: Declaring that the Feb 2014 release will be 3.0 now will give everyone plenty of notice, and might encourage efforts to fix bugs in the next 6 months. I'm aware that my FG development time is more limited these days, and given activity on this list I suspect I'm not alone, so this time might be quite useful. I think I sensible step in that case is to keep 3.0 as backward compatible (in terms of Aircraft APIs) with 2.12 as possible, which mostly means my resisting the urge to clean up legacy stuff :) Obviously it's tricky to offer a 100% guarantee, but I don't have anything planned for 3.0 that will require aircraft changes - I'm sure new technologies such as state machines, knob/slider animations and tooltips will mature and gain some new features but hopefully aircraft developers will be able to work against 2.12 with confidence that things will work the same in 3.0 It's a bit tricky because I haven't had much feedback from aircraft developers about the new APIs (since they aren't in 2.10), but once 2.12 ships we would want to keep them compatible, so fingers crossed the current design is sensible :) Regards, James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
On 24 Jun 2013, at 07:53, Gijs de Rooy gijsr...@hotmail.com wrote: Wherever I mentioned 2.12, it was because that's the logical follow up on 2.10. If we didn't decide anything, we'd automatically end up with 2.12 instead of 3.0. That's all. I wouldn't worry too much about someone who's telling what other people think, without he himself taking part in the discussion. I agree with Gijs - I've been referring to the next version as 2.12 simply by default; if people feel strongly it should be 3.0, well, it's just a number from my point of view. There was already a couple of people on IRC confused that 2.12 is different to 2.1.2 (since minor version numbers 9 are something of a rarity in many people's perception). So that's arguably a tiny reason to go to 3.0 now. Again, it's just a number to me. Give our release pattern is date scheduled, an Ubuntu style numbering scheme would actually make more sense, but a bit more effort to move too. If anyone spends more than five minutes worrying about the version number of the next release, I would say save your efforts and use them on something more fun or rewarding :) James-- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TerraSync libSVN replacement testing
On 11 Jun 2013, at 16:17, James Turner zakal...@mac.com wrote: I've pushed some code to Git, which will ultimately replace our use of libSvn, and hence simplify build and deployment, especially on Mac and Windows. This has an immediate benefit for end-users too: TerraSync will use pretty much half the disk space it currently does, since unlike a real SVN client, we don't need to keep two copies of each file locally. In the longer term, there are many other improvements I will make - to reduce the number of network round-trips to check directories are in sync, to improve the interaction with the main thread so the splash screen waits for terrasync to update a location before finalising position, and others. These things will happen *after* 2.12, and once the code is tested everywhere. First, I need some help; for people to rebuild simgear with -DSG_SVN_CLIENT=1, and mv / erase their TerraSync dir. Then simply run FGFS as normal, as if you were starting on a new machine / account with no previous use of TerraSync. (Remember that TerraSync initially syncs the large Models and Airports dirs, which takes some time - be patient. Also expect some nav-cache rebuilds since the nav-cache will see the paths / stat-times change. This is nothing to do with the revised code, simply what happens if you change your TerraSync dir) If the testing is mostly positive, I will consider making the option default to ON for 2.12, but if people report problems (which cannot be easily fixed!), I will be cautious and leave it OFF by default for 2.12. Soon after 2.12 branches, 'next' will be switched to using the new code exclusively. (BTW, the option to use rsync or external, command-line svnclient still exists, and will be retained - though I am curious if anyone still uses those options!) If you run from Git, haven't already tried this option, and have a spare moment, I would welcome more feedback on this. So far I have positive feedback from various people, and one problem I can't identity, which is slow downloads for Chris (papillion) on Linux. I encountered this on Mac during testing, erratically - it resulted in the Models directory taking 10 minutes to download instead of the more normal 2-3 minutes (of course scale those times by your Internet download bandwidth), but at some point during development it went away entirely. (The issue is not bandwidth, but the socket apparently sitting idle, as if there's a flow-control issue) Regards, James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Terrain Object ignored at load
On 20 Jun 2013, at 13:20, grtuxhangar team hohora...@gmail.com wrote: UNFORTUNATELY, right now, with recent FG GIt we can't use it. At FG load the new terrain ( it is an object ) is not recognized and the Aircraft is positioned on the original surface of the scenery which is under the new_terrain_object. The feature we had before was very useful, since it could give us any others add on, for instance, platform on the sea or specific building with helicopter area, we could take off from. Does the feature has been removed on purpose, or is it only a bug ? It's a bug, but I think it may be a side effect of fixing a different bug. Someone else reported it since they can no longer land helicopters on scenery (helipads on buildings) I've no idea which change introduced it, alas - if someone could test a few older revisions it would help to narrow it down. James-- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Terrain Object ignored at load
On 20 Jun 2013, at 14:44, grtuxhangar team hohora...@gmail.com wrote: We have a FG Git built working version which is Feb the 17, versus a next FG Git built version NOT working which is March the 20. Sorry we can't be more precise. Okay, that's still a good narrowing of possible changes, thanks. If anyone wants to experiment within that range, it would be much appreciated. I'll eyeball the relevant commit logs over the next few days and see if I can spot anything. James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
On 20 Jun 2013, at 17:54, Stefan Seifert n...@detonation.org wrote: With an AMD Radeon HD 5670 using free radeon driver I've never seen performance of more than 15fps with Rembrandt and if I turn shadow details up so they don't look crappy I get about 3-4fps. And with a i3770K and a GTX670, I get some hit from ALS (10-30%) but Rembrandt instantly drops me to 20fps, and 10fps I use an aircraft I actually want to fly (777 or Citation) and go to any major airport (EGKK, EHAM, EDDM, EDDF, EGLC, VHHH) This is at 2560x1600, but on the 670 I would be highly surprised if I'm fill-rate limited, given that AA is off, and the general suboptimal size of our primitive batches. Emilian has explained on IRC this might be due to the out-of-the-box / default config for Rembrandt being highly suboptimal, which I didn't yet evaluate, I would be delighted to have it more usable. I'm going to test further over the weekend. James-- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
On 18 Jun 2013, at 09:38, Vivian Meazza vivian.mea...@lineone.net wrote: We still cannot select the Screenshot Directory from the gui. I think that all argues for 2.12. Hmm, that is 'just a bug' which will be fixed during the release cycle, I just keep forgetting about it since there's no issue i the tracker and I never use that feature. Of course, you could look at fixing it yourself! BTW I don't have any strong opinion on 3.0 vs 2.12 - it's simply an increasing number, and given our timed release plan, it's inevitable that the amount of work in each release will fluctuate based on people's time availability. James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
On 17 Jun 2013, at 14:41, grtuxhangar team hohora...@gmail.com wrote:
though not sure
gps.cxx line 774
if (!_config.driveAutopilot() || !_defaultGPSMode) {
_apDrivingFlag-setBoolValue(false);
isn't it that strange ?
_apDrivingFlag is ever set to false
Yes, the problem is I assumed aircraft with an explicit GPS instrument are
using a fully configured setup, but in fact many (such as yours) are listing an
explicit GPS in instrumentation.xml, but relying on the default configuration.
These problems are because long ago it was decided it would be a good idea to
have the route-manager, GPS AP work in aircraft which never had such things
in real-life (Spitfires, Cubs…) , so we have to (in C++) decide if the user is
asking for a simulated GPS (which should obey electrical power, and often needs
manual synchronisation of the GPS course - CDI course, and maybe no AP at all
all), or if they are asking for the internal features to 'just work'
regardless.
Anyway, for now the fix is just to go back to the old situation, where we
assume the user wants the GPS to drive the AP all the time.
Longer term, I think I will contemplate a more radical renaming to fix the
issue, where explicit simulated GPSs such as the Garmins and so on use a
different instrument name. ('real-gps' or something) Then I could assume any
aircraft requesting a 'gps' instrument is legacy and wants the old behaviour,
but remove all the awkward defaults for people who really want full simulation.
Regards,
James--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
On 17 Jun 2013, at 15:41, grtuxhangar team hohora...@gmail.com wrote: If you refer to your last fix (yesterday) , it is not sufficient, since like said the /autopilot/settings/gps-driving-true-heading property is not set to true. No, I need to make further tweak this evening, don't worry :) Regards, James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TerraSync libSVN replacement testing
On 17 Jun 2013, at 21:25, Vivian Meazza vivian.mea...@lineone.net wrote: Haven't managed to get it to work for Win 7 64 bit either - still seems to want LIBSVN to build. Seems to be a cmake issue, but I'm not confident that I know how to fix this one. That's because I didn't yet remove the libsvn checks - that would be risky, this close to the freeze. It's strictly a new, optional feature until after 2.12 is branched. Alan, did you have any luck with the compiler errors? it builds on the Windows build slaves on Jenkins I believe. Regards, James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
On 16 Jun 2013, at 13:09, grtuxhangar team hohora...@gmail.com wrote: For the record With FG Git : I cannot get working the autopilot with the route manager, we had an automatic update of the autopilot box , by getting a GPS button , when a way point was activated within the route manager. That feature is not longer working. We had within the GPS box ( menu equipment gps ) , within closest or search by name , the required airport id. That feature is not longer working They're temporarily broken, not definitively broken :) I was travelling most of last week and then had to rebuild my laptop due to a failed hard-drive, later today / next week I'll be looking at a collection of related route-manager / flight-plan / GPS issues. It will help to have very precise test cases in the bug-tracker, since when I did some limited testing two weeks ago, I found searching by nearest or name did work. So really I would like to see very exact steps to reproduce, not simple 'is not working'. Regards, James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
On 16 Jun 2013, at 13:09, grtuxhangar team hohora...@gmail.com wrote: I cannot get working the autopilot with the route manager, we had an automatic update of the autopilot box , by getting a GPS button , when a way point was activated within the route manager. That feature is not longer working. I need some help understanding this one, since you don't like to use the bug tracker please list the exact steps to reproduce the issue. We had within the GPS box ( menu equipment gps ) , within closest or search by name , the required airport id. That feature is not longer working I've just pushed a fix to the GPS box which should fix this issue, please test and let me know. (fix is in fgdata) Thanks, James-- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
On 16 Jun 2013, at 15:46, grtuxhangar team hohora...@gmail.com wrote: Both same place , same computer.. I've just pushed a fix to FlightGear, which fixes part of this for the Cub. Please test and let me know if things are improved! Regards, James-- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Bug 772 (Yasim on ground)
Hi all, Hyde has submitted a work-around for issue 772, which you can see here: https://gitorious.org/fg/flightgear/merge_requests/1572 He'd like this merged before the freeze (actually it's a fix so it can be merged afterwards, but still), I'd like to hear any opinions on if this is a bad idea or good idea. Personally I'm not so affected by issue 772, but if many people are, the work-around seems just-about-acceptable to me. (Obviously it would be nicer to fix Yasim for real, but let's skip that just for a moment) Does anybody feel strongly that either: - the bug is very bad, so that the workaround is definitely needed (keeping in mind it's a long-standing bug) - the work-around is very bad, for some scenario I didn't imagine myself? (Helicopters on the ground? But they likely benefit more from the fix?) I'm happy to merge the change above to get some feedback, with the understanding that if people raise 'problems which are worse than the original issue' before 2.12 is final, we could revert it. James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] TerraSync libSVN replacement testing
Hi, I've pushed some code to Git, which will ultimately replace our use of libSvn, and hence simplify build and deployment, especially on Mac and Windows. This has an immediate benefit for end-users too: TerraSync will use pretty much half the disk space it currently does, since unlike a real SVN client, we don't need to keep two copies of each file locally. In the longer term, there are many other improvements I will make - to reduce the number of network round-trips to check directories are in sync, to improve the interaction with the main thread so the splash screen waits for terrasync to update a location before finalising position, and others. These things will happen *after* 2.12, and once the code is tested everywhere. First, I need some help; for people to rebuild simgear with -DSG_SVN_CLIENT=1, and mv / erase their TerraSync dir. Then simply run FGFS as normal, as if you were starting on a new machine / account with no previous use of TerraSync. (Remember that TerraSync initially syncs the large Models and Airports dirs, which takes some time - be patient. Also expect some nav-cache rebuilds since the nav-cache will see the paths / stat-times change. This is nothing to do with the revised code, simply what happens if you change your TerraSync dir) If the testing is mostly positive, I will consider making the option default to ON for 2.12, but if people report problems (which cannot be easily fixed!), I will be cautious and leave it OFF by default for 2.12. Soon after 2.12 branches, 'next' will be switched to using the new code exclusively. (BTW, the option to use rsync or external, command-line svnclient still exists, and will be retained - though I am curious if anyone still uses those options!) James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TerraSync libSVN replacement testing
On 11 Jun 2013, at 18:52, Anders Gidenstam anders-...@gidenstam.org wrote: I always use the separate terrasync binary since with it I only have to suffer the initial startup synchronization once per day - and not for each FG session. Will the separate terrasync binary use the new SVN replacement if I set the new option? The terrasync binary *should* use the new SVN, it's certainly technically feasible, I just didn't test yet. Setting a refresh timeout is one of the things i want to do after 2.12 - probably 24 hours validity after a successful sync of a dir or tile, would give exactly the speed you want. (And greatly reduce trivial requests on the backend). But also once Airports/A..Z is synced, I'm going to convert it into a single Airports dir, and hence only one round-trip to update, *and* I'm planning to make syncing Airports, Models (and other data in the future, such as AI traffic), a separate HTTP engine from regular tiles, so tiles will validate quicker, not getting stuck behind 'slow' data. Taken together these things *should* make regular terrasync fast enough for you I hope - if you disagree, or can think of other ways to improve it, please say. James-- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 772 (Yasim on ground)
On 11 Jun 2013, at 22:01, Hyde Yamakawa h...@hyde-tech.com wrote: Hi, I'm a guy who submit that fix. I tested today without my fix, I noticed it's been fixed!! There still be the pulling power but it's controllable by steering now. I'm sorry to bother all of you but I didn't know it was fixed. I gladly withdraw my request. I will report what change fixed the issue later. Okay, thanks to everyone for looking at this, if someone could update the issue as WontFix or Invalid for now it's probably wise, it can always be re-opened if someone disagrees. Regards, James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Enabling JPEG factory causes fgfs/GIT to fail compiling
On 11 Jun 2013, at 23:53, Roland Haeder rol...@mxchange.org wrote: please take a look at this: http://pastebin.com/sFMjmxXA The most important lines here are: -- /home/quix0r/fgfs/flightgear/src/Network/jpg-httpd.cxx: In member function ‘virtual bool FGJpegHttpd::process()’: /home/quix0r/fgfs/flightgear/src/Network/jpg-httpd.cxx:179:5: error: ‘poll’ is not a member of -- It can be fixed by disabling JPEG factory in both SG/FG all together. This is my fault, I will fix it. And, I should probably update one of the Jenkins slaves to have JPEG-factory enabled, since this has happened before. James-- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Enabling JPEG factory causes fgfs/GIT to fail compiling
On 12 Jun 2013, at 01:12, Roland Haeder rol...@mxchange.org wrote: That is maybe good to get noticed about it. And this is why I try to enable all features to check if they are okay or broken. :) Glad to help you out again. Well we already have the 'all-FDMs' build on Jenkins for that reason, JPEG factory is a little tougher because it requires SG reconfigured too. Although actually the entire option could likely be removed, and replaced with using the osgDB Image plugins to create a JPEG or PNG. And then it wouldn't need to be a CMake option at all. If anyone would like to attempt this, please ask and I can suggest where to start, it's a nice small project :) James-- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear voice communication
On 8 Jun 2013, at 16:28, Clement de l'Hamaide clem...@hotmail.fr wrote: Hi all, With help from Geoff and James I've successfully added FGCom feature to FlightGear. And thanks the Clement for tackling this. 1) Simultaneous calls snip If someone want to expand IAXClient library in order to manage simultaneous calls, please raise your hand ! I would say that would be 'quite' tough, but more likely we can run two instances of iaxclient simultaneously. 2) OpenAL context In order to avoid context conflict I've merged FGCom sound into global FG sound system. This mean that we can choose to redirect FGCom sound into our headphone and FG sound into our speaker. The question is: can we agree that FGCom sound is played on the same output than FG sound ? Again, if someone is ready to investigate OpenAL deeply, raise your hand. This one I care about, but on Mac stand-alone has the same issue. The fix on Mac is for me to create a non-OpenAL backend for iaxclient, either the PortAudio one or write a native CoreAudio one myself. Anyway this is just 'an enhancement', what you suggest is fine for now. BTW I suspect the iaxclient ALSA backend might give this feature trivially on Linux. I know very little about Linux audio, so I leave it to people there to experiment. Regards, James -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Base fgdata
On 8 Jun 2013, at 02:28, Saikrishna Arcot saiarcot...@gmail.com wrote: Is it just me, or has the base fgdata package size increased since 2.10.0? Do you mean some substantial change in size? That might indicate a bug in the rsync rule which generates the base package. Some comparison of contents would be useful. The one thing I'm aware of is the addition of poi.dat.gz, which is a few megabytes I think. Regards, James -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Windows Log file pipe/redirect
On 6 Jun 2013, at 11:10, Alan Teeder ajtee...@v-twin.org.uk wrote: Has anything been changed in flightgear which could cause this to no longer work? The log file C:/Users/Alan/Appdata/Roaming/flightgear.org/fgfs.log unfortunately does not include the JSBSim output that I am interested in at the moment, even though I can see it flash past my eyes in the console window. What's changed is the addition of that log file :) (Well, and the capability to show portions of the log in the GUI) I was unaware JSBSim output wasn't being captured there, but it makes sense since I'm only capturing SimGear log output, which JSBSim doesn't use. There is a mechanism to send other log streams to the same backend, including partial code to do this with OSG messages. There's a couple of fixes: - figure out what I've (accidentally!) touched which breaks logging to a pipe from the console. There is presumably some subtlety of stdout on Windows, but since the output to the DOS box *is* working, I'm not sure what it is. - convert JSBSim *when running inside FG* to also log to the standard backend. (I was hoping the enhanced log support would be a step towards killing off the DOS-box for release builds in Windows, since it looks rather retro - and on the basis that we frequently want the log file after-the-fact, the file on disk seemed more useful) I can look at the second part over the weekend, the first part (and in general, improving how our log support interacts with the Visual Studio and DOS box) can only be done by someone on Windows. Regards, James -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
