[Flightgear-devel] Rain
Just adding to the list of issues which might need attention: I've recently noticed a weird behaviour of rain - was okay on the ground, but it faded out 300 ft above ground in spite of /environment/rain-norm being set to some number. After some thinking, I think I understand why: The current system displays rain only below the lowest cloud layer, no matter what value is set for /environment/rain-norm. In contrast, Local Weather conceptually defines 3d volumes inside which rain is switched on, otherwise it gets switched off. Previously I didn't bother because I didn't use the layer infrastructure, so I set the lowest layer altitude to 30.000 ft and this guaranteed that rain works fine. Now, with the new rendering system, I place clouds (formally) into the lowest layer, but it gets altitude zero and I keep track of every individual cloud altitude myself which gets passed to Stuart's system as an offset to layer altitude zero. But of course, that now affects rain. Now, the reason why I don't want to be stuck with a layer based system is best explained using my test case Maui. Here, the typical situation is that the layer itself comes in rather low (say 2000 ft) above the sea and then hits the slopes of Haleakala, in strong winds being pushed up all the way to 14.000 ft, raining in the process. So, here practically all the precipitations happens above what one would call 'layer altitude' (the altitude one would have without the obstacle). In order to get that with the current system, I'd need to set layer altitude to the highest point (14.000 ft) and define all clouds with a negative offset with respect to that altitude. Another example would be rain inside a Cb tower (I'm not sure what sense it makes to speak about a layer in the context of Cb anyway). None of this is a fundamental problem, there are various workarounds in which to do it, but a clean solution would be an option to have rain displayed whenever /environment/rain-norm is nonzero and the same for /snow and /environment/snow-norm, without any regard for layer altitude or temperature (there is such a thing as supercooled rain droplets at -10 degrees C, it's not automatically and not even usually snow once it drops below zero). These are things the weather system should be deciding, not the precipitation rendering routines. Cheers, * Thorsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear and 2 Arc Second elevation data
Martin Spott wrote: We're not yet there. On a first test earlier today, 'genapts' ended in a segfault with the recent changes but I ran out of time, thus I have not yet verified if the source change in 'simgear' really was the culprit, Confirmed here. And I thought first it was the new terragear Doing a debug session now... -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear and 2 Arc Second elevation data
Martin Spott wrote: We're not yet there. On a first test earlier today, 'genapts' ended in a segfault with the recent changes but I ran out of time, thus I have not yet verified if the source change in 'simgear' really was the culprit, Confirmed here. And I thought first it was the new terragear Doing a debug session now... -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
Jason Cox wrote: I am hoping to try your changes as I was constantly blowing up the scenery around YWLM by using osm residental data [...] OSM residential is quite ambitious - I'd be a happy man if I succeeded building tertiary without triggering GPC segfaults in 'fgfs-construct' I think the only solution is to make GPC obsolete - either by replacing GPC by something different but functional equivalent or simply (TM ;-) by avoiding any polygon clipping in 'fgfs-construct' overall. Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TerraGear - removing the 'terror' ;=))
Whil I was trying to catch up with old *Terra*-EMail, I found this one: Geoff McLane wrote: Maybe you missed my 'little' question buried deep in my, as usual ;=(), quite log posts, but I was asking about the 'content' of mapserver simgear-cs git... simgear-cs had been a requirement for building terragear-cs but, as far as I understand, it's going to be obsolete pretty soon (it might already be so, but I didn't test thoroughly). Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TerraGear - removing the 'terror' ;=))
Csaba Halász wrote: Also note, installing libgdal1-dev would have pulled in most of these automatically. BTW, for those who are running Debian, I'd recommend to pull the respective GIS packages from: http://debian.gfoss.it/ Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TerraGear - removing the 'terror' ;=))
Geoff McLane wrote: I am sorry Martin. I read your post MANY times, but you will have to provided more clues for this old brain to cotton onto ;=)). I do not quite catch what you can mean by scenery root node? In order to tell FlightGear where to find its Scenery we're currently feeding a _directory_ name (or a list of directory names) as the Scenery Path. Other formats like OpenFlight for example are using a _file_ name as the root Scenery handle. The latter is much more common, as far as I can tell, and therefore doing the same in FlightGear as well would facilitate the transition to different Scenery formats. And I was certainly very under-whelmed by the lack of response on 'private' scenery generation, although I 'know' a number who are pursuing this - http://wiki.flightgear.org/Scenery Well, at least _I_ personally don't care about people's private scenery generation, that's simply not my area of interest. What I am trying to do is building infrastructure (not scenery) which should one day permit to build all this nitfy local scenery at the same level of detail as the 'private' scenery builds do now - but in a global scale and context as opposed to what some people are doing nowadays. I know that this plan is only going to work out if the so-called community is willing to contribute to a more general effort - but, hey, the community gets what the community deserves ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGJS cannot calibrate Saitek Flight Yoke
Hi Muad just to make sure: You know the wiki http://wiki.flightgear.org/Joystick ?? I did use that to set/reset my Saitek X52 with no problems. joe Hey Joe! Yes I did consult it. It solved the issue of calibrating the Yoke.It seems that some aircraft have a dead zone in reacting when one turns the yoke, but I guess this is an Aircraft Developer oriented issue. Best Regards,Kle/Muad'Dib -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
Am 15.10.11 10:53, schrieb Martin Spott: I think the only solution is to make GPC obsolete - either by replacing GPC by something different but functional equivalent or simply (TM ;-) by avoiding any polygon clipping in 'fgfs-construct' overall. Martin. Hi Martin Are there any concrete suggestions ? Cheers, Yves -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] GIT
You may have guessd what this is about: FGDATA and GIT. When we last spoke about it, everything had been prepared to the utmost convenient state possible. I had prepared a script which basically only has to be run, to migrate the truckload of planes, ranging from fine stuff to utter junk, into separate repos, which from then on could be maintained by their respective autors - separately from FGDATA. Since then... ...nothing happened. Developers have buoyantly indulged in their lethargy as ever before and passionately ignored the topic wherever it came up. I must say that even I have a limited amount of patience. And that amount - already accounting for the fact that I'm not a vivid contributer as others and might thus have less of a right to request something from the core team - is about to be depleted by the striking ignorance that is portrayed among those responsible. You want people to help with the development of flightgear, in every area they can? And this is how such help is recognized? Very well understood. I'll let this be my last mail to the list and last time I even remotely mention the topic anywhere. You can see for yourself and wait until that pile of crap hits the ceiling. I'm done with trying to fix it in time, for I'm sick begging you to accept my help. not so kindly, ManDay -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On 15 Oct 2011, at 15:22, HB-GRAL wrote: I think the only solution is to make GPC obsolete - either by replacing GPC by something different but functional equivalent or simply (TM ;-) by avoiding any polygon clipping in 'fgfs-construct' overall. Martin. Hi Martin Are there any concrete suggestions ? Yes, it's being actively hacked on and tested, I believe, because the clipper is the most numerically sensitive part of the whole process, and performance sensitive too. One candidate is being tested already, and there's other options available, but it's really important not to regress the core functionality, so some caution is required! James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
Hi James Thank you very much (and Martin of course) for diving into. I am just curious how you go to replace GPC. Cheers, Yves Am 15.10.11 17:20, schrieb James Turner: On 15 Oct 2011, at 15:22, HB-GRAL wrote: I think the only solution is to make GPC obsolete - either by replacing GPC by something different but functional equivalent or simply (TM ;-) by avoiding any polygon clipping in 'fgfs-construct' overall. Martin. Hi Martin Are there any concrete suggestions ? Yes, it's being actively hacked on and tested, I believe, because the clipper is the most numerically sensitive part of the whole process, and performance sensitive too. One candidate is being tested already, and there's other options available, but it's really important not to regress the core functionality, so some caution is required! James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT
Cedric Sodhi wrote: Developers have buoyantly indulged in their lethargy as ever before and passionately ignored the topic wherever it came up. I don't know everybody's favourites but, anyhow, maybe it's also a matter of preferences. Personally I'd hate having to pull dozends of repositories just to retrieve the current state of 'fgdata'. Therefore I'm quite happy with the current state. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT
I know of another project who's main git repository contains a script, that manages the other git repositories, this allows them to split the gigs of data they have in to more sensible chunks, without having to pull every repository individually. Though the current state will be annoying for new developers on average speed internet connections as afaik, git cannot clone, stop half way, then continue. On Sat, 2011-10-15 at 18:29 +, Martin Spott wrote: Cedric Sodhi wrote: Developers have buoyantly indulged in their lethargy as ever before and passionately ignored the topic wherever it came up. I don't know everybody's favourites but, anyhow, maybe it's also a matter of preferences. Personally I'd hate having to pull dozends of repositories just to retrieve the current state of 'fgdata'. Therefore I'm quite happy with the current state. Cheers, Martin. signature.asc Description: This is a digitally signed message part -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT
Am 15.10.11 22:41, schrieb Christopher Baines: I know of another project who's main git repository contains a script, that manages the other git repositories, this allows them to split the gigs of data they have in to more sensible chunks, without having to pull every repository individually. Though the current state will be annoying for new developers on average speed internet connections as afaik, git cannot clone, stop half way, then continue. Looks like we have to live with a mix of clueless git experience and personal preferences of some administrators ? Cheers, Yves -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT
Christopher Baines wrote: Though the current state will be annoying for new developers on average speed internet connections as afaik, git cannot clone, stop half way, then continue. Someone's providing a starter-package containing just the bare repository for download via HTTP. I don't remember the site but it should be pretty easy to find. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT
On Saturday, October 15, 2011 02:41:15 PM TDO_Brandano - wrote: Really, couldn't we just split off all the aircrafts to a separate SVN repository? Or to several GIT repositories? That way they could be checked out individually. I don't think we need the level of detailed history that GIT provides when it comes to aircraft data, and that way it would be possible for the Flightgear frontends to grab the aircrafts dynamically, if not even FGFS itself when using the multiplay protocol. And a developer should not need to download EVERY aircraft that was ever made for FGFS, One aircraft to test FGFS itself would be enough in most cases, and when checking aircraft specific issues it's a quick job updating only the one plane under exam. Cheers, Alessandro I don't think one aircraft is enough to test FGFS with. Too many differences between these aircraft. YASim vs. JSBSim and vastly different use of Nasal are just two examples. But I think it should be possible to test everything in FGFS with perhaps 8 or10 aircraft and there is definitly no need to have every aircraft in GIT for this testing. So the basis idea that we don't need all of the aircraft in GIT for testing is correct. Hal Date: Sat, 15 Oct 2011 23:33:14 +0200 From: flightg...@sablonier.ch To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] GIT Am 15.10.11 22:41, schrieb Christopher Baines: I know of another project who's main git repository contains a script, that manages the other git repositories, this allows them to split the gigs of data they have in to more sensible chunks, without having to pull every repository individually. Though the current state will be annoying for new developers on average speed internet connections as afaik, git cannot clone, stop half way, then continue. Looks like we have to live with a mix of clueless git experience and personal preferences of some administrators ? Cheers, Yves - - All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
HB-GRAL wrote: Am 15.10.11 10:53, schrieb Martin Spott: I think the only solution is to make GPC obsolete - either by replacing GPC by something different but functional equivalent or simply (TM ;-) by avoiding any polygon clipping in 'fgfs-construct' overall. Are there any concrete suggestions ? As James wrote, one option would be to replace GPC by another clipper (not my expertise). The second option I am investigating is to do all the cleaning and clipping, including cutting holes for line data and airports into the land cover, directly in PostGIS or, preferred, GRASS, thus obsoleting the entire vector preparation in 'fgfs-construct' Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
Am 16.10.11 00:30, schrieb Martin Spott: HB-GRAL wrote: Am 15.10.11 10:53, schrieb Martin Spott: I think the only solution is to make GPC obsolete - either by replacing GPC by something different but functional equivalent or simply (TM ;-) by avoiding any polygon clipping in 'fgfs-construct' overall. Are there any concrete suggestions ? As James wrote, one option would be to replace GPC by another clipper (not my expertise). The second option I am investigating is to do all the cleaning and clipping, including cutting holes for line data and airports into the land cover, directly in PostGIS or, preferred, GRASS, thus obsoleting the entire vector preparation in 'fgfs-construct' Cheers, Martin. There is so many software to do exactly this task. I could not imagine that our scenery is THAT important for this developement. Cheers, Yves -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
