Re: [Flightgear-devel] Weather
Hi Thorsten Thanks a lot for helping me understand how this could work with METAR and advanced weather. Because I’m not that familiar with remarks in metars I misinterpreted position as possibility to distribute the center position by coordinates (forgive me pilots here), but it is just N/S/E/W etc. of the reporting location as I understand. The most advanced option is to do exact synchronization over the MP protocol by exchanging random seeds between clients. That's not so much additional Nasal, maybe a few hundred lines, but requires changes in other places as well. When I’m reading older threads and try to understand how the MP protocol works and where the sharing of random seeds could be really practicable too actually- I fear I should really take HLA/RTI into account. A weather engine creates a weather federation which could be shared by other participants. Since I'm not sure what exactly you want to do, I can't really tell you what the best option is. I want to synchronize some kind of raw weather data over the network I guess, independent of the viewport. This sounds simple, but I see ... it’s not. Ok, the random seed is just some kind of raw data too, but probably needs the HLA/RTI idea to be the most efficient option, not sure about at the moment. Anyway, thanks a lot for your reply -Yves -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Hawaii regional textures merge request
Okay, given yesterday's discussion, I don't know if there is still need to discuss further or not I guess there is. Still, I think it makes the Hawaii experience much nicer. I'm sure about that, beacuse personally I follow all your contributions and it is really nice work, just to state. But ... there is no visible structure in textures folder yet for regional textures, is it ? Want a zurich_kreis_6_neighbourhood_grass.png as a 30mb .dds for my next merge request ? ;-) I miss some ideas and proposals from core developers here where this should go. Materials have a structure now, but textures and aircrafts still miss a naming convention and better structure (and some textures committed the last months just filled up the clonable repository, even they have been removed because this area is under heavy development). Cheers, Yves -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Regional textures merge request
On Tue, May 15, 2012 at 8:52 AM, Renk Thorsten wrote: Quick question to Stuart: Currently the conditionals for texture selection are done using /position/longitude-deg,... i.e. aircraft position. The actual tile position however is different from that by the visibility and an direction, which makes for some uncertainty. So, it'd be more consistent to place a condition on the position of the tile to be loaded rather than the aircraft - is that information exposed somewhere (or would it be difficult to do that)? Sorry for the delay in replying - I've been away. As Fred says, it would be possible, with some changes to the materials.xml format and the tile loader. However, I think we can do better. Martin Spott pointed out to me off-list that one could use a GIS shapefile to define a region. This would be much more flexible, allowing for non-rectangular areas to be defined. So, if we're going to change the tile loader, I'd want to go down that route instead. Hi Stuart Good point from Martin Spott off-list ;-) but anyway, has there ever been a proposal how this regions could be defined ? Is there a wiki, a readme or something ? I stumbled over an interesting system the last months, because I was looking for a landcover system with less inconsistency than corine or other systems ... and found a complete different approach which might be interesting for getting such materials/texture regions probably ? Not sure, but this could also lead to a new approach how to use textures at all with flightgear, but of course this is just a very vague assumption. LCCS is the only universally applicable classification system in operational use at present. It enables a comparison of land cover classes regardless of data source, economic sector or country. The LCCS method enhances the standardization process and minimizes the problem of dealing with a very large amount of pre-defined classes. Taken from here: http://www.glcn.org/sof_1_en.jsp Cheers, Yves -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Regional textures merge request
As Fred says, it would be possible, with some changes to the materials.xml format and the tile loader. However, I think we can do better. Martin Spott pointed out to me off-list that one could use a GIS shapefile to define a region. This would be much more flexible, allowing for non-rectangular areas to be defined. So, if we're going to change the tile loader, I'd want to go down that route instead. Well, I don't want to be greedy, I just wanted to know if it's trivial to do - what we have now is quite a bit better than what we had previously - it's just not perfect and still has some issues. But if that's how it stands, I'll create a merge request for my Hawaii project as it is (i.e. including the visibility-range dependent artefact generated by the transition from lush green to volcano red in shrub and tundra). I think it's still nice to fly Hawaii with the regional scheme. Hi Thorsten Sorry for my impatience, but I think before one start to have tousands of custom scenery textures in fgdata we should discuss if such limited custom scenery changes makes sense to be in the (already heavy) fgdata repository. What I like about conditioning on position is that it's simple - everyone can do it, and it already seems to inspire some to try to use the scheme: http://www.flightgear.org/forums/viewtopic.php?f=5t=16418 I may rot in custom scenery hell for what I write down here because I still have some kind of world scenery in mind ... Something I really fear meantime is a git-exploding texture folder in fgdata because of focus on better textures for small custom scenery projects. Yes, its just as simple as this more or less useless comparison in this first post at the forums. The only thing that needs to be done here is improving landcover shapefiles to get more details, later changing some textures and materials.xml and providing a custom scenery project, trought whatever channel ... but when I look at this, why not being consistent and just go for detailed photo scenery at the end ? Looks wow all the time. (But once you will realize with photoscenery youre only flying at noon for the rest of your flightgear scenery life ;-) I think that wouldn't be so easy with a GIS shapefile (I would not know how to start that way for instance). But if we ever move to a more faithful solution, e may have all the texture sets for various parts of the world already in place :-) - so we're not losing anything. The GIS shapefile might be easy, but this will first need some new sg/fg and probably terragear code for such meta coverage. And more proposals, ideas and some kind of a scenery master plan. Here I will add a note to the concept of the transition shader I introduced a longer time ago. Stupid, but the idea was to have LESS texture files at the end to free resources. It was inspired by the idea of having natural structures, giving (transitional) patterns with different colour schemes, following water/clima/temperature or whatever parameters. (The code for the texture/shader handling with transition shader was simply based on an idea of Tim Moore and an uncited/unknown contributor for the old but working crop shader). Parallel to the transition shader I had the idea for an improved texture system based completely on transitions, having a texture folder with some small structures and another with colour schemes, following some newly introduced meta-vegetation-parameters. Ok, I never finished this task because Im not able to introduce the new parameters to sg/fg code. But personally I vote against having a big bunch of rural textures in a wow-fgdata for the moment. I would really like that new overall shader/texture concepts are tested and discussed well and gives proposals and roadmaps to all the scenery projects, eating less resources when possible. Otherwise I guess we will end up with a heavy archive of temporary custom scenery approaches. Cheers, Yves -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
Selectively disabling features is probably not going to work reasonable as long as the features in question are required to play nice in order to get disabled, there's no such infrastructure as a kill-switch to prevent the use/loading of *any* shaders (or whichever additional feature). Personally, I think the problem is that easy enabling/disabling shaders goes along discussion of personal preferences and technical/graphical wow!-game-competition of some developers temporary, and not along other discussion. The effects and shader inheriting system is not used as it could for such switches, at least for me. But dont get this wrong, because it might be right in sense of moving forward in such a project ! Its just a lazy comment of a man with varying interest, trying to follow every graphical enhancement the last years. Cheers, Yves -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
Yves: Towns are not point features. The vmap0 represents towns as points, but these particular points are parsed by terragear and turned into 1km by 1km polygons which are burned into the terrain. That gives the square appearance in the default scenery. Hi John Yes, Im aware of this behaviour of terragear and vmap0. But I also remember this town model, a european church-like building with some houses grouped, all with same elevation. This looked very ugly i.e. in mountain areas (half of the village in the hill, rest hovering over terrain). And without this models you see this squares, which is the most atypic form for a small housing scheme/settlement/village in most places of the world. When the random buildings can be used to represent a settlement in near future and with new generated scenery I thought maybe its time to change cs_town from point to polygon feature from the beginning of scenery creation/digitizing now, and also remove this point to square option of terragear completely. Without claiming to have complete overview myself, I dont know any natural landclass where such geometry make sense. When it is not possible to change cs_town definition to polygon I will vote for an additional landclass, even Im sure we should reduce the classes ... -Yves -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] updates to nav.dat.gz
On 24 Apr 2012, at 08:28, ThorstenB wrote: If data needs to be loaded anyway (airport codes/positions), then distributing it to tons of individual files may not help with start-up delays either. James really needs to comment on nav data things though, since I never touched this area. The quick answer is, we need a lot of data *available* at startup for position init. Parsing it from apt.dat and nav.dat is 'slow', but has been optimised over the years. (Parsing 20MB of text data each launch is still kind of crazy, though) Collecting it from many XML files would also be slow, but there's a general point that we should be decoupling *availability* from *loading*. I've had (in the past, it's bit-rotted now) a binary cache of the navdata and airport-data (stored into $FG_HOME), so that assuming the stat() data on files hasn't changed, no time is spent rebuilding the cache on launch - which makes the FGFS launch time dramatically better, for me. Having such a cache takes a major constraint off how the data is structured and parsed, so I think it needs to be revisited. (Quite a lot of the structuring of FGPositioned and related classes is to make such a scheme possible, especially the fact everything is ref-counted - another benefit of the cache is not needing to have every airport, navaid, runway and taxiway from apt.dat in RAM) To repeat what I said in some other places - on the C++ side I can tolerate (and am happy to write the code!) to deal with nearly any format - XML files in the scenery, single files in XML or the X-plane 810 or 850 format - whatever. It's not that hard, I understand the issues and we have plenty of supporting code. My concern is that 'the community' agree a design that fits most people's needs. (And can generate / get / maintain the data!) Thorsten's point about matching apt.dat and nav.dat into TerraSync makes a lot of sense to me, for example. I'd also be happy looking for navaids in the scenery structure (in the w010n040 dirs?), looking for *all* airport data in the Airports/E/G/P/ structure, or anything else. I really don't mind, and I can support several approaches with some schemes taking precedence, but deciding what design is right, I have not much clue about :) James Hi James Maybe its also worth to compare whats in FGx here. A lot of all this C++ code is already in. The cache, a very fast apt.dat parser, a xml parser etc. Cheers, Yves -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] updates to nav.dat.gz
Hi Thorsten, ThorstenB wrote: On 23.04.2012 13:52, Christian Schmitt wrote: We could, if the xml parser would not simply discard any new runways that are not already in the apt.dat file. If I understood a comment of James in the bug tracker correctly, this, however, always has been and still is the normal behaviour, since these XML files were only intended to provide updated airport info, not introduce completely new ones (so it's not a new bug, as someone suggested). Indeed, the XML structure was primarily meant to override incorrect values of pre-existing airfields. Anyhow it's by far flexible enough to add additional features wherever it makes sense. Thus, for the cases you outlined, I don't see the need for distributing yet another set of files carrying almost redundant data. Hi Martin Is the code/the queries to produce the xml output from the postgres apt/nav.dat database available for public somewhere? Cheers, Yves -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
On Tue, Apr 24, 2012 at 10:09 PM, Stuart Buchanan wrote: The initial commit of the random buildings is now available in git. One thing I forgot to mention: you need to be running with data/materials/default/materials.xml or data/materials/dds/materials.xml. The data/materials[-dds],xml are obselete and will be removed shortly. -Stuart Hi Stuart Maybe this is the point now to change something in scenery creation process? AFAIK towns are still (?) point features ... maybe this could be switched now to polygon features, using random buildings code later instead of this unique village models ? What do you think about towns and random buildings ? Cheers, Yves -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding Airports
Hi John Are this strips/fields missing in apt.dat 810 and 850 ? Do this strips have a FAA code or is it outside U.S. ? Cheers, Yves - Ursprüngliche Nachricht - Von: FlightGear developers discussions An: Cc: Gesendet:Fri, 13 Apr 2012 08:23:54 -0700 (PDT) Betreff:[Flightgear-devel] Adding Airports I have made a couple airports which are not in the airport database in the 8.10 format in TaxiDraw. Before anyone tells me about 8.50 these airports are nothing more than missing grass/dirt airstrips. What is the best way to add them to apt.dat, so I might be able to use Terragear with these airstrips included? Thanks John -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] updates to nav.dat.gz
Hi Crhis, Torsten What is really needed at the moment is someone starting to verify if some changes to our apt.dat from the past have to come to recent apt.dat shipped with FlightGear. Martin Spott prepared an updated apt.dat on the mapserver, but the changes in there have to be verified if its worth to commit this to Robin Peels database first. Some airports have probably better or more improvements in flightgear apt.dat version (i.e. taxiways). There are ~250 airports to check (see the link posted in my former post). In this case it would make sense to unpack apt.dat, too, as many changes need to be done to the two files (ILS changes i.e.) Chris, you mean nav.dat here, do you? The central repository would be Robin Peels xplane database, which still contains nav.dat files compatible with FG. BUT as they depend on a certain apt.dat version we can't just copy them over as a whole. In the future, when our scenery is created with apt.dat 850 data, we still have to keep one apt.dat file, as it has to match the distributed scenery. Isnt it possible to commit flightgear apt.dat/nav.dat changes directly to Robin Peel/xplane database, without serving an own apt.dat and spreading derivatives? This caused a lot of problems the last years I guess. I.e. there was never a proper solution what happens to changes made by flightgear contributors. It would be so much easier to have ONE apt.dat/nav.dat source, maybe someone can contact Robin Peel to get a shared flightgear/xplane repository? Cheers, Yves Cheers, Yves -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] updates to nav.dat.gz
Hi Chris (Sorry for my quick writings and mispelling and other mistakes) Maybe it’s time to establish a new contact to Robin Peel. I sent him data too but never got any answer, I sent my data to Martin Spott and the airports have never been updated, nore in apt.dat shipped with flightgear nore in scenery files derived via terrasync. Maybe it is time that apt.dat updates coming from flightgear gets a new conception now. Someone or a team has to establish a heard connection to Robin Peel. I could imagine that Robin Peel didn’t follow our updates anymore because it hooked on old 810 data, which is not updated for xplane anymore. - Ursprüngliche Nachricht - Von: FlightGear developers discussions An:FlightGear developers discussions Cc: Gesendet:Tue, 10 Apr 2012 10:15:03 +0200 Betreff:Re: [Flightgear-devel] updates to nav.dat.gz flightg...@sablonier.ch wrote: Hi Crhis, Torsten What is really needed at the moment is someone starting to verify if some changes to our apt.dat from the past have to come to recent apt.dat shipped with FlightGear. Martin Spott prepared an updated apt.dat on the mapserver, but the changes in there have to be verified if its worth to commit this to Robin Peels database first. Some airports have probably better or more improvements in flightgear apt.dat version (i.e. taxiways). There are ~250 airports to check (see the link posted in my former post). I'm already doing the checks (and modifications) for the german airports on the list. Those will be sent to Robin. In this case it would make sense to unpack apt.dat, too, as many changes need to be done to the two files (ILS changes i.e.) Chris, you mean nav.dat here, do you? I mean both files here. EDDF recently got a new runway and as such the namig scheme has changed completely. So I would like to change the runway names in apt.dat and the ILS data in nav.dat :) Is it more recent than what shows up in current 850 xplane data? Maybe this is a good point to show xplane data contributors that our updates have some value too :-) Isnt it possible to commit flightgear apt.dat/nav.dat changes directly to Robin Peel/xplane database, without serving an own apt.dat and spreading derivatives? This caused a lot of problems the last years I guess. I.e. there was never a proper solution what happens to changes made by flightgear contributors. It would be so much easier to have ONE apt.dat/nav.dat source, maybe someone can contact Robin Peel to get a shared flightgear/xplane repository? It IS generally (almost always) the best, to send changes directly to Robin. As I stated above, I didn’t see any change in our scenery work coming to Robin Peels database. I don’t know the reason exactly. Outdated data as base might be one, but that’s probably only my personal assumption. Our problem here is that we can't just update our apt.dat file with a newer version from Robin, as long as our scenery does not get rebuilt. What Torsten probably envisions with his proposal is the possibility of easier hotfixes for our files. For my point of view that’s exactly the path we have to leave. No more hotfixes which gives us imperative to a own apt.dat version. Instead of such fixes it would be nice to improve flightgear to read single custom airports like xplane does. With xplane you can load one improved airport from a custom data location and you go with this data. Again, we can't just update our apt.dat file with the latest version from xplane, as our scenery was created with a certain apt.dat file and thus depends on the corresponding file. Otherwise we'd have inconsistencies between i.e. FG's apt database and the runways showing up in our scenery. Xplane in contrast creates all airports on the fly, when loading the scenery, so they can switch apt.dat files without bigger problems. I don’t understand this concept: FlightGear distributes a static data file and on the other hand dynamically updated (scenery) data via terrasync or trough other sources. This will never be in sync unless flightgear has capability to read custom airport data or to update apt.dat via sync process too. For my point of view it’s anyway an overhauled concept of distributing static world data. Maybe someone can explain me more here, sorry for all my misunderstandment. I aplogize in advance, but I’m trying to follow this apt.dat and scenery process since many years but I definitely don’t get it probably ... Cheers, Yves -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] updates to nav.dat.gz
flightg...@sablonier.ch wrote: Maybe it???s time to establish a new contact to Robin Peel. I sent him data too but never got any answer, I sent my data to Martin Spott and the airports have never been updated, nore in apt.dat shipped with flightgear nore in scenery files derived via terrasync. Just as a clarification to everyone: The XML files on TerraSync are meant to represent the actual Scenery provided at this very place (TerraSync). Thus, introducing new airfield layouts/references without changing the corresponding terrain would lead to inconsistencies - which is why I refrained from doing so. Read also: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17407.html Hi Martin I know about this inconsistencies, and this of course the core of the problem. When flightgear reads from one updated scenery source and from one corresponding data source we wont run into the same problems anymore, do we? The old concept caused a (unwanted) freezing of scenery and apt.dat work over the last three years. You asked people to send you new scenery data/resources and airport data, but nothing happens with this data now, because you decided not to provide scenery anymore. One of the consequences of this decision could be for us to think about the whole scenery data process, and not to establish quickly the next hotfix. But this is only my personal view of things of course and is not well discussed. The same applies to shipping modified apt.dat files with the Base Package as long as use-custom-scenery-data flag wasn't established as default. Why is apt.dat/nav.dat (which covers the whole world and has some tons of MB) shipped with the base package, and not an updatable excerpt? And another question, wouldnt it be possible to establish an apt.dat online update in general? Why is it possible to update apt. and nav.dat in xplane every months without (?) inconsistencies and not for FlightGear? Is there something that could be changed in the concept of scenery and data distribution for FlightGear? Maybe leaving the world scenery approach and dividing scenery and data distribution into data regions? Therefore I've been collecting the various contributions just for the purpose of saving valuable work from bit-rot. Yes, this is a honorable work you did over the last years. I will start to compare newer xplane data with all changes made by flightgear contributors on old data. This will take some time, maybe this will take 2-3 months. Every help is much appreciated, also some hints where to start (Europe because of upcoming scenery updates?). Cheers, Yves -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Willfully violating Google Terms of Use under the FlightGear umbrella ?
Considering the same legal issues arise frequently, would you mind posting a link to the discussion, because all I can find is this: http://wiki.flightgear.org/index.php/Copyright_Inquiry And in a quick response to the second question, your scenery would be more detailed if you built it using SRTM-3 and CORINE data. Just to add a note, building scenery with corine could probably be more detailed, but we will never be aware of the well known inconsistency corine has, whith each data cycle. You will find some papers about this. The give an example: we have a much more detailed classification system for Switzerland. Now this has been translated to corine, I guess - no, I'm sure - there are some compromises in classification. And this discussion you will find for every corine member probably. Now maybe when someone is looking to an area he/she knows very well, this inconstistency is noticable quickly. But from another point of view ... for the huge task to get more detailed scenery at europe overall the inconsistency doesnt matter that much. For me its imaginable to have more detailed custom scenery for distinct areas, digitized from scratch or using corine as a base and improving. Depends on resources. But first corine and other public sources have to be verified properly of course, and anyway wider experience using this layers for scenery creation is needed. Another question would be if it really makes sense to have more detailed and improved resources than corine for FlightGear scenery creation at all, or if this is more an interesting side project and somehow overstating the case. BTW. Im wondering why no one uses the new flightgear-scenery mailing list for such discussion? Does it need more promotion? Cheers, Yves -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Looking at a nice project from outside
I really hope that we can start a discussion now about the state of the scenery and making (or following) some plans keeping the basic ideas up for the moment, also looking to planned improvements. I am following Martins ideas since a long time. I always tried to help here and there but I saw that it really needs a lot of people following this ideas. Martin spent so much time explaining me how to set up this and that and how all this scenery process could work. I really wish we could build some kind of temporary Scenery Team and discuss ideas. My proposal is to meet at IRC on day the next weeks to start organizing, or to open a temporary group or list. (Sorry, i do not like the forum for such). Personally- ... Martin, I would send you all my best wishes and I would send you one billion Thank Yous for all your support. Without you I would never have seen what is behind the whole scenery process. You spent so much time explaining me how this all works, you shared your experience and all the results of your researches in idealistic way and you guided me through the jungle. You always studied all proposals carefully. I ever got an answer from you. All my respect. Cheers, Yves - Ursprüngliche Nachricht --- Von: FlightGear developers discussions @lists.sourceforge.net An: Cc: Gesendet:Fri, 24 Feb 2012 10:01:16 + (UTC) Betreff:Re: [Flightgear-devel] Looking at a nice project from outside Pedro Morgan wrote: On Thu, Feb 23, 2012 at 10:21 PM, Martin Spott wrote: In the mid of the last decade I've been one of those who realized that developing a long-term strategy for the various FlightGear Scenery ressources would be a Really Good Idea. Meanwhile there's been progress to make such a strategy happen, anyhow, as usual, the groundwork doesn't have much of a shiny surface, it doesn't have eye-candy. Martin, am right with you.. I understand.. its a php site.. and its on a server and your dont want it to go wrong.. Pedro, the ground work I'm talking about is not the visible web site, it's the infrastructure behind these web pages: Man-months of research and tests in GIS land, building and testing tools, building and maintaining the database, shaping all the data into its current form and loading it into the DB, researching and testing how to build detailed airport layouts with TerraGear, the same with OSM roads, ensuring a certain quality level for the land cover data as well as for the Scenemodels repository and so on. Just to mention one symptomatical example: It's really weird doing a lot of research and tests, investigating licenses, compatibility issues and the like - and to realize months or years later that others, who don't care at all about these implications, are gaining laurels. After you've gone through this sort of a story more than twice, then you're finally going to ask yourself if there's any sense in what you're trying to achieve. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel .sp...@mgras.net@lists.sourceforge.net -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.6.0 for Mac - call for detail bug info known issues
(and I also want someone to give me a Mac that reproduces #7 :-p). Here. Cheers, Yves -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Final 2.6.0 Release Preparations
3. We need a short official announcement to be sent out to press, fs websites, newstickers, CBS, NBC, al-Arabia, ITAR-TASS et al. I'd prefer a native English speaker to write on or two enthusiastic paragraphs about FlightGear 2.6.0. For my point of view it is worth to put some effort in recent announcement. I guess we will see a campaign the next weeks for MS Flight (released end of february) ? I noticed articles in Newspapers here today about non-foss sim products MS Flight/X-Plane/Aerofly FS, and -unfortunately- as often, FlightGear as open source alternative is missing. I could also need a german and probably french translation of the announcement and some official screens, to place everywhere I can :-) Ok, it is not CNN/NBC or whatever here, but sometimes it is also worth to look out for smaller local newspapers and channels. Cheers, Yves -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Final 2.6.0 Release Preparations
The FlightGear development team is happy to announce the v2.6.0 release of FlightGear, the free, open-source flight simulator. This new version contains many exciting new features, enhancements and bugfixes. Major improvements from v2.4.0 include reduced AI aircraft load times, easier graphics tuning, more sophisticated AI aircraft and improved usability. Hi Stuart Does a new user (or other people not familiar with FlightGear but with other sims) know what AI stands for? Is it probably better to have AI improvements in more universal terms like easier graphics tuning or improved usability? (Just a thought, not important, many thanks for preparing this!). -Yves -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue 57 in flightgear-bugs: Font selection in ATC
Comment #2 on issue 57 by pedromorgan: Font selection in ATC http://code.google.com/p/flightgear-bugs/issues/detail?id=57 Why are there font in flightgear? cant it use local fonts ? -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue 58 in flightgear-bugs: New Joystick configuration: SpeedLink SL-6640 Black Widow Flight Stick
Updates: Labels: joystick Comment #2 on issue 58 by pedromorgan: New Joystick configuration: SpeedLink SL-6640 Black Widow Flight Stick http://code.google.com/p/flightgear-bugs/issues/detail?id=58 (No comment was entered for this change.) -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Please add Matekane Air strip, Matekane.dat included
Hi, I submitted Matekane Air strip to Robin Peels database today. But It takes a while for Robin to get and process email and much longer to get apt in fgfs updated from master. So I was hoping to get it in fgfs quicker by going this route as well. I have attached a text file Matekane.dat. Here is the original fgfs forum thread... http://www.flightgear.org/forums/viewtopic.php?f=5t=3293 http://en.wikipedia.org/wiki/Matekane_Air_Strip The fgfs forum user statto deserves credit for fake code. I fg-torrents created the strip using latest cvs of TaxiDraw. Just in case this list don't take attachments dat file below... ###start of dat file I 810 Version. Created with TaxiDraw 0.3.2 1 7544 0 0 FX01 Matekane Air strip 10 -29.928290 27.846140 56.140 1312 . . 42 11 01 0 1 0.25 0 . 99 ###end of dat file Matekane.dat Description: application/extension-dat -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] some hopefully helpful gdb core debug output
hi, I am fg-torrents from the forums. I am trying to debug error in triangle intersect problem. Original thread here: http://www.flightgear.org/forums/viewtopic.php?f=2t=2824 I keep running into what looks like other issues causing fg to crash before triangle intersect occurs. I updated all my src today and am following the instructions provided by jester in the forum thread. So after applying the patch provided by jester and doing export FG_SIGFPE=1 then ulimit -c unlimited, I got something about jsbsim ftank or something, you can look at the thread. Now after todays src update I get the following output: (for reference ./configure --prefix=/home/user/fg-debug CFLAGS=-O0 -g CXXFLAGS=-O0 -g) $gdb fgfs core.24650 Core was generated by `./fgfs'. Program terminated with signal 8, Arithmetic exception. [New process 24650] [New process 24652] [New process 24653] [New process 24651] #0 0x00873b02 in Tape (this=0xb2b00f0, hud=0x87bd9f0, n=0xb2a27a0, x=320, y=240) at HUD_tape.cxx:67 67 _odd_type = int(floorf(_input.max() + 0.5)) 1 ? true : false; (gdb) bt #0 0x00873b02 in Tape (this=0xb2b00f0, hud=0x87bd9f0, n=0xb2a27a0, x=320, y=240) at HUD_tape.cxx:67 #1 0x00868a50 in HUD::load (this=0x87bd9f0, file=0x125c040 Huds/NTPS.xml, x=320, y=240, level=0, inde...@0x7fff069b3610) at HUD.cxx:387 #2 0x00869ddd in HUD::init (this=0x87bd9f0) at HUD.cxx:137 #3 0x00ac88f8 in SGSubsystemGroup::init () #4 0x00ac88f8 in SGSubsystemGroup::init () #5 0x004469e0 in fgInitSubsystems () at fg_init.cxx:1682 #6 0x0042bf82 in fgIdleFunction () at main.cxx:928 #7 0x00486dc8 in fgOSMainLoop () at fg_os_osgviewer.cxx:177 #8 0x0042a388 in fgMainInit (argc=1, argv=0x7fff069b3e68) at main.cxx:1073 #9 0x0042981e in main (argc=1, argv=0x7fff069b3e68) at bootstrap.cxx:177 -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] some HUD_tape.cxx gdb core debug output
--- On Fri, 2/6/09, Tim Moore timo...@redhat.com wrote: From: Tim Moore timo...@redhat.com Subject: Re: [Flightgear-devel] some hopefully helpful gdb core debug output To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Date: Friday, February 6, 2009, 3:12 PM FlightGear wrote: hi, I am fg-torrents from the forums. I am trying to debug error in triangle intersect problem. Original thread here: http://www.flightgear.org/forums/viewtopic.php?f=2t=2824 I keep running into what looks like other issues causing fg to crash before triangle intersect occurs. I updated all my src today and am following the instructions provided by jester in the forum thread. So after applying the patch provided by jester and doing export FG_SIGFPE=1 then ulimit -c unlimited, I got something about jsbsim ftank or something, you can look at the thread. Now after todays src update I get the following output: (for reference ./configure --prefix=/home/user/fg-debug CFLAGS=-O0 -g CXXFLAGS=-O0 -g) This is a bit like whack-a-mole, but try again with the latest CVS or git version. When you send gdb output, it's helpful to know how you started the program and any interesting variable values. For instance, it would be helpful to know the value of _input.max() below. Tim I just started fg with ./fgfs and I don't know how to obtain the value of _input.max(). I also use a .fgfsrc file if thats of any importance. Fixed the subject line. fg-torrents -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Warning: Picked up error in TriangleIntersect freezes fg
Dear developers, since changing to osg I get this awful warning message in my DOS-box after having started fg some minutes ago like Warning:: Picked up error in TriangleIntersect (-1.81147 0.476811 -0.118829, -1.78078 0.471588 -0.0661082, -1.79068 0.886959 -0.0813922) (1.#QNAN, 1.#QNAN, 1.#QNAN) Warning:: Picked up error in TriangleIntersect (-1.79068 0.886959 -0.0813922, -1.78078 0.471588 -0.0661082, -1.78498 And like Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..) -1.#IND -1.#IND -1.#IND -1.#IND -1.#IND -1.#IND segment ignored.. Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..) -1.#IND -1.#IND -1.#IND -1.#IND -1.#IND -1.#IND segment ignored.. OS: WIndows XP The screen freezes while displaying these messages in the DOS-box for hours. I always have to restart fg to get rid. But problem returns some minutes later once again. An exteremely annoying effect. I wasn't able to connect the appearance of this effect with any actions. It seems to appear statistically. I did not know what kind of information about my system is needed to encircle the problem. I tried to get some help in the fg-forum (general help), first, but it seems to be a challange for basic binary code. The problem persists still today with whatever binary I used until now: I use this binary at the moment fgrun+fgfs-osg-win32-20081202.zip It seems that the error occors more often in mountain area. Can anybody help about this effect? I Tried to get solutions from the osg develop-list but my skills in computer hacking are to small to try their proposals for a solution. I don't know which information I should provide for encircling the problem. Hope you are interested in my problems because in this bad state it is no fun at all running fg. Thanks for your help! Jaques - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Not found simgear/structure/ssgSharedPtr.hxx
Curtis Olson ?: On 12/21/06, *Aleksey Y. Ulasevich (STAKANOV)* wrote: Curtis Olson ?: On 12/21/06, *Aleksey Y. Ulasevich (STAKANOV)* wrote: When I try to compile FGFS from CVS I see it: ... Making all in Aircraft make[2]: Entering directory `/home/pilot/FlightGear-0.9/source/src/Aircraft' if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/local/include -I/usr/X11R6/include -g -O2 -D_REENTRANT -MT aircraft.o -MD -MP -MF .deps/aircraft.Tpo -c -o aircraft.o aircraft.cxx; \ then mv -f .deps/aircraft.Tpo .deps/aircraft.Po; else rm -f .deps/aircraft.Tpo; exit 1; fi In file included from aircraft.cxx:44: ../../src/Model/acmodel.hxx:20:46: simgear/structure/ssgSharedPtr.hxx: No such file or directory In file included from aircraft.cxx :44: ../../src/Model/acmodel.hxx:47: error: ISO C++ forbids declaration of `ssgSharedPtr' with no type ... Slackware 11.0 SimGear 0.3 installed from CVS and I don't see simgear/structure/ssgSharedPtr.hxx in /usr/local/include: [EMAIL PROTECTED]:/usr/local/include/simgear/structure# ls callback.hxx event_mgr.hxx SGReferenced.hxx subsystem_mgr.hxx commands.hxx exception.hxx SGSharedPtr.hxx I read http://www.simgear.org/cvs.html and install SimGear from CVS. May be I read wrong instruction? That's right, but make sure you don't have additional versions of simgear floating around on your system that are being found instead of the CVS version. I deinstall slackware package SimGear and them install SimGear from CVS. I don't have ssgSharedPtr.hxx in sources: [EMAIL PROTECTED]:~/SimGear-0.3/source$ cd simgear/structure/ [EMAIL PROTECTED]:~/SimGear-0.3/source/simgear/structure$ ls callback.hxx event_mgr.cxx exception.o SGReferenced.hxx commands.cxx event_mgr.hxx libsgstructure.a SGSharedPtr.hxx commands.hxx event_mgr.o Makefile subsystem_mgr.cxx commands.o exception.cxx Makefile.am subsystem_mgr.hxx CVS exception.hxx Makefile.in subsystem_mgr.o I remove my directory SimGear-0.3, then create new and do it: [EMAIL PROTECTED]:~/SimGear-0.3$ cvs -d :pserver:[EMAIL PROTECTED]:/var/cvs/SimGear-0.3 login Logging in to :pserver:[EMAIL PROTECTED]:2401/var/cvs/SimGear-0.3 CVS password: [EMAIL PROTECTED]:~/SimGear-0.3$ cvs -d :pserver:[EMAIL PROTECTED]:/var/cvs/SimGear-0.3 co source I see: cvs checkout: Updating source U source/.cvsignore U source/AUTHORS U source/COPYING U source/ChangeLog U source/Doxyfile ... U source/simgear/xml/xmlrole.h U source/simgear/xml/xmltok.c U source/simgear/xml/xmltok.h U source/simgear/xml/xmltok_impl.c U source/simgear/xml/xmltok_impl.h U source/simgear/xml/xmltok_ns.c cvs checkout: Updating source/src-libs And them: [EMAIL PROTECTED]:~/SimGear-0.3$ ls source/simgear/structure/ callback.hxx event_mgr.cxx Makefile.am subsystem_mgr.hxx commands.cxx event_mgr.hxx SGReferenced.hxx commands.hxx exception.cxx SGSharedPtr.hxx CVS exception.hxx subsystem_mgr.cxx No ssgSharedPtr.hxx I do: [EMAIL PROTECTED]:~/SimGear-0.3$ find . -name ssgSharedPtr.* - no result! I think, I don't have CVS version. How to recieve sources from CVS? Thank You :-) PS. Sorry for my English - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] two scenery ideas
I noticed this, too , since the landcover data actually has a large amount of landcovertypes that are currently ignored. So my question is: If somebody would brew up some new textures for these types, is there any reason for not using them? For example, if you have many textures in a scenery part, they take up alot of memory on the 3d card, wich could lead to worse performance. Concerning the plib - OSG debate: Wouldn't it make sence to open up a page on the wiki for that? This way people could layout their suggestions for a possible transformation and by this the developers could get an estimate on how much work it really would be to change. Also this could be discussed in more detail this way. The wrapper-class discussed some days ago might be a good start? Just my ideas :) Josh Babcock wrote: It would be nice if Terragear was able to this automatically, as an interim solution, if the landcover types were available in FGSD users could customise areas that they want. Is it hard to add landcover types? Are there any other issues that I'm not aware of? I don't think so, there are a lot in the raw datasets that are currently ignored just for lack of textures. The harder part would be to have terragear assign new ones on it's own based on the slope angle and the original landcover data in the raw dataset. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
