Re: [Flightgear-devel] Nav-cache
I wonder how we deal with this with the next release- I'm sure a whole lot more users will complain about the stuck while launching FGFS. By printing a message like 'Building database during first startup' on the screen? By including the binary nav data with the release? Doesn't look like a show-stopper to me... Let me just say that I'm _extremely_ grateful for this feature - I so frequently just start Flightgear, have a look how a parameter change looks in practice and end it again, and reducing the startup time by half makes a lot of difference. * Thorsten -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Depth buffers, render bins and passes
You know that rendering a transparent object twice alter its transparency. Of course, you can avoid to render it in the color buffer using write mask in one pass. What I do with the trees is render just the opaque bits early on as white with essentially no light and fog computations to set the z-buffer and discard all transparent pixels in the first pass, then render the rest in detail with lequal comparison later. The first pass has just one texture lookup in the fragment shader, but what this saves is rendering the terrain pixels (and other trees) covered by the tree, and the terrain has a lot of complicated light and fog equations to solve, as well as up to four texture lookups and lots of noise generation. To trade that against an additional pass for trees which is essentially trivial turns out to be a really good deal. Of course, here's the part I don't know: All this makes perfect sense as long as the fragment shader is the bottleneck. But the first tree pass also needs the geometry computations in the vertex shader, and in an environment where the vertex shader is the bottleneck, it would make matters actually worse. So, the framerate gain for me personally left aside - what should I do with such things? Commit them and hope a majority will benefit? Not commit them? Make them optional and create a complicated rendering dialog? Test them and gather feedback? The idea with clouds is still to slip rectangles in which cover most of the opaque core of a cloud, render them into the z-buffer early on while passing through the normal clouds through vertex shading and discarding them in the fragment shader, and then render the rest of the clouds and the terrain with lequal comparison onto that depth buffer. I don't know if it actually works, but at least I'm pretty sure I understand now what is expensive about cloud rendering - funnily enough, it's fogging them. In a layer looking forward, we can have hundreds of cloud sheets overlapping all drawn from outside in, and so the fogging means we compute hundreds of exponential functions for every pixel... Depth buffering should definitely help here. * Thorsten -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Depth buffers, render bins and passes
On Thursday, October 04, 2012 06:42:30 Renk Thorsten wrote: You know that rendering a transparent object twice alter its transparency. Of course, you can avoid to render it in the color buffer using write mask in one pass. What I do with the trees is render just the opaque bits early on as white with essentially no light and fog computations to set the z-buffer and discard all transparent pixels in the first pass, then render the rest in detail with lequal comparison later. The first pass has just one texture lookup in the fragment shader, but what this saves is rendering the terrain pixels (and other trees) covered by the tree, and the terrain has a lot of complicated light and fog equations to solve, as well as up to four texture lookups and lots of noise generation. To trade that against an additional pass for trees which is essentially trivial turns out to be a really good deal. Of course, here's the part I don't know: All this makes perfect sense as long as the fragment shader is the bottleneck. But the first tree pass also needs the geometry computations in the vertex shader, and in an environment where the vertex shader is the bottleneck, it would make matters actually worse. So, the framerate gain for me personally left aside - what should I do with such things? Commit them and hope a majority will benefit? Not commit them? Make them optional and create a complicated rendering dialog? Test them and gather feedback? The idea with clouds is still to slip rectangles in which cover most of the opaque core of a cloud, render them into the z-buffer early on while passing through the normal clouds through vertex shading and discarding them in the fragment shader, and then render the rest of the clouds and the terrain with lequal comparison onto that depth buffer. I don't know if it actually works, but at least I'm pretty sure I understand now what is expensive about cloud rendering - funnily enough, it's fogging them. In a layer looking forward, we can have hundreds of cloud sheets overlapping all drawn from outside in, and so the fogging means we compute hundreds of exponential functions for every pixel... Depth buffering should definitely help here. * Thorsten Hi, Take a look here http://developer.download.nvidia.com/GPU_Programming_Guide/GPU_Programming_Guide_G80.pdf pages 43, 44. They deal with cases where the culling optimizations might be disabled/underperforming. Emilian -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine sound problems with Lightning
On 10/03/2012 11:02 PM, AJ MacLeod wrote: On Mon, 01 Oct 2012 17:47:54 +0100 James Turner wrote: The place I miss stereo sounds most is in glider cockpits - where are you going to position the sound of the wind rushing past the canopy, fuselage etc? It's bound to just sound mono and dead (I'd be happy to be proved wrong of course!) I once experimented with two (mono) noise locations (obviously left and right of the listener but it might even be a higher number for gliders) with two different noise samples using independent properties (like pitch based on angle-of-attack and/or side-slip angle). From memory this sounded quite convincing but I don't remember if it ended up in one of the aircraft. The most obvious place I could have put it is in the c172p though. Erik -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Gitorious] Activity: fredb pushed 1 commits to nextnext...
James wrote On 27 Sep 2012, at 09:40, James Turner wrote: Here the aircraft model appears 5 sec before the scenery, I'm seeing this intermittently too, I think it's related to ThorstenB's clean-up of the scenery init process. I'll let him comment how likely that is. then the throttle is wide open and the brakes are off despite the settings in the ~.set file, so the aircraft races down the runway. That's bad enough on an airfield, but it really screws up the start on a carrier. I'm not seeing that with the aircraft I test regularly - Bravo, c172 and 777. I also didn't see it with the Vulcan or CRJ1000 yesterday. It's possible it's related to my moving the FGcontrols init, but a bit research on if it's aircraft specific, and if so, why, would be helpful. I've just pushed some changes that should help this (or not!) - please test and let me know if you see any improvement. I've just pulled and built SG/FG/FGData. The start looks fine now, after only a short test. However, I only see incomplete language resource on the splash screen during the start sequence, and the spinner starts about halfway through. I don't see any of the old messages. I will do some more testing to try to ensure that this initial test result isn't aircraft-dependent. Sorry about the tardy reply - I've been away on a short break. Good to come back and find it fixed. Vivian -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nav-cache
On 4 Oct 2012, at 07:27, Renk Thorsten wrote: By printing a message like 'Building database during first startup' on the screen? That's already done. By including the binary nav data with the release? This is possible but there's something weird going on with some people's rebuilds. Touching the files will cause a rebuild, so rebuilds need to take a 'reasonable' amount of time. Shipping the binary data improves first-launch perceptions, but many applications do additional work on their first launch after an install, so it's not my top concern. As I said in the bug, my concern is why the rebuild times are so bad for some people - it's purely a CPU / disk-bound operation, and for me and all people I've asked, it's around the ~60sec for debug, ~30sec for release times for a complete rebuild. (That time will be dramatically reduced if we get the taxiway data out of apt.dat in the future, since taxiways account for 80% of the lines in the file). Regards, James -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Depth buffers, render bins and passes
On 4 Oct 2012, at 07:42, Renk Thorsten wrote: What I do with the trees is render just the opaque bits early on as white with essentially no light and fog computations to set the z-buffer and discard all transparent pixels in the first pass, then render the rest in detail with lequal comparison later. I am pretty confident (and hope to test, but it sounds like you might beat me to it) that for either the classical (non-Rembrandt) render, doing a depth-write *only* pass of the entire scene will be a net win. (Again assuming the fragment shader is the bottleneck). Since this will reduce overdraw to zero - solving both the 'cockpit covers terrain' optimization, but also where random trees or buildings do. (Which is presumably where your 30% gain comes from) James -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Gitorious] Activity: fredb pushed 1 commits to nextnext...
On 4 Oct 2012, at 09:19, Vivian Meazza wrote: I've just pulled and built SG/FG/FGData. The start looks fine now, after only a short test. However, I only see incomplete language resource on the splash screen during the start sequence, and the spinner starts about halfway through. I don't see any of the old messages. I will do some more testing to try to ensure that this initial test result isn't aircraft-dependent. With a latest pull, the spinner should spin the entire time, with a few pauses later on. The translation strings come from FGDATA, so it sounds like either your fgdata hasn't updated correctly, or you're somehow selecting a locale for which we don't have translations? James -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Depth buffers, render bins and passes
I am pretty confident (and hope to test, but it sounds like you might beat me to it) that for either the classical (non-Rembrandt) render, doing a depth-write *only* pass of the entire scene will be a net win. (Again assuming the fragment shader is the bottleneck). Since this will reduce overdraw to zero - solving both the 'cockpit covers terrain' optimization, but also where random trees or buildings do. (Which is presumably where your 30% gain comes from) I guess there's only trees, random buildings, cockpit and clouds which can cover substantial parts of the scene (all else is rare and exotic...). Trees I've accounted for, random buildings most likely cover urban landclass which has no overlay texturing and is hence pretty cheap to render if no urban effect is on (in which case you can't have buildings), so the expected gain is less. Clouds are a bit tricky if done directly because their rotations sit pretty heavy on the vertex shader, so doing a second pass might create a new vertex shader bottleneck (at least in one try it did, but I may have done something fishy there). Hence the idea to slip the obscuring rectangles in... The cockpit is the biggest potential gain, but due to the near camera - far camera thingy, I don't see how this can be done on the level of editing effect files - maybe a suitable edit of the camera group code can pull that off, but I have no idea where to start there. If you figure that one out, it'd be great. * Thorsten -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Depth buffers, render bins and passes
On 4 Oct 2012, at 10:02, Renk Thorsten wrote: The cockpit is the biggest potential gain, but due to the near camera - far camera thingy, I don't see how this can be done on the level of editing effect files - maybe a suitable edit of the camera group code can pull that off, but I have no idea where to start there. If you figure that one out, it'd be great. Right, that's absolutely the first item on my 'look at easy performance gains' list. James -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Depth buffers, render bins and passes
De: James Turner zakal...@mac.com On 4 Oct 2012, at 10:02, Renk Thorsten wrote: The cockpit is the biggest potential gain, but due to the near camera - far camera thingy, I don't see how this can be done on the level of editing effect files - maybe a suitable edit of the camera group code can pull that off, but I have no idea where to start there. If you figure that one out, it'd be great. Right, that's absolutely the first item on my 'look at easy performance gains' list. I have in my Rembrandt TODO list to restore the use of a near and a far camera to reduce z-fighting. But Rembrandt needs a monotonic depth buffer, and erasing it in the middle of a frame is not an option. So I think we can render the near camera using a depth range (see glDepthRange) of (say) 0.0 - 0.1 and the far camera with a range of 0.1 - 1.0. This will have the advantage to allow the near camera to be rendered first. Mathias or Tim also suggested to look to logarithmic depth buffer but that is more demanding and needs a shader for all geometry (already true for Rembrandt, but not for the classical renderer). Regards, -Fred -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FW:Using FlightGear to visualize JSBSim state
I found that if I waited a little but longer so that FlightGear was completely started up, and used UDP instead of TCP that it worked. Great! -Original Message- From: Jon S. Berndt [mailto:jonsber...@comcast.net] Sent: Wednesday, October 03, 2012 6:03 AM To: 'FlightGear developers discussions' Subject: [Flightgear-devel] FW:Using FlightGear to visualize JSBSim state I've been trying to drive FlightGear from an external instance of JSBSim running, over a socket. Not having much luck at the moment. Looks like I have the correct net_fdm header (version 24). I start FlightGear like this: $ FlightGear/projects/VC90/Win32/Release/fgfs.exe --fg-root=c:/cygwin/home/jon/flightgear/fgdata --aircraft=c172p -- native-fdm=socket,in,60,,5500,tcp --fdm=external After that is started up I crank up JSBSim with an output specified in the aircraft config file like this (per the email from HDWysong): output name=localhost type=FLIGHTGEAR port=5500 rate=60/ In the JSBSim console I get this: Successfully connected to socket for output ... send: Software caused connection abort send: Software caused connection abort send: Software caused connection abort ... FlightGear immediately core dumps. Any suggestions? Jon -Original Message- From: Jon S. Berndt [mailto:jonsber...@comcast.net] Sent: Wednesday, October 03, 2012 5:20 AM To: 'Development issues' Subject: Re: [Jsbsim-devel] Using FlightGear to visualize JSBSim state That was it. Thanks. Although I did get FlightGear to start up in this mode, it core dumped when I tried to connect from JSBSim. I wonder if I need to update the net fdm header. Jon -Original Message- From: Anders Gidenstam [mailto:anders-...@gidenstam.org] Sent: Wednesday, October 03, 2012 2:03 AM To: 'Development issues' Subject: Re: [Jsbsim-devel] Using FlightGear to visualize JSBSim state On Tue, 2 Oct 2012, Jon S. Berndt wrote: Not sure it does work: FlightGear/projects/VC90/Win32/Release/fgfs.exe --fg-root=c:/cygwin/home/jon/flightgear/fgdata --aircraft=c172p native-fdm=socket,in,60,,55p --fdm=external Processing command line arguments Fatal error: Failed to open file at native-fdm=socket,in,60,,5500,tcp (received from SimGear XML Parser) Did you drop the '--' that should go before native-fdm when transcribing the command line to the message? Or are they missing there too? If it is the latter SG tried and failed to open the file native- fdm=socket,in,60,,5500,tcp. Cheers, Anders -- --- - - - - Anders Gidenstam WWW: http://gitorious.org/anders-hangar http://www.gidenstam.org/FlightGear/ --- - - - - --- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Jsbsim-devel mailing list jsbsim-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jsbsim-devel ___ The JSBSim Flight Dynamics Model project http://www.JSBSim.org ___ - - - --- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Jsbsim-devel mailing list jsbsim-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jsbsim-devel ___ The JSBSim Flight Dynamics Model project http://www.JSBSim.org ___ --- - -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Jsbsim-devel mailing list jsbsim-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jsbsim-devel ___
Re: [Flightgear-devel] Depth buffers, render bins and passes
De: Frederic Bouvier I have in my Rembrandt TODO list ... BTW, this is not meant to refrain anybody to follow this route or another ;-) Regards, -Fred -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] another git question
Thanks again everyone for the great feedback. I was completely unaware of the git bundle mechanism. That actually seems like it is the simplest and most straight forward. It allows pretty typical work flow with just an alternative mechanism for handling the network parts. The only tricky thing appears that I have to manually look at the log of commits and make sure I bundle the right things. Typical pull/push over the network figures all that out automatically. In my case I can sneaker-net the bundle or if it's small (which it usually is) I can sz/rz them back and forth over my slow console connection. So +1 on git bundle! :-) Curt. On Wed, Oct 3, 2012 at 4:05 AM, James Turner wrote: On 3 Oct 2012, at 09:41, Tim Moore wrote: A better alternative in your case might be to use git bundles, which pack into a file the data that would be on the wire in a git push. http://git-scm.com/2010/03/10/bundles.html seems well suited to your scenario. Oooh, I didn't know about these - they sound like a good solution to Curt's issue. (Well, I'm a little surprised he/Curt can't rig some kind of serial/ usb-ethernet connection sufficient to push/pull directly from the device, but that's 'solving the wrong problem' :) James -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] another git question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/04/2012 05:58 PM, Curtis Olson wrote: Thanks again everyone for the great feedback. I was completely unaware of the git bundle mechanism. That actually seems like it is the simplest and most straight forward. It allows pretty typical work flow with just an alternative mechanism for handling the network parts. The only tricky thing appears that I have to manually look at the log of commits and make sure I bundle the right things. Typical pull/push over the network figures all that out automatically. In my case I can sneaker-net the bundle or if it's small (which it usually is) I can sz/rz them back and forth over my slow console connection. So +1 on git bundle! :-) Thank you a lot. :) I'm happy to provide a good service to all community members. The main bundle can be found at the preferred location via BitTorrent: - --- http://mxchange.org:23456/file?info_hash=%BF%FF%AB%0C%16%BF%8Eg%B8%A0%CFw%01%0A%5D%8F%3F%81%96y - --- There is now one increment update available for those having trouble updating git because of network trouble: - --- http://mxchange.org:23456/file?info_hash=%DB%C3%E3%8B%E5%F1%07%CE%15%88%03%A7%0C%0E%F19%9C%91%03%CC - --- My main website for this is here: http://flightgear.mxchange.org/fgdata-bundle.html There is a direct download (same file) for the main bundle. But I would like to welcome you to download from BitTorrent as 4.73 GB (see tracker) is really a lot for my server if e.g. 100 people are downloading it. I may discontinue the direct download in the future if it starts consuming to much traffic. Then it is only (and the better way) available through BitTorrent. Regards, Roland Haeder PS: Here is my tracker: http://mxchange.org:23456/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlBtxloACgkQty+BhcbHvXjNOwCgth8buZdeDISeZlaK287WR201 WAcAoKB+m+Ryw5Na+Q/UlXxWvuq5A8MQ =zcXz -END PGP SIGNATURE- -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Gitorious] Activity: fredb pushed 1 commits to nextnext...
On 4 Oct 2012, at 01:28, James Turner wrote: The translation strings come from FGDATA, so it sounds like either your fgdata hasn't updated correctly, or you're somehow selecting a locale for which we don't have translations? The English language resource is always considered for defaults. incomplete resource only appears when the identifier isn't found in the user's selected language resource, nor in the English (master) resource. So, a git pull for fgdata is required here, to update the (English) GUI labels. cheers, Thorsten -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
