Re: [Flightgear-devel] Doc Project Idea
Made some more progress, and flightgear now links to osg, plib and simgear; with some nice graphics thrown in http://docs.freeflightsim.org/flightgear/ Feedback appreciated. Please note I'm prepared to host this long term eg at docs.flightgear.org or alike Pete -- 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] Patch: FOV automatic compensation for wider screens
On Wed, Oct 3, 2012 at 9:05 PM, Alexis Bory wrote: > The idea is NOT to change anything to this standard. Instead, I've just > added a tiny option in the Display Options dialog: > > [ ] Compensate Field of View for wider screens (Disabled by > default) > We've currently got three different dialog with graphics options - Rendering Options containing elements such as wireframe, frame-rate throttling, random objects/trees, shader quality. - View Options allowing the user to configure the active views - Display Options allowing the user to configure what GUI/non-scene information is displayed on the screen. On balance, I think this new options probably sits best under Rendering Options along with frame-rate throttling. Mind if I move it? -Stuart -- 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] Merge request #181
On Sat, Oct 6, 2012 at 9:15 PM, Stuart Buchanan wrote: > I'll take a look at the changes to GrassCover in more detail when I > get the chance. I've had a look at this in Scotland, where it is a bit too bright based on my own experience, so I'd like to leave this change so it only applies to South America. Obviously I could do the opposite and make some specific materials for Scotland (hmmm, good idea :) On a related note, I've just added a new feature to the ufo: Ctrl+Alt+click displays the lat/lon/alt and landclass(es) of the clicked upon point. Unfortunately due to the way that FG builds up the material definition, we can only display the group of landclasses that this particular terrain piece matches to in materials.xml, rather than the actual landclass itself. I.e, the terrain triangle may have type GrassCover, but if the currently valid materials.xml definition for GrassCover also applies to BareTundraCover and MixedTundraCover, all three will be displayed. Nevertheless, I find it makes it much easier for me to find appropriate pieces of terrain to test/identify for material changes. -Stuart -- 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] Merge request #181
On Sat, Oct 6, 2012 at 12:24 PM, Renk Thorsten wrote: >> I'm taking a look at this merge request. One thing I don't quite >> understand from doing a code read is the chance to the overall >> Grasscover to use the tundra-hawaii-green texture, on line 1909 of >> regions/materials.xml. >> >> Can I check this is intentional? > > This is intentional - I'm trying to capture an effect here which I have > created in my devel branch with an non-GPL texture similar to the Hawaii > green and which works fine for me where I have tested it (US West coast > California, Nevada and Oregon, Himalaya and South America). But admittedly > it's a matter of taste to define this world-wide - if you do not think it > fits other areas of the world, maybe we just give it the tropical South > America header to be on the safe side. I've made the new textures only affect tropical South America, purely to ensure that I could get the changes committed and pushed to origin/master, which is now done. I'll take a look at the changes to GrassCover in more detail when I get the chance. Thanks for your work, as always! -Stuart -- 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] New materials.xml elements to control object/tree density depending on slope angle
> I've sometimes wondered if we could have much greater variety of > 'trees', to place scrub (cactus in Central America, bramble in Scotland) > in areas where full trees don't make sense. I guess wi the regional > materials that ought to be much easier? Yes, it's quite straightforward - tropical South America actually uses the tropical tree texture sheet instead of the default trees. If anyone wants to make a cactus sheet? Or whatever alternative tree sheets - it's pretty straightforward to implement, but I'd also volunteer to do it if needed. > Doesn't that mostly depend on the average temperature? > Which usually depends in the first order on the lattitude and altitude > above sea level. What is beyond this temperature dependence could be tracked > with specific materials then. Not that much. In Finland, we have plenty of birches for instance, but in the Alps there is never a pronouced birch zone when you go up. Also, birches love light, so you often see them on southern slopes, to change to fir on the northern slopes of hills. Greece would have pronounced Cedar forests, except they were all cut down 3000 years ago for ships, so all you get now is shrub. Managed forests don't fall into reasonable patterns in any case. To work out a good scheme which captures all that so that we'd really in the end not need too many regional declarations to get it right isn't quite trivial. * 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] Engine sound and HSI problems with Lightning
-Original Message- From: Vivian Meazza Sent: Friday, October 05, 2012 8:49 PM To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] Engine sound and HSI problems with Lightning Alan wrote > AJ > > With Debug->Browse Internal Properties I see that the properties > "instrumentation/heading-indicator" are stable, but > "instrumentation/heading-indicator-dg" are changing rapidly. > When I press the "Push Source" button the HSI stops rotating and indicates > North, but this does not agree with the RMI or Magnetic compass, which are > in agreement with "instrumentation/heading-indicator/indicated-heading- > deg". > > The chirps in the engine sound exist in other aircraft to a greater or > lesser > degree. e.g. the Sea Vixen. With most it is barely audible, but with the > Lightning and my TSR2 development it is very obtrusive. > > Hope this helps. > > Alan > > -Original Message- > From: AJ MacLeod > Sent: Friday, October 05, 2012 6:03 PM > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Engine sound and HSI problems with > Lightning > > On Sat, 29 Sep 2012 10:59:18 +0100 > Alan Teeder wrote: > > > The second problem is that the HSI spins continuously until the “Push > > Source” button at the bottom of the instrument is pressed. Pressing > > this button twice results in rotation once again. > > Hi Alan, > > I've made a few minor changes to the Lightning sounds and sound XML - > sadly none of them fix the main issue you reported (it seems to be a wider > FG issue as you say) but the warnings about stereo sounds are addressed. > Vivian will hopefully be committing these changes at some point when he > gets a moment - to my ears the startup sequence sounds a little bit better > though if I had the time I think I'd do it differently... feel free to > improve it in > the meantime! > > The HSI issue on the other hand I don't see at all here so not sure what > might > be causing that unfortunately. Does anyone else have the same issue? AJ's update has been pushed. The stereo warnings should have gone away. However, I'm hearing noise spikes in the engine sound. I'm also seeing this error: ALC Error (sound manager): Invalid Enum at context creation. I'll try to analyse the sound to see if the noise spikes are present in the sound file. I can see no problem with the HSI either on the panel or in the property tree. HTH Vivian -- Today I have been very busy with my wine harvest, and am now sitting down to rest. In see the rotating HSI problem only with Windows. It is not there on Linux. Also on Linux the HSI agrees with the RMI and magnetic compass, which is not the case in Windows, where the HSI either remains stuck on North, or rotates depending on the source select switch. As a test, I disabled my private aircraft directory in case this was causing the problem. Sadly the Lightning HSI continued to spin. Tortoise git pull and diff tools declare that my fgdata, flightgear and simgear directories are all up to date and correct. I think that I will go and stir the wine. Just 750 litres this year! Alan -- 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] New materials.xml elements to control object/tree density depending on slope angle
Hi, On Saturday, October 06, 2012 14:14:49 James Turner wrote: > I've sometimes wondered if we could have much greater variety of 'trees', to > place scrub (cactus in Central America, bramble in Scotland) in areas where > full trees don't make sense. I guess wi the regional materials that ought > to be much easier? Doesn't that mostly depend on the average temperature? Which usually depends in the first order on the lattitude and altitude above sea level. What is beyond this temperature dependence could be tracked with specific materials then. Mathias -- 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] New materials.xml elements to control object/tree density depending on slope angle
On 6 Oct 2012, at 12:27, Renk Thorsten wrote: > Nice - looking forward to it! > >> (and before anyone asks, I'm not planning to reduce tree density on >> shaded slopes...) > > We wouldn't really want that - shaded slopes in my experience do not grow > less trees, they just grow different tree species... :-) I wonder if we could > trick the shader into doing that, since that selects tree species from the > sheet (just thinking aloud...) I've sometimes wondered if we could have much greater variety of 'trees', to place scrub (cactus in Central America, bramble in Scotland) in areas where full trees don't make sense. I guess wi the regional materials that ought to be much easier? 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] New materials.xml elements to control object/tree density depending on slope angle
Nice - looking forward to it! > (and before anyone asks, I'm not planning to reduce tree density on > shaded slopes...) We wouldn't really want that - shaded slopes in my experience do not grow less trees, they just grow different tree species... :-) I wonder if we could trick the shader into doing that, since that selects tree species from the sheet (just thinking aloud...) * 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] Merge request #181
> I'm taking a look at this merge request. One thing I don't quite > understand from doing a code read is the chance to the overall > Grasscover to use the tundra-hawaii-green texture, on line 1909 of > regions/materials.xml. > > Can I check this is intentional? This is intentional - I'm trying to capture an effect here which I have created in my devel branch with an non-GPL texture similar to the Hawaii green and which works fine for me where I have tested it (US West coast California, Nevada and Oregon, Himalaya and South America). But admittedly it's a matter of taste to define this world-wide - if you do not think it fits other areas of the world, maybe we just give it the tropical South America header to be on the safe side. * 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
