[Flightgear-devel] Frankfurt (EDDF) scenery SVN now available
Hi guys, As some of you might already know, we are working on improving the scenery of Germany. Right now we are 3 people and I want to announce the first preview of our work. It is currently only Frankfurt and its Airport, but you can expect more to come in the future. I would be happy to receive some feedback. The SVN branch is available at: http://www.ilovelinux.de/svn/fgfs-ffm/user/ Cheers, Chris - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frankfurt (EDDF) scenery SVN now available
till busch wrote: hi christian, sorry. that was my fault -- skimming instead of reading. the scenery looks very nice to me. i think i miss a building with a pyramid-shaped roof: messeturm?. (though my memory may not be the best, since i was in frankfurt only twice). cheers, -till Hi Till, yes, you are right. The current SVN branch is only a preview. We have more models which will be released when they are ready. You can expect much more to come, so update your working copy regularily! :-) I have been working on many of the Frankfurt skyscrapers and will release them as soon as I think they are worth it. However I am currently concentrating on improving the airport. Chris - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frankfurt (EDDF) scenery SVN now available
till busch wrote: hi, would you mind adding a .tar.gz or a zipfile for easier download? thanks, -till Hi, as the whole thing is still in alpha or at least beta state, I want to wait until it is more mature. You can download it just as simple with svn co http://www.ilovelinux.de/svn/fgfs-ffm/user/; and always keep up with all changes. Maybe this was unclear in my first posting. The URL is an SVN repository. HTH Chris - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frankfurt (EDDF) scenery SVN now available
Hi Gabor, first of all thank you for this very useful feedback. I have noticed only one minor issue so far with the buildings of Terminal 2DE and 1C. When you load AI traffic data and ground map for EDDF in FG you will see airplanes parking at wrong positions (behind the buildings of 1C, in the passenger bridges of 2DE.) I have AI traffic activated, but how do I make any AI planes park on the positions in your screenshots? Sorry. I'm still quite new to FG. This problem can come from two sources, the parking positions can be defined wrong, or the position or scale of the buildings can be wrong. Or both. :) If you used Google Earth, I don't think the positions are wrong. The dimensions of the buildings are correct as well (measured with Google Earth as well). I think the positioning is wrong, a fact that I didn't care about too much until now :-) What is your opinion? Can you check somehow if the buildings are placed at the right position? Is it hard to move the buildings to east parallel the longer side of Terminal2? That would be no big deal and is overdue. Would you please tell me how to get these planes on there parking positions for reference. Cheers, Chris - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frankfurt (EDDF) scenery SVN now available
Gabor Toth wrote: Hi Chris, extract the attached tarball into your data directory. You will also need the appropritate AI aircraft (LH 737, LH 747, LH A320 LH A333). They are available on Durk's site: http://www.xs4all.nl/~dtalsma/flightgear.html Regards, Gabor WOW! Thank you. That's a completely new experience for EDDF. Any reason why the EDDF AI is not yet included in the official CVS? I will fix the positions ASAP. Chris - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frankfurt (EDDF) scenery SVN now available
Hi everybody. The problem is mostly solved. The update is already in SVN. I'm still working on making the remaining gates more accurate. Cheers, Chris Gabor Toth wrote: Hi Chris, Let me express my appreciate to your wodwerful work. As I fly very often to EDDF (in FG and IRL as well), this airport become one of my favourites. I have noticed only one minor issue so far with the buildings of Terminal 2DE and 1C. When you load AI traffic data and ground map for EDDF in FG you will see airplanes parking at wrong positions (behind the buildings of 1C, in the passenger bridges of 2DE.) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frankfurt (EDDF) scenery SVN now available
Heiko Schulz wrote: Hi, as long we havn't the discussed feature - where will we able to download this Traffic-files? There are some in CVS, but I sometimes heard, that people did their own - would be grat if anyone can profit from. Cheers HHS I can offer to use my SVN for this. As there is already the structure for the Data directory it would be no problem to add an Ai subdir. Chris - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frankfurt (EDDF) scenery SVN now available
Hello, here is a short update: Today I went to EDDF to take some photos of as many buildings and things as possible, to be able to better create textures. Some of the results can already be seen in SVN. However, I have one problem: There is reconstruction going on on gate c/d and they built a new tower-like thing there. I also read there will be more A380 parkings. I was not able to take a detailed shot of this, so if anybody is able to provide me with some photos of that new construction, I'd be very greateful. Other pictures are welcome, too :-) Cheers, Chris - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frankfurt (EDDF) scenery SVN now available
Hi Gabor, This problem can come from two sources, the parking positions can be defined wrong, or the position or scale of the buildings can be wrong. Or both. :) Now with more and more parts of the terminals being added, I encounter more errors with the aircraft positions again (the big ones like 747 stand partly in the building). The gate in the middle (Gate B) has this problem. I don't say it's not my fault. As I put the buildings together and position them in relation to their neighbours, errors might add up. So I'm still working on correcting this. But to rule out any other error source I just want to know how precisely you defined the parking positions? Greetings Chris - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FG CVS ebuilds for Gentoo
Hi, I created some ebuilds for the CVS/SVN versions of FG, simgear andd OSG. It works as an overlay and can be downloaded via: svn co http://ilovelinux.de/svn/fgfs-gentoo; It runs on two machines here right now, without problems, so I tought I make them publically available. Cheers, Chris - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frankfurt (EDDF) scenery SVN now available
Heiko Schulz wrote: Hi, I had a look too on the airport, and it looks great. With AI-Traffic it looks real nice and realistic! But I noticed that the groundnetwork not match to the new Scenery 1.0.0 - that could maybe the problem. Cheers HHS Thank you. Yes, the ground network needs some work. Planes are starting on the grass on the right side of the runway. Are you working on this? Chris - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frankfurt (EDDF) scenery SVN now available
Hi, I just corrected the building positions once more and checked everything with Google Earth. The parking positions are ok for our current buildings. However, as I already wrote, there are some changes in reality to make room for the A380. These new gates are spread across the Terminals and I have not yet looked deeper into it. However: Positions D121, D111, D101 and D91 changed. There are only 3 positions left, in addition to a bigger reconstruction of the D building. Greetings Chris Gabor Toth wrote: Hi, Loading the attached file into Google Earth will show you the parking positions at EDDF. This way you can check if they are correct. Unfortunately I do not have too much time to redo the ground network, if any of you can do it, I'm more than pleased. :) My idea about the performace issue is to make it scalable by the user. I mean a slide bar or something in the AI menu. (eg. only every second, tenth whatever AI flight to activate) Regards, Gabor - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frankfurt (EDDF) scenery SVN now available
Hone more question: Is there a way to set maximum sizes for aircraft that are allowed on a particular parking position? That would solve the current problem of a 747 parking on at Gate B on a position not suitable for that size. Chris - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frankfurt (EDDF) scenery SVN now available
Heiko Schulz wrote: Yes, have a lok into the wiki: http://wiki.flightgear.org/flightgear_wiki/index.php?title=Interactive_Traffic Thanks for this hint. As soon as I get the NEW_GUI branch of Taxidraw finally working here, I will maybe take a look there. But I'm still modelling EDDF and it is makeing good progress, as some of you might notice. Cheers, Chris - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Res: segmentation fault
Cleber Santz wrote: Hi, I solve the problem with plib (removed v1.84 already instaled), but now i`m getting segmentation fault when run flightgear. I think the problem is with data (fg can`t find models) but i make checkout with the lastest data. I get 2 different dump, first with carrier enable so i disable carrier and get a another dump. I send the 2 segmentation fault, w/o carrier, in attached files. Any help ?? Best regards, Cleber Santz. Hi, I encountered something like this yesterday, too. I did not run the debugger, but going back to CVS from 14-Mar-08 made FG run again. Maybe you should try this, too. Cheers, Chris - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frankfurt (EDDF) scenery SVN now available
Christian Schmitt wrote: Hello, here is a short update: Today I went to EDDF to take some photos of as many buildings and things as possible, to be able to better create textures. Some of the results can already be seen in SVN. However, I have one problem: There is reconstruction going on on gate c/d and they built a new tower-like thing there. I also read there will be more A380 parkings. I was not able to take a detailed shot of this, so if anybody is able to provide me with some photos of that new construction, I'd be very greateful. Other pictures are welcome, too :-) Cheers, Chris I was lucky to find some pics of this new construction on the web. Together with a plan of EDDF i was able to more or less measure the sizes of the new Gate D and texture it. It is already in SVN. Cheers, Chris - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Segfault on current HEAD?
James Sleeman wrote: Am I the only one getting segfaults on a full compile of the latest HEAD or is it just not working at the moment. Full update and compile of everything, SimGear, OSG, Plib1.8.5, flightgear with --enable-osgviewer, and data all up to date. Segfaults as soon as it tries to display the splash screen (disabling the splash doesn't get much further). I can confirm this problem. I had to go back to OSG 2.3.4 and recompile flightgear and simgear, before it started working again. Maybe 2.3.5 works, too, but it didn't for me (forgot to recompile simgear). I don't want to make further tests right now, since it takes some hours on my machine. Cheers, Chris - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Segfault on current HEAD?
Tobias Ramforth wrote: Hi! Everytime. I'll try rolling back to an older OSG when I get a chance. Are you sure you recompiled every single lib using up-to-date sources (CVS/SVN)? I encountered a segfault, as well, but I forgot to recompile simgear. Double check the compilation order, too! Regards, Tobias Today I recompiled everything, starting with an update from OSG-2.3.4 to HEAD. After that recompiled simgear and flightgear. Now everything is working as it sould again and I have the impression that it is running faster and smoother again. Cheers, Chris - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] AI at the airport...
Hey Durk, Ralf just pointed me to you being the expert on AI/ATC and stuff like that, which is IMHO one of the most important things for a good user experience. :-) As you might know we are currently doing a lot of work on EDDF. One of the things I am doing right now is redesigning the AI-Network. AI Planes are starting and landing on two runways. The runway where they start is not a problem, but the landings are strange: The plane lands approx. in the middle of the runway length and brakes. Now, in real life I would suppose it to take the first taxiway available to leave the runway. Well, it doesn't. Instead it continues on the runway till it reaches the last possible exit, right at the end and takes it. Is this supposed to be normal behaviour? Another question: Should I use a rwyuse.xml file? I have currently one in use, but I don't like AI planes always taking the same end of the runway for starting and not putting winds into consideration. Well I hope you can help me here. Thanks. Chris - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AI at the airport...
Durk Talsma wrote: We are moving towards a more sophisticated runway exit strategy: Last year at LinuxTag, Thomas Foerster and I discussed the idea of adding a performance database that could be used to determine stopping distances, and I'm currently working on adding support for runway entrance/exit points. Ideally, I'd want taxidraw to set these automatically, but this is still on my TODO list. So does it mean that the On the runway points I set in taxidraw are currently of no use? Another issue I have is that setting a point as Cat II/II will lead to a segmentation fault on next FG startup. Cheers Chris - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] osg 2.4 released today
Melchior FRANZ wrote: And according to a past agreement, this means that everyone should from now on expect commits that require OSG 2.4 -- to add new features, and to remove old workarounds. Allright. I'll update the overlay :-) Cheers Chris - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft start up postion issue.
Markus Zojer wrote: Hi all! This issue still exists. The YASim FDM places the datum of the aircraft at the end of the runway as startup position, which means that all aircraft with datum=nose start behind the runway. Maybe we should use the CG of the aircraft as reference point or calculate some offset to the existing solution, as some airports are unusable. Thanks, Markus Hi, I recently talked to a guy who complained that some of the aircraft are also initially positioned too high above ground, which makes them fall down on start and in some cases crash. Cheers, Chris - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Some TV material from 3sat about Linuxtag 2008 AND Flightgear
Holger Wirtz wrote: Hi, last week Flightgear was represented at Linuxtag 2008 in Berlin, Germany. The TV station 3sat made some small trailers about Linux and OpenSource projects. I made an mpeg2 stream which shows some projects on this fair. At the end you can see some seconds of captain DT flying a 777 at EDDF :-) Great to see! Thanks a bunch! Chris - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT; Was: _Sport Model_
Frederic Bouvier wrote: Migrating from CVS to SVN would already be a very good thing IMO -Fred Sure enough. But if we take a migration into consideration, we sould probably go the GIT route. Although I'm not too experienced with git when it comes to committing things to it, from the git pull side, it looks pretty nice. I don't know however how it performs with binary data, which would be nice to know for flightgear-data. IMHO, the current solution as read-only is a good way to test it from one side and maybe later move more stuff to it. Cheers Chris - 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] GIT
Martin Spott wrote: The FlightGear project has been notoriously behind about getting people's source code contributions into CVS - for years. We all know the story, it's been the same for years already, no need to repeat it here. So, in order not to loose the respective contributions over the time, such a GIT repo - be it mine or someone else's - makes the perfect tool that allows contributors to maintain their changes in a local branch while still easily keeping them in sync with the main source tree(s). Thus, it will be highly beneficial for the FlightGear project as a whole to support these developers by backing an official GIT repo instead of letting their enthusiasm fade out in disappointment Guess why there are there so many private GIT repositories containing modified versions of FlightGear source trees !? Please think of it and keep up with the times. Ah, great to hear this from you, Martin. This does BTW not only apply to the FG source code, but also to the scenery and flightplans... ;-) Chris - 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] GIT
Martin Spott wrote: I was persuaded to mention that GIT allows you to wrap single steps of your private development into independent commits to your local repository, even if you don't have any network access while sitting at the beach on a remote island Once you're back to a place where you have network access, you're easily - without having to deal with a collection of individual patch files - going to push all the accumulated changes at once but still retaining the granularity of the individual steps. ... which is IMHO one of the most interesting and useful features of GIT for FG development, but also for scenery stuff. SVN is lacking such functionality. Chris - 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] GIT
Melchior FRANZ wrote: * Melchior FRANZ -- 8/26/2008 3:03 PM: But it would make me a bit nervous if an aircraft developer commits several pointless updates of 5MB sound files. GIT can't compress that. We'd collect the whole pile on our disks. How much would disk space requirements grow each year? Bah, I just saw a rather cheap 1TB disk offered in the ads of a shop that focuses on books, music CDs and paper stuff. I guess that a few MB more aren't really an issue nowadays. Hereby I withdraw the above consideration. So what's left as an argument against switching to GIT right away? That's after some more discussions and tests, of course. :-) And by the way: an SVN checkout keeps two copies of every single file. And for most files that copy takes about as much disk space as the *whole* history of that file in GIT, which includes all file revisions! (IIRC) I just tested the fg GIT server and checked out fgdata, which is quite a piece of stuff. It took some time, but that's normal for the first checkout and not different to CVS. The interesting thing is running du -c after the checkout on both different dirs: CVS: 1696167 total git: 1043121 total Which clearly shows how efficient git works even with binary files and considering that this copy contains all the changes, as Melchior already stated. - 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] GIT
Thomas wrote: Thanks for that review. I'm still wary of the auto line term conversion and would probably favor disabling it. I'm more concerned about the 2 GB repo size limit listed in the Known issues in the release notes. I don't think that will work for FG. Am I correct in assuming that Git under CygWin does not have that limitation? Anyone here tried it? As I already wrote here yesterday, the fgdata repo needs currently approx 1GB of diskspace on my machine here. I don't know if msysGit counts this a bit differently, but for the forseeable future, we should be save in this regard, as fgdata is AFAIK the biggest repo we have. Chris - 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] GIT
Stefan C. Müller wrote: That's of course the safest choise for binary files. But it would certainly mess up the text files. While most windows tools can read LF, they all write CRLF by default, some even to automatic conversion (like VC). We would end up having files of both types (and files with a mix inside) in the repository. And then we get trouble with all the linux tools not able to handle CRLF... Huh? From my experience it is more the other way around. I saw many Windows tool that displayed LF fext incorrectly but I have never seen a CRLF text in Linux being messed up. What exactly do you mean by all the linux tools? Cheers Chris - 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
[Flightgear-devel] Concorde VL autopilot problem
Hi everybody, I recently started flying the Concorde intensively. There seems to be a problem with the VL (VOR lock) autopilot. It sould follow a radial towards/from a VOR, which it does, but it is not steering towards the radial fast enough. The angle towards the radial is too small. This often leads to getting off course and passing a VOR several miles away, instead of crossing it. I hope I could describe the problem properly. It would be great if the anonymous author of the concorde could take a look into it. Thanks Chris PS: What a nicely modelled plane :) - 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] [Flightgear-cvslogs] CVS: data/Aircraft/b1900d b1900d-set.xml, 1.32,
Heiko Schulz wrote: The last errors I had were: -Bank-Angle-Callouts with real zero-angle after lift off or shortly above rwy while landing. - the callouts 50 40 30 20 10 could be never heard at all- even with a very low sink rate Low-Terrain-warning on a corrct ILS-glidepath Hello, I just want to confirm this. Especially the bank angle right after takeoff is a common issue. I encounter it in the Citation Bravo. Did not take care on the callouts, but the low terrain warning although perfectly on a 3° glidepath are happening here, too. If i'm not mistaken as well on the Bravo. Cheers, Chris - 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] Call for aircraft nominations
Durk Talsma wrote: While I'm at it. :-) With each release we include a selection of representative aircraft that highlight FlightGear's capabilities. Inclusion criteria include: Completeness, variability across categories, realism, suitability for demo flights (think of aerotowing, AI/Multiplayer refueling, carrier landing, etc etc.), relative ease of operation (ie don't want to intimidate new users too much), and disk space (we don't want to bloat the base package too much). So, with these criteria in mind, what would be your current top 10 of aircraft? Hi Durk, I clearly vote for the Concorde here. It is not the easiest plane when it comes to all its functions that are implemented (complete engineers seat with a million of buttons ;-), but exactly a model like this shows what is possible with FG. And the player can always automate Copilot and Engineers tasks via a menu and thus concentrate on flying. Cheers, Chris - 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
[Flightgear-devel] fgrun --as-needed configure/compile problem
Hi, I'm currently working on improving my Gentoo overlay for FG and added a live version of fgrun to it. There is a problem to compile it with --as-needed enabled as LDFLAGS. During configure it already prints: checking for gl_start in -lfltk_gl... no which leads to a compile error later on: mv -f .deps/main.Tpo .deps/main.Po mv -f .deps/run_posix.Tpo .deps/run_posix.Po mv -f .deps/wizard_funcs.Tpo .deps/wizard_funcs.Po x86_64-pc-linux-gnu-g++ -DLOCALEDIR=\/usr/games/share/locale\ - march=amdfam10 -O2 -pipe -L/usr/lib64/fltk-1.1 -Wl,--as-needed - L/usr/games/lib -lfltk -lpthread -ldl -lm -lXext -lX11 -Wl,--as-needed - L/usr/games/lib -o fgrun wizard.o wizard_funcs.o advanced.o advanced_funcs.o AirportBrowser.o AirportTable.o Fl_Table.o Fl_Table_Row.o Fl_OSG.o Fl_Heading_Dial.o main.o io.o fgfsrc.o logwin.o parkingloader.o settings.o util.o run_posix.o fgrun_pty.o -lsgmodel -lsgscreen -lsgprops -lsgxml - lsgdebug -lsgbvh -lsgmaterial -lsgmodel -lsgutil -lsgstructure -lsgprops - lsgtgdb -lsgmath -lsgmisc -lsgbvh -lsgio -lsgbucket -lsgmodel -lsgutil - lplibsg -lplibul -lplibnet -losgParticle -losgSim -losgViewer -losgGA - losgText -losgDB -losgUtil -losg -lOpenThreads -lpthread -lfltk -lXft -lGL - lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lm -lz -lutil -losgFX wizard_funcs.o: In function `Wizard::preview_aircraft()': wizard_funcs.cxx:(.text+0x6c0d): undefined reference to `Fl_Gl_Window::make_current()' wizard_funcs.o: In function `Wizard::reset_settings()': wizard_funcs.cxx:(.text+0xab25): undefined reference to `Fl_Gl_Window::make_current()' Fl_OSG.o: In function `AdapterWidget::AdapterWidget(int, int, int, int, char const*)': Fl_OSG.cxx:(.text+0x5c8): undefined reference to `vtable for Fl_Gl_Window' Fl_OSG.cxx:(.text+0x5d0): undefined reference to `Fl_Gl_Window::init()' Fl_OSG.cxx:(.text+0x954): undefined reference to `Fl_Gl_Window::~Fl_Gl_Window()' Fl_OSG.o: In function `AdapterWidget::AdapterWidget(int, int, int, int, char const*)': Fl_OSG.cxx:(.text+0xe68): undefined reference to `vtable for Fl_Gl_Window' Fl_OSG.cxx:(.text+0xe70): undefined reference to `Fl_Gl_Window::init()' Fl_OSG.cxx:(.text+0x11f4): undefined reference to `Fl_Gl_Window::~Fl_Gl_Window()' Fl_OSG.o: In function `AdapterWidget::resize(int, int, int, int)': Fl_OSG.cxx:(.text+0x1ac): undefined reference to `Fl_Gl_Window::resize(int, int, int, int)' Fl_OSG.o: In function `AdapterWidget::~AdapterWidget()': Fl_OSG.cxx: (.text._ZN13AdapterWidgetD2Ev[AdapterWidget::~AdapterWidget()]+0x79): undefined reference to `Fl_Gl_Window::~Fl_Gl_Window()' Fl_OSG.cxx: (.text._ZN13AdapterWidgetD2Ev[AdapterWidget::~AdapterWidget()]+0x42): undefined reference to `Fl_Gl_Window::~Fl_Gl_Window()' Fl_OSG.o: In function `AdapterWidget::~AdapterWidget()': Fl_OSG.cxx: (.text._ZN13AdapterWidgetD0Ev[AdapterWidget::~AdapterWidget()]+0x3c): undefined reference to
[Flightgear-devel] Concorde changes (merge request)
Hi, to make sure the anonymous original author is ok with the changes, I want to announce here a merge request concerning the Concorde and ask for a review/testing and a merge. http://gitorious.org/fg/fgdata/merge_requests/15 Cheers, Chris -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simple atmospheric scattering shader for skydome
Erik Hofman wrote: I'm not sure, it needs time to look after some things. For one it should be made possible for the shader to adjust the fog color located under /rendering/fog but at this time values written to it will be overwritten by the current code. Erik I can only agee with Vivian here: lets get this change into GIT, so that it doesn't get lost as so many others in the past. The shader is not perfect yet, but that should not hurt, as it is disabled as a default. Those who want to test and improve it are free to do so. Let me add that it's good to have people who work on things like shaders (we need every single one of them). Chris papillon81 -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG visualization question
Durk Talsma wrote: Hi All, As part of visualizing the AI ground networks from within FlightGear, I've been trying to find out whether there is a simple way of drawing them using a few OSG commands. As a start, for each of the segments, I have a start and end position in latitude / longitude coordinates, and I would like to start by drawing a simple line between those, using an OSG equivalent of OpenGL drawing primitives. After staring at the code for some time, I haven't really been able to determine how this should be done, so any ideas would be welcome. Although I have no solution for this, it might be worth noting that finding something to implement this, might also be useful to generate REAL centerlines for our taxiways and maybe even more... Cheers Chris -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] terragear-cs unknown runway surface/ segfault
Hello, i have recently created many bigger scenery chunks with Corine Landcover and OSM line data. Yesterday I wanted to do the same for all of the UK and Ireland. Then I encountered some problems: I encountered unknown runway surface errors, caused by some strange heliport runways (see EGTG). I created a patch to circumvent this for now: https://gitorious.org/papillon81/terragear- cs/commit/263a1cdd537bd07e2d5a503b38043f8faee29e38 After that genapts segfaulted during EGKK processing and right until now I have still not much of a clue what exactly is going on. I thought it was a problem with compiling TG against SG and not SG-CS (all from GIT). That showed to be wrong. Next guess was overoptimization (-O2 and -march), yet unsetting this and recompiling did not solve it either. So I'm still investigating. A backtrace is attached. If you have any ideas i'd be glad. Cheers Chris Building EGKK Runway count = 2 Taxiway count = 241 w010n50/w001n51/2941771 18 51.154176 -000.183887 1 Light beacon 14 51.154176 -000.183887 130 0 Tower Viewpoint 19 51.145960 -000.211647 1 Windsock 19 51.150391 -000.167913 1 Windsock 19 51.150760 -000.179184 1 Windsock Building runway = 08R Forward displaced threshold = 1289 Reverse displaced threshold = 879 Runway num = '08' Forward displaced threshold = 1053 Reverse displaced threshold = 1365 Runway num = '08' Program received signal SIGSEGV, Segmentation fault. 0xb7fb8fdd in merge_left (p=0x814ba90, q=0x0, list=0x814bab0) at gpc.c:785 785 gpc.c: No such file or directory. in gpc.c (gdb) bt #0 0xb7fb8fdd in merge_left (p=0x814ba90, q=0x0, list=0x814bab0) at gpc.c:785 #1 0xb7fbae88 in gpc_polygon_clip (op=GPC_UNION, subj=0x8161fb8, clip=0x8151708, result=0x816ad60) at gpc.c:1383 #2 0x080a467a in polygon_clip(anonymous enum, const TGPolygon , const TGPolygon ) (poly_op=POLY_UNION, subject=..., clip=...) at polygon.cxx:385 #3 0x080a4a08 in tgPolygonUnion (subject=..., clip=...) at polygon.cxx:441 #4 0x0809ac50 in gen_taxiway (rwy_info=..., alt_m=25.29840087890625, material=..., rwy_polys=0xbfffdf7c, texparams=0xbfffdf70, accum=0xbfffd8c0) at taxiway.cxx:103 #5 0x08051ae0 in build_runway (rwy_info=..., alt_m=value optimized out, rwy_polys=value optimized out, texparams=value optimized out, accum=0xbfffd8c0, apt_base=0xbfffd908, apt_clearing=0xbfffd8e4) at build.cxx:300 #6 0x0805547a in build_airport (airport_id=..., alt_m=25.2984009, runways_raw=..., beacons_raw=..., towers_raw=..., windsocks_raw=..., root=..., elev_src=...) at build.cxx:614 #7 0x080860e9 in main (argc=4, argv=0xbfffed24) at main.cxx:340 -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs unknown runway surface/ segfault
Martin Spott wrote: After that genapts segfaulted during EGKK processing [...] Did you use the 'public' apt.dat file from MapServer ? Yes, indeed. I hope i'll be able to really get down to the problem today. I still have no exact clue what caused it, although I recompiled with several cflags settings yesterday. Chris -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs unknown runway surface/ segfault
Martin Spott wrote: http://mapserver.flightgear.org/Heliport.pl Well, I'd rather get it right in genapts and I'm sure it's not too difficult to accomplish. Chris -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Christian Schmitt wrote: After that genapts segfaulted during EGKK processing and right until now I have still not much of a clue what exactly is going on. I thought it was a problem with compiling TG against SG and not SG-CS (all from GIT). That showed to be wrong. Next guess was overoptimization (-O2 and -march), yet unsetting this and recompiling did not solve it either. After recompiling simgear and terragear multiple times with different cflags i guess I found out what is the problem: the use of sse/sse2 instructions by gcc. Here is a diff output of the internal GCC options between a non-working config and a working one: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1 #define __DBL_DENORM_MIN__ 4.9406564584124654e-324 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1 -#define __FLT_EVAL_METHOD__ 0 +#define __FLT_EVAL_METHOD__ 2 #define __unix__ 1 #define __DBL_MIN_10_EXP__ (-307) #define __FINITE_MATH_ONLY__ 0 @@ -51,7 +51,6 @@ #define __DEC32_MIN__ 1E-95DF #define __DBL_MAX_EXP__ 1024 #define __DEC128_EPSILON__ 1E-33DL -#define __SSE2_MATH__ 1 #define __LONG_LONG_MAX__ 9223372036854775807LL #define __SIZEOF_SIZE_T__ 4 #define __SIZEOF_WINT_T__ 4 @@ -73,7 +72,6 @@ #define __ELF__ 1 #define __FLT_RADIX__ 2 #define __LDBL_EPSILON__ 1.08420217248550443401e-19L -#define __SSE_MATH__ 1 #define __SIZEOF_PTRDIFF_T__ 4 #define __DEC32_SUBNORMAL_MIN__ 0.01E-95DF #define __FLT_HAS_QUIET_NAN__ 1 I encountered this problem on an Atom-based machine and an AMD Phenom machine. So, yes, I should probably change my cflags in this case. But given many distros that will ship this as binary package (compiled with SSE instructions enabled), the better way would be to fix it in the code. Chris -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Martin Spott wrote: -#define __FLT_EVAL_METHOD__ 0 +#define __FLT_EVAL_METHOD__ 2 I think a simple -O2 should be permitted. Does it still fail with setting just this single option ? The O2 flag was set for all tries but it's not the problem here. The problem are certain -march options. -march=core2 -mfpmath=sse for the Atom showed the error. Settung it to a more conservative -march=prescott makes it work. In this case it was a clear overoptimization. But there are other march settings like -march=amdfam10 for my Phenom which enable SSE. If I understand correctly, what you're calling a fix would be a workaround to circumvent a compiler/platform bug in my terminology. Right !? ;-) Correct. Are you running an appropriate kernel on your platform ? As far as I remember, the Atom processor series is just a slightly modified and shrinked down Pentium III processor. My kernel is allright. If not i'd run into other issues already. Note that it's only EGKK where this happens. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Arnt Karlsen wrote: ..who's code, F|S|TG, or GCC? Which gcc version(s) did you use here? Where the problem lies in the code I don't know. But it would be SG or TG. My GCC version is 4.4.5, OS is Gentoo. Debian has updated gcc-4.4 and gcc-4.6 yesterday and today, may be updating gcc-4.5 now if they didn't earlier this week, so it could well be the bug you've found, is being fixed, or has been fixed by now. As I never encountered segfaults like this I currently think it's a SG/TG issue that was undetected until now. This does not mean that something has to be fixed as it's very small and can be circumvented by disabling SSE in the Makefile. Chris -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Martin Spott wrote: Well, to be more precise, it's been optimization for an incompatible platfom ;-) The Core2 has a slightly different instruction set from the Pentium III, thus, if I were you, I'd let the 'native' compiler choose the right platform optimization for you - as long as you don't compile cross-platform. I can agree, it was surely not the 100% correct setting. But for my Phenom I still have no clue what to do. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Curtis Olson wrote: GIS on a global scale is a really really hard thing. There are tremendous challenges in terms of data set sizes, processing time, numerical representations, manipulating and crunching data, etc. Terrorgear is a clever play on words, but any one who is ready to dive in and create a better scenery system is more than welcome. The current system certainly has some limitations and I'd welcome updates that brought the system up to the next level of realism and polish ... or even replaced the current system entirely with something better. Sorry if I'm a little overly sensitive today to criticism ... even it it is wrapped in humor or cleverness... I can only agree with you here, Curt. Everyone who has worked with GIS data knows that it can become very complex and time consuming to process. That we get scenery, now even from more complex data (although with errors and artefacts at some places) can be considered as a miracle, given the amount of development time TG receives, compared to FG/SG. I also have to say that the sourcecode of TG is nicely documented (i'm a complete noob when it comes to C/C++ programming) and yet I somehow can follow the logic in the code. That's why I'd like do dive deeper into the airport code and see if I can do something there. Building a frontend (Qt-based) as Gijs did, is a nice endeavour, but I hope the backend will not be forgotten and the audience will not have too elevated expectations. Cheers Chris -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Csaba Halász wrote: It is certainly good advice to optimize for the correct processor, but using unsupported instructions typically result in a SIGILL not a SIGSEGV. It would help to see the actual disassembly around the fault and machine register contents. It smells like alignment problem. Hi Jester, I can get that for you, if you want. But what do you need? info registers? The whole coredump file? Cheers, Chris -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Csaba Halász wrote: Info registers, and something like x/10i $eip (or $rip on 64 bit) Here you go (still on Atom), Phenom this evening. (gdb) info registers eax0x0 0 ecx0xb7e67380 -1209633920 edx0x814aab0135572144 ebx0xb7fbfff4 -1208221708 esp0xbfffc4d8 0xbfffc4d8 ebp0xbfffc4e8 0xbfffc4e8 esi0x3 3 edi0xbfffc72c -1073756372 eip0xb7fb8fdd 0xb7fb8fdd merge_left+9 eflags 0x210286 [ PF SF IF RF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) x/10i $eip = 0xb7fb8fdd merge_left+9: mov0x14(%eax),%eax 0xb7fb8fe0 merge_left+12: movl $0x1,0x4(%eax) 0xb7fb8fe7 merge_left+19: mov0x8(%ebp),%eax 0xb7fb8fea merge_left+22: mov0x14(%eax),%edx 0xb7fb8fed merge_left+25: mov0xc(%ebp),%eax 0xb7fb8ff0 merge_left+28: mov0x14(%eax),%eax 0xb7fb8ff3 merge_left+31: cmp%eax,%edx 0xb7fb8ff5 merge_left+33: je 0xb7fb9058 merge_left+132 0xb7fb8ff7 merge_left+35: mov0x8(%ebp),%eax 0xb7fb8ffa merge_left+38: mov0x14(%eax),%eax Chris -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Christian Schmitt wrote: Here you go (still on Atom), Phenom this evening. Phenom: (gdb) bt #0 0x77bd4504 in merge_left (p=0x7c4f00, q=0x0, list=0x7c4f30) at gpc.c:785 #1 0x77bd6861 in gpc_polygon_clip (op=GPC_UNION, subj=0x747fb0, clip=0x770120, result=0x74edc0) at gpc.c:1383 #2 0x0045a3cb in polygon_clip (poly_op=POLY_UNION, subject=..., clip=...) at polygon.cxx:385 #3 0x0045a613 in tgPolygonUnion (subject=..., clip=...) at polygon.cxx:441 #4 0x0045337c in gen_taxiway (rwy_info=..., alt_m=25.29840087890625, material=..., rwy_polys=0x7fffb0b0, texparams=0x7fffb090, accum=0x7fffa180) at taxiway.cxx:103 #5 0x0040d61d in build_runway (rwy_info=..., alt_m=25.29840087890625, rwy_polys=0x7fffb0b0, texparams=0x7fffb090, accum=0x7fffa180, apt_base=0x7fffa220, apt_clearing=0x7fffa1d0) at build.cxx:300 #6 0x0040fbde in build_airport (airport_id=..., alt_m=25.2984009, runways_raw=..., beacons_raw=..., towers_raw=..., windsocks_raw=..., root=..., elev_src=...) at build.cxx:614 #7 0x00444623 in main (argc=4, argv=0x7fffda68) at main.cxx:340 (gdb) info registers rax0x0 0 rbx0x3 3 rcx0x0 0 rdx0x7c4f30 8146736 rsi0x0 0 rdi0x7c4f00 8146688 rbp0x7fff8430 0x7fff8430 rsp0x7fff8430 0x7fff8430 r8 0x7506b0 7669424 r9 0x3 3 r100x7720def0 140737339514608 r110x206518 ---Type return to continue, or q return to quit--- r120x405540 4216128 r130x7fffda60 140737488345696 r140x0 0 r150x0 0 rip0x77bd4504 0x77bd4504 merge_left+20 eflags 0x10206 [ PF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) x/10i $rip = 0x77bd4504 merge_left+20: mov0x20(%rax),%rax 0x77bd4508 merge_left+24: movl $0x1,0x4(%rax) 0x77bd450f merge_left+31: mov-0x18(%rbp),%rax 0x77bd4513 merge_left+35: mov0x20(%rax),%rdx 0x77bd4517 merge_left+39: mov-0x20(%rbp),%rax 0x77bd451b merge_left+43: mov0x20(%rax),%rax 0x77bd451f merge_left+47: cmp%rax,%rdx 0x77bd4522 merge_left+50: je 0x77bd45a1 merge_left+177 0x77bd4524 merge_left+52: mov-0x18(%rbp),%rax 0x77bd4528 merge_left+56: mov0x20(%rax),%rax -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Curtis Olson wrote: Right, as said before, you crashed inside the gpc code. Have you tried regenerating this airport using the --nudge option (increasing the value in small increments until you find a value that allows the airport to be successfully built.) Regards, Curt. Curt, it's not a question of finishing this build, it's a fact that something is broken and I'd like to do my best to help get it fixed. FYI: I found another, different segfault with EGKK: Starting program: /usr/bin/genapts --input=./EGKK.dat --work=./test Input file = ./EGKK.dat Terrain sources = ./test/SRTM2-Africa-3 ./test/SRTM2-Australia-3 ./test/SRTM2-Eurasia-3 ./test/SRTM2-Islands-3 ./test/SRTM2-North_America-3 ./test/SRTM2-South_America-3 ./test/DEM-USGS-3 ./test/SRTM-1 ./test/SRTM-3 ./test/SRTM-30 Work directory = ./test Nudge = 10 Longitude = -180:180 Latitude = -90:90 Data version = 810 Next airport = EGKK 196 End of file reached last_apt_id.length() = 4 Building EGKK Runway count = 0 Taxiway count = 1 w010n50/w001n51/2941771 Program received signal SIGSEGV, Segmentation fault. 0x0040fc55 in build_airport (airport_id=..., alt_m=0, runways_raw=..., beacons_raw=..., towers_raw=..., windsocks_raw=..., root=..., elev_src=...) at build.cxx:621 621 taxiways[i].generated = true; (gdb) bt #0 0x0040fc55 in build_airport (airport_id=..., alt_m=0, runways_raw=..., beacons_raw=..., towers_raw=..., windsocks_raw=..., root=..., elev_src=...) at build.cxx:621 #1 0x00444e15 in main (argc=3, argv=0x7fffda68) at main.cxx:442 Chris -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders flicker
David Glowsky wrote: Hi developers, I have a new computer, installed FG on it and have a problem with the graphics. The problem (beside missing runway lights) is that surfaces generated by a shader will flicker. This applies to terrain and aircraft Moin David, while I have no solution for the main problem, the following patch (kudos to Jester) helps here on my ATI to let runway lights shine as expected: http://git.overlays.gentoo.org/gitweb/?p=proj/gamerlay.git;a=blob;f=dev- games/simgear/files/simgear-radeon-fix-runway- lights.patch;h=a48c4bf62cd52ffe7f1c2c71dbb8f95ac41fbb09;hb=HEAD Chris -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Csaba Halász wrote: Hm, ok, that doesn't seem to be SSE related, it's just your everyday NULL pointer. Have to check source code to see how that can happen. Did you look into this already? Would be a good start to fix this (if the problem is not IN the gpc lib). Chris -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Newsletter - April 2011
Pascal J. Bourguignon wrote: Papillon81's git repo is not available: Please note that the link in the Newsletter only leads to the repo overview on gitorious where you can see the clone URL right on top of the page. Use this one and all should be fine :) Chris -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: fgdata merge request 76: Improvedairport Textures
Vivian Meazza wrote: The main problem is that the taxiway textures expose the workaround that we use because we don't (yet) have curved taxiways. The concrete colour does not blend with the old texture, which is still used for aprons etc., and the edge and centre lines also serve to emphasize the problem. Here are a couple of examples. I really don't see the problem here. The new textures look nicer as they have a slightly different colour than the apron. This looks more like planes are taxiing there and leave some tire traces behind. Note the lack of stopways. Presumably something went wrong with the merge. See how every segment of the taxiways is obvious. The colour of the grass is probably a matter of opinion, but note how it fails to merge with the surrounding textures, exposing the cut-in edge of the airfield. I'm very sorry, but IMO this all looks rather unprofessional. I would not wish to release this as it stands. The stopways still work for me here, so there is maybe something wrong in your fgdata? The taxiways in your screenshot surely look ugly but that's more due to the fact that they are not correctly ordered in the apt.dat file. It's not a problem of the new textures. I'm sorry, but I can't reproduce those problems here Chris -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear - file src/Lib/Optimize/genfans.cxx
Geoff McLane wrote: It certainly works better for me ;=)) And removes another reason why fgfs-construct can abort without apparent reason! Hi, you mean segfaults with no apparent reason? I experience them under Linux when building huge scenery chunks and if your patch improves the situation, I'll gladly give it a try. Chris -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear - file src/Lib/Optimize/genfans.cxx
Geoff, I applied both of your patches, see here: https://gitorious.org/papillon81/terragear-cs Until now I had no crashes or negative effects on the resulting scenery. However, there IS a problem, unrelated to your patches, for which I hope to get some help. I create large chunks of scenery with CORINE and OSM data. fgfs-construct runs quite some hours for it and i see the processing is fine. Then, after some time (say 6 hours), all I see in the console output are colums with Default=x where x is a number between 1 and 3. This goes on and on for hours and I stopped it yesterday. Is this supposed normal behaviour? Maybe the process is hanging somewhere, the CPU is buisy the whole time. Any ideas? Cheers Chris -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear - file src/Lib/Optimize/genfans.cxx
Geoff McLane wrote: It is certainly _NOT_ 'normal' behavior, and historically (I assume Curt ;=)) implemented some draconian 'rlimit' - setrlimit(RLIMIT_CPU,timeout), to abort after a period of time, which is just NOT available in my WIN32 environment, to avoid such a 'forever' loop... Hi, while i can't give you the exact output that I reported, right now (i'm not on my Computer where it happened), I have dug a bit deeper into the rlimit stuff. I used TG with the following patch applied (partly strange): http://git.overlays.gentoo.org/gitweb/?p=proj/gamerlay.git;a=blob;f=games- util/terragear-cs/files/terragear-cs- setrlimit.patch;h=bcb166cd1c6311d655416c4aacefa1b71bcd25c4;hb=e330979f290cc3b2259f124ddc9d9527d42280c5 To rule out any influence of it, I built TG without it, but the fgfs- construct process got interrupted very early, even with a small part of scenery to build. So it seems like this patch is needed one or the other way. Maybe with other settings. What do you use there? Chris -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear - file src/Lib/Optimize/genfans.cxx
Geoff McLane wrote: Thanks. It is good to know that the - Default=x, where x = 0-2 is 'normal', but Chris reported that it was still running after 6 hours, or more... and still unable to exactly find where this is output, in the code... You won't be able to find Default in the sources as the output is Landclass = x, Default being Landmass. So there might be something wrong in this direction. And Chris, you can see some of the comments associated with the 2009 patch to the rlimits code you pointed to are NOT correct! Even at that time any attempt to limit memory use was abandoned, and the CPU timeout was doubled... Like it seems you have done, this 'limit' is really NOT applicable to a specific area generation, as apposed to a whole world generation, using server/client, so like you, I 'chop' this 'rlimit' code completely... I put the patch back in, too. Some, like Gijs, and myself, are working on a GUI to assist in this scenery generation, but the important issue IS making sure the TG tools work well, otherwise such a GUI is rather pointless... Exactly, and as long as we don't have a new terrain engine in FG, more efforts have to be put into TG, if we don't want to end up in a mess, scenery-wise. Chris -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear terrafit memory leak
Durk Talsma wrote: I'm explicitly deleting all the Triangle and Edge objects. This has improved performance a lot I'm still not able to process the entire Eurasian continent in one pass, after this fix, the total number of .fit files that can be created on my linux box has gone up from 15881 to 94865. I hope to be able to commit these changes one way or the other. Hi Durk, glad to see you are also tackling some TG issues. I'm looking forward for your patches. Maybe you can also take a look at the patches in this repo here: https://gitorious.org/papillon81/terragear-cs Some of the commits might be worth integrating. Thanks Chris -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Slackware packages for 2.4.0
Curtis Olson wrote: Thanks Jon! I've added this info to the flightgear.org web site. If anyone else is working on packages for other linux distributions (or knows of updates for other distributions) please post here or let me know directly. I'm maintaining the Gentoo packages for our GIT versions (including tools like taxidraw and terragear). Available here: http://git.overlays.gentoo.org/gitweb/?p=proj/gamerlay.git;a=summary A package for 2.4.0 has yet to be created. Chris -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The future of FlightGear's support programs
HB-GRAL wrote: Personally I don’t know if there is a roadmap for taxidraw anymore. You can edit airport data with tools like Qgis directly and with much more comfort. It’s sad, but I think we dont need it anymore. Well, you can import apt.dat data into QGIS via GDAL. But be aware that this is a one-way road. Export is not possible with GDAL. I hope I'll be able to write a postgres script to write out apt.dat text files. Work is advancing slowly, however. Chris -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw
Durk Talsma wrote: I've imported the complete revision history from CVS. At this stage, I haven't really made a desision about whether I should try to keep the CVS and gitorious projects synchronized, or whether we should abandon the CVS repository altogether. I don't see why you should take the extra work to sync up both repos. First of all CVS is a PITA, compared to git and I don't see the benefit of further supporting it. Also, having the possibility of pull requests now on gitorious is a valuable improvement which might lead to the development of taxidraw gaining speed again. The same as with taxidraw should be done with terragear, which also lacks developer power and where quite some patches are scrambled over different places. Chris -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw
Martin Spott wrote: Well, why did this happen ? As far as I can tell no patch submission was unheard. Well, there are some patches in my TG tree that I'm using here and that might be worth considering: https://gitorious.org/papillon81/terragear-cs/commits/master Am I right that the mapserver TG repo is a copy of the CVS original? Then maybe a complete rebase would be in order, before pushing the whole stuff to its own repo. Chris -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
James Turner wrote: If you regularly pull+build 'next', please try a cmake based build, and report any issues you encounter - CMake should work 'out of the box' on Mac (Makefiles or XCode), Linux (32- and 64- bit) and Windows (VisualStudio 2008 and 2010 - mingw and cygwin may need some fixes). I have used CMake in the Gentoo packages pretty much from the start, but right now I'm experiencing some problems: all is good as long as I have libsvn support enabled in SG and FG. When I disable it in SG and want to recompile FG afterwards (also disabled, of course), I get a linking error for Terrasync: Linking CXX executable terrasync [ 47%] Building CXX object src/FDM/CMakeFiles/fgFDM.dir/UIUCModel/uiuc_auto_pilot.cpp.o /usr/lib/gcc/x86_64-pc-linux- gnu/4.5.3/../../../../lib64/libsgthreads.a(SGThread.cxx.o): In function `SGThread::~SGThread()': (.text+0x41): undefined reference to `pthread_detach' /usr/lib/gcc/x86_64-pc-linux- gnu/4.5.3/../../../../lib64/libsgthreads.a(SGThread.cxx.o): In function `SGThread::start()': (.text+0xce): undefined reference to `pthread_create' /usr/lib/gcc/x86_64-pc-linux- gnu/4.5.3/../../../../lib64/libsgthreads.a(SGThread.cxx.o): In function `SGThread::join()': (.text+0x116): undefined reference to `pthread_join' collect2: ld returned 1 exit status make[2]: *** [utils/TerraSync/terrasync] Error 1 make[1]: *** [utils/TerraSync/CMakeFiles/terrasync.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs I don't know if this is caused by the recent cmake changes or rather by the threads class rewrite... HTH Chris -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New experimental mapserver
Curtis Olson wrote: I won't say this is perfect in all areas ... some areas have stray data points or noise in the terrain data that confuses things. There's always a chance of a mismatch between airport location terrain location so that we are trying to put the airport on not quite the right underlying terrain. My thoughts for future extensions of this code would be to allow for creating specific tuning parameters for airports that didn't behave well with the default parameters. An nice example where a high slope leads to bad results would be LFLJ, however, it is possible in such cases to use the --max-slope option in genapts. Chris -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Christian Schmitt wrote: I have used CMake in the Gentoo packages pretty much from the start, but right now I'm experiencing some problems: all is good as long as I have libsvn support enabled in SG and FG. When I disable it in SG and want to recompile FG afterwards (also disabled, of course), I get a linking error for Terrasync: This is now solved with the latest FG git version. Thanks! -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] terragear-cs apt.dat 850 runway support
Hi there, i just want to announce that I added support for the 850 apt.dat runways to genapts. This work is thought as a compliment to the currently ongoing development towards curved taxiways. The current state is that genapts reads runways and creates them accordingly. Features: -different designations for both runway ends -different runway markings for both ends -all kinds of lights (different where possible in the 850 format) I was very glad to find already existing definitions for all kinds of new approach lights in the source. Also, the possibility to assign different runway markings to both ends make it possible to finally create runways visually correct that are only used into one direction (RW 18/36 in EDDF is one example). I'm currently working on the missing objects like PAPIs/VASIs. As this is my first programming project, I hope I didn't mess up something too bad. The source is available here: https://gitorious.org/papillon81/terragear-cs/commits/850 I cleaned up quite a bit of the runway markings code and made it more flexible. So it should be easier to add a wider variety of runway types in the future. Cheers, Chris / papillon81 -- 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-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs apt.dat 850 runway support
Christian Schmitt wrote: Hi there, i just want to announce that I added support for the 850 apt.dat runways to genapts. This work is thought as a compliment to the currently ongoing development towards curved taxiways. The current state is that genapts reads runways and creates them accordingly. Oh, and by the way: I'm still searching for the runway texture paintkit as mentioned here: http://www.mail-archive.com/flightgear- de...@lists.sourceforge.net/msg25639.html If not, we might want to take another approach on recreating them... Chris -- 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-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
James Turner wrote: Okay, but the relevant source file (sg_binobj) appears to contain both the read *and* write code paths - which is really what I was asking - is the write logic in sg_binobj.cxx the one terragear uses, or 'something else'? James Please be aware that TG uses SG-CS currently. I used it with the normal SG for a while but this was no longer possible recently. It exposed weird behaviour and crashes. Chris -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ 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
[Flightgear-devel] Terragear now sans plib
Hi there, maybe you have noticed some exceptionally high activity in recent days/weeks on the Terragear repo. Well, there is one particular reason for it: It now supports the cmake build system and, as of today, does no longer depend on plib. These changes are not yet in the master tree, but can be tested in the topics/cmake-integration branch. Please do so, if possible, so we can iron out any showstoppers. Chris -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear now sans plib
Geoff McLane wrote: An error something like - 'do not know how to make main.c from main.o' which I did NOT understand... seems reversed! And why 'main.c', since the Makefile.am shows only - raw2ascii_SOURCES = main.cxx rawdem.c rawdem.h There is no main.c here??? Hi, this is caused by old .dep dirs and files lying around, which still contain the old names (main was renamed recently). So either restart with a fresh repo checkout, or do a grep for main.c in src/Prep/DemRaw2ascii and change it accordingly. HTH Chris -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear now sans plib
James Turner wrote: A fair suggestion! I originally combined them because it was easier not to worry about PLIB when creating the CMake files, but I wasn't expecting the slightly-complex changes to de-PLIB the file handling code. Let me see how hard it would be, to un-pick the changes. I'm pretty good at untangling git commits, but IMHO, let's only do that if it is clear that the current directory problems can't be rectified with 1-2 more commits. Seperating cmake from de-plib might be far more work. Chris -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear memory usage issue
Jason Cox wrote: is it not appropriate to issue a build of such a large area? should I use smaller chunks? should terragear not be releasing the memory after building a tile? Generally speaking, sometimes it works, sometimes it doesn't. And yes, it should free unused memory after finishing a tile. This is also one of the (many) issues. Patches or more info are always welcome. Chris -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear memory usage issue
Hi Jason, I just tried to reproduce this issue here. Generating some scenery around LOWI with 850 airport layouts, I only see always two SRTM files open: the arr.gz and fit.gz for the tile that is currently built. So no problems here. What confuses me a bit is you using SRTM-2 files. What is this and how does hgtchop handle these? Chris Jason Cox wrote: Ok so I am replying to myself. after running fgfs-construct for the last 10+ hours at nice -20 and still going I have the following info. I ran lsof on the PID and have found that it is still holding all SRTM2 arr and fit files open. This is the probable cause of the memory leak that I am seeing. Can anyone point in the direction of where this should be unloaded and I will attempt to hack the code -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear memory usage issue
Jason Cox wrote: I would try a larger area, say 1x1 deg or larger and then and then you will see the list grow to include tiles that are no longer needed. I created a 2x3 degree area. No problems. What terragear-cs version do you use and against which simgear do you compile it? Will now test even further and create another area. Chris -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear now sans plib
James Turner wrote: I've pushed a fix to Simgear, updated the tests, and now I can run hgtchop happily with latest simgear and terragear. Not only can I hgtchop, but also build scenery chunks again. So from my point of view the problems are solved. Are there any objections against pushing the changes to master? So this gets some more testing and more people can make use of the improvements. Chris -- RSA#174; Conference 2012 Save $700 by Nov 18 Register now#33; http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear now sans plib
James Turner wrote: With some local changes to Simgear/next, but I am 'fairly sure' they don't relate to path/file/string handling. (Some changes in the SGOceanTile handling) I just tested this as well (without your fix) and it works here too. Even when using Martin's pathnames. glibc-2.13 gcc-4.5.3 Martin: Can you tell me under which OS this is happening? So I can try to reproduce it in a VM. Chris -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear now sans plib
Martin Spott wrote: Christian Schmitt wrote: Martin: Can you tell me under which OS this is happening? So I can try to reproduce it in a VM. That's stock Debian 6 alias Squeeze, the current stable, GCC-4.4.5 and Glibc-2.11.2, if it matters, I guess it matters, because I get exactly the same error as you now in the Debian VM Chris -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear now sans plib
Martin Spott wrote: That's stock Debian 6 alias Squeeze, the current stable, GCC-4.4.5 and Glibc-2.11.2, if it matters, Ok, I observed the following: compiling the raw2ascii as Release leads to the error (on Debian). When compiling as Debug it works here. Chris -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FGWeekend NL scenery
Hi, for those of you who are interested in some nice EHLE flyins can download the custom scenery for NL with apt.dat 850 airports and OSM line data here: https://gitorious.org/papillon81/flightgear-terrain Have fun! Chris -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear now sans plib
Martin Spott wrote: Thanks a lot, things are looking much better now ! I'll perform a few more tests and will report back. Can confirm the fix as well. It works all as expected. Waiting for your last feedback now, Martin, before preparing the merge. In the meantime we managed to established a method to reliably create topologically clean !! CORINE land cover from the publicly available sources, thus we just (TM) need to find out how - reliably - not to crash 'fgfs-construct' when processing these detailed datasets at large scale ;-) That sounds good, but I still don't know what/where the tile border elevation inaccuracies exactly come from... Chris -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear now sans plib
Martin Spott wrote: I'm pretty certain the crash in 'fgfs-construct' is unrelated, just the usual issue we already know. Therefore I'd vote to merge the CMake branch - just in case, we'd fix the remaining issues in master. Done. If someone could remove the cmake branches, that'd be nice. :) -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixing fgfs-construct crashes
Hi, Martin Spott wrote: Thus, if you'd be willing to put your stuff into a branch at the main repo, please go ahead - call us if you don't have write access. I don't feel too good about adding even more branches directly into the main TG repo. The reason is this: In the process of the 850 development we have changed and rebased the history multiple times against TG master (mainly because of the cmake addition that came along and that I added to our files as well). This as a consequence changes the git objects and needs a forced push. That's allright for testing. I'd rather do the dirty work seperately in an own repo than polluting the TG main repo with old and unused git objects (which git does not throw away by itself). And no, I'd not use git merge for this, as this as it complicates the history and leads to all kind of problems later on. To make life a bit easier, I have moved the TG 850 repo to be a clone of TG now, so that at least activity in our clone shows up on the main FG page. This should already improve the situation quite a bit. Chris -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixing fgfs-construct crashes
James Turner wrote: Okay, this all sounds like good news indeed. Martin, Chris, Peter - I think the steps need to be as follows - get a branch of terragear with the clipper changes, and probably the epsilon changes Maxime describes (because I've always worried, they were only needed due to GPC problems). I like the way of getting the changes into master in tiny chunks. And I already tested the epsilon changes of Maxime with the NL scenery I created for FSWeekend. So if you all agree, I can create a clipper/epsilon branch against master to get this tested first. Chris -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] lightning codes, genapts
Hi, yes, the 850 genapts supports the new approach lights. In fact, even the 850 version did in theory, but the file format did not. The relevant code starts here: https://gitorious.org/~papillon81/fg/terragear850/blobs/tg850/src/Airports/GenAirports/lights.cxx#line2635 Please ignore the not supported by data base comments. Those types are also supported. I only have to correct the comments. Of course they work with FG. Cheers, Chris HB-GRAL wrote: Hi all Another question rised up here during my faa-data to apt.dat conversion. Does the current (or the updated) genapts take new approach lightning codes into account ? Can the scenery tools read the new 8.50 runway line already or is this still based on 8.10 specs ? Maybe I missed this point in a discussion here, sorry for that. But to illustrate my question, the problem is that some lightning codes are not covered in 8.10 specs. What I get from FAA: # MALSR # MALSF # MALS # SSALR # SALS # LDIN # RAIL # MIL OVRN # NSTD # ALSF-1 # ALSF-2 # ODALS Now With 8.50 runway line specs I can cover most of this new codes, but not with 8.10, which knows only # SSALS (Simplified short approach light system) # SALSF (Short approach light system with sequenced flashing lights). # ALSF-I (Approach light system with sequenced flashing lights). # ALSF-II (Approach light system with sequenced flashing lights and red side bar lights the last 1000'). # ODALS (Omni-directional approach light system). # Calvert (a British design) category 1. # Calvert (a British design) categories 2 and 3. I can not find any information about FLightGear implementation. This here http://wiki.flightgear.org/Approach_lighting_system is just a copy paste from wikipedia and does not say if this codes/models are part of the fg runway lightning system or not ? Thanks for any suggestion and comment about this. Cheers, Yves -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] lightning codes, genapts
Christian Schmitt wrote: Hi, [...] In fact, even the 850 version did in theory, but the file format did not. I mean 810, of course :) Chris -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SPAM in the MP world
Stefan Gofferje wrote: I think, we should seriously do something about this kind of stuff before the MP world becomes a popular place for spammers, like e.g. have the MP servers filter URLs out from the MP chat... No, I do not agree. But for exactly this purpose we have the ignore checkboxes in the pilot list, which would have solved your problem quite easily :) Chris -- 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] Scenery related: groundnetworks and parking
Martin Spott wrote: Any volunteer(s) ? Proper representation of ground network nodes as PostGIS (actually OGC) geometry data type preferred. Apparently you don't want any 850 centerlines as a base for this, which would be easy as gdal imports 850 data directly into Postgis, as you surely know :) It might be a solution worth considering IMHO. Surely a lot easier than drawing groundnetworks from scratch for bigger airports. Chris -- 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] Looking at a nice project from outside
flightg...@sablonier.ch wrote: [...] 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). A scenery team is no bad idea and overdue. There ARE people who have proven in the past that they like to work on the scenery basics and not only create custom scenery. I had so many contributions to the CS DB, that I did not catch up with the work (and am in fact still missing some parts). Let me mention though that there IS a #fg_scenery channel on IRC (with nobody in it) and having a meeting to coordinate ideas and capacities surely is a good start. In the mid- to longterm perspective I'd like to make more advancements on the terragear side, to enable us to rebuild single tiles when there are changes. This is possible already, as many of you know, but then in most cases the newly created tile does no longer match fit to its neighbours, which results in gaps. If we could iron this out, we'd be a whole lot further down the road... Chris -- 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
[Flightgear-devel] Log of Scenery IRC meeting
Hello, here is the log of the meeting we held today as a first measure to formalize future scenery development processes. I deleted any mail adresses for privacy reasons. Cheers Chris [17:26:58] MartinSpott I'm just interested in the log, thus if you prefer to chat on 'your' server, then I'm completely satisfied if you'd create a log [17:27:12] papillon81 MartinSpott: that's planned anyway, yes [17:27:46] MartinSpott Ok, then you'd better save your time and use your favourite server [17:28:02] papillon81 now we are almost all here [17:28:17] MartinSpott Ah, I was just about to leave :-) [17:28:30] itchi_ arf :/ [17:28:42] papillon81 whatever [17:28:45] papillon81 let's start [17:28:47] MartinSpott Really, I just interested in the log [17:29:27] itchi_ MartinSpott: There where a few that had some questions [17:30:01] itchi_ Maybe time to start no? Not that i have any particular question [17:30:25] itchi_ MartinSpott: BTW, i'm David Van Mosselbeen (if you have read my mail on the devlist) [17:30:30] Blackiris Yeah, ok [17:31:28] ysablonier MartinSpott: Is there a tracker for issues/task world scenery related? [17:32:54] MartinSpott Don't know, I didn't create any tracker [17:32:57] - ysablonier heißt jetzt gral [17:33:00] gral So. [17:33:55] MartinSpott If you'd like to track Scenery issues, I think the bug-tracker @ Google is the place you're looking for [17:34:16] MartinSpott At least that's the only one I've been monitoring occasionally [17:34:23] Blackiris Martin: do you have at least some todo list about world scenery tasks? [17:34:54] gral My proposal is to open another tracker for the World Scenery Project, more for the tasks [17:35:36] papillon81 gral: i'd say a scenery specific tracker, which includes issues in TG and in the released scenery [17:35:50] MartinSpott I'm having _my_ todo list concerning the land cover vectors. Aside from that, you'll find a couple of requests on the -devel mailing list [17:36:45] MartinSpott Olivier has picked up one of the items, but as far as I know most of the requests passed unheard [17:37:17] gral Can I make you the owner of http://code.google.com/p/flightgear-world-scenery/ , temporary ? [17:37:20] Blackiris Maybe they should be written somewhere such as the wiki [17:38:00] gral http://wiki.flightgear.org/World_Scenery_2.0_Project [17:38:27] MartinSpott gral: If you're asking me, I'm certainly not taking any ownership ;-) [17:39:40] gral This was TO ALL ;-) [17:39:40] MartinSpott I'm in the process of cleaning up by backlog so whoever might want to continue will get the stuff a moderately clean state [17:40:25] papillon81 MartinSpott: what would stuff be in this case? [17:41:12] MartinSpott Past Scenemodels submissions with open issues [17:41:43] MartinSpott Writing yet another reminder about the airfield collection [17:42:08] MartinSpott Chatting with GIS people about possible improvements in GRASS [17:42:25] MartinSpott Building recent PostGIS SVN on Solaris [17:43:06] MartinSpott Adding comments to the various (Shell) scripts and updating the sceneryweb and terragear-cs GIT repos accordingly [17:43:19] psadro1 Martin, I'm a bit concerned about mapserver.flightgear.org. This is pretty much your domain as well, correct? [17:44:01] MartinSpott yup, I had very little support there :-) [17:44:20] itchi_ For my Belgium scenery, one of the main reasons i host them on Gitorious is that the airport layouts aren't right. Some are completely non-accurate with +-300m off. And some other are just missing some essential runway. So i'm a bit lost i must admit [17:44:48] MartinSpott Adrian recently added some features to the web map, but aside from that I think it's my own playground [17:45:02] psadro1 Is this your server? [17:45:11] MartinSpott Don't expect me to join any sort of discussion about the private sceneries [17:45:15] itchi_ Well, i worry about EBSG and EBTY, because they are on of my favorite fields which i visited and like to fly there in FG :) Even if i didn't fly there in real life :) [17:45:42] MartinSpott psadro1: No, sponsored hardware and bandwidth in San Diego UCSD and Calit2 [17:45:55] itchi_ They aren't meant to be private at all. But if i push my airport objects, you will be on the wrong side of te airfield :/ [17:46:12] MartinSpott psadro1: Actually that's not just one server. [17:46:21] MartinSpott One four-socket DB server on Solaris [17:46:22] papillon81 MartinSpott: if I see this correctly, gral is working on some mapserver project, too. would you hand over the ressources to a person you trust? [17:46:36] MartinSpott One web frontend (4 cores) on Linux [17:46:38] itchi_ I like to take up an aircraft at a hangar, take off... and do my stuff, and set back the aircraft where i took it :) [17:46:58] MartinSpott A supplemental TileCache running on a dedicated machine, but not being used exclusively for FG stuff [17:47:12] psadro1 that's a relief. I was a bit panicked about it when I read your mail on the
Re: [Flightgear-devel] New (real time) mapping tool proposal
HB-GRAL wrote: Now I am deeply offended. Did you ever have a closer look to FGx launcher? It has exactly all this already prepared for you and this project is open to any contribution. I can understand you. And Curt, openlayers is by far a new thing. Not only is it used in FGx (a nice piece of software), but also on mapserver.flightgear.org. Chris -- 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] Project Rembrandt - next steps
Stuart Buchanan wrote: Given that we have 400+ aircraft that need to be updated, I think we also need clear documentation (on the wiki?) describing the steps you outline above, and in particular how to register the transparent surfaces. That probably needs to be in place before the code goes into next. Yes, then we can make aircraft after aircraft Rembrandt ready so that we have a nice pool of planes for the next release. IMO we should bite the bullet and get it into next this week if possible. There's obviously some risk to our 6 month release schedules that we'll just have to accept. I agree here. Let's merge the Rembrandt work into next so that every git user has to work with it, can find glitches and adapt shaders. There are people holding back their shader improvements in anticipation of Rembrandt. We have to merge it anyway sooner or later. Now, the likeliness of conflicts is lower and the speed of development will be faster. Cheers Chris -- 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] Project Rembrandt - next steps
Curtis Olson wrote: I have a local branch I've created here for some experimentation. When ever I do a git pull from the gitorious repository, I do that in the next/master branches. Then I switch to my local branch and type git merge next (or master) to make my local branch up to date with the main development head. There may be a better way to do that, but it's what was suggested to me, and seems to work and I've stuck with it. For the sake of completeness and (possibly) nicer git history in the future let me say this: There IS indeed a better way for exactly your use-case: When switching back to your local branch after git pull in next, use git rebase next (or master) on your local branch. This makes sure your changes are always on top of your local branch and prevents those Merge commit XXX messages in the git history. HTH Chris -- 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] First attempt with terragear: fail! :-(
Gijs de Rooy wrote: Looks like OGR-decode is broken (in the Windows builds at least) since some time. I still don't completely understand the difference between OGR and Shape, both seem to deliver the same results... Maybe someone else can explain this? ogr-decode uses gdal to process the shapes, which is generally a good idea as gdal is THE tool for such tasks. As I'm not running windows I can't help with improving the situation there, sorry. Chris -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Next Meeting #fg_scenery
Hi, the next meeting is planned for Monday, 26.3. at 16:00 UTC or 4 PM UTC. Don't forget about the DST starting tonight in many countries :) Hope to see many of you. Chris -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Rembrandt] the plan
Tested under Gentoo with a Radeon HD 4670 and the fglrx driver: Works. Render previews show up and the overall performance is nice. I also ran a short test with the opensource radeon driver. There, the GLSL version 1.3 was too much for it. I got a picture however. Can't wait to see the render previews combined :) Chris Frederic Bouvier wrote: The first batch of sources has been pushed to gitorious. These commits are intended mainly to check that the classical (forward) renderer is not broken and works as usual. They will also permit one to challenge his GPU and see how it behaves in front of the beast. In the plan exposed previously (see below), I skipped step 3. (define an XML format for a configurable renderer) as it appears to be more involved than expected. So what you have is a buggy step 5. :) Buggy because for some reason, sun light depends on the orientation of the camera. But you should get an image. The Rembrandt renderer is enabled with the --enable-rembrandt option. *ALL SHADERS SHOULD BE SET TO OFF* unless someone want to begin to convert other shaders. Regards, -Fred -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ 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: 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 :) 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. 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. 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. HTH Chris -- 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 Yves, flightg...@sablonier.ch wrote: 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? Did you actually read my last message here? I tried to explain where the differences between FG and xplane are: Xplane generates the airports on the fly on startup and thus can just exchange the apt.dat files. I guess you can imagine that this would not be a good idea for us currently. 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?). -- 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
ThorstenB wrote: But to be honest, it neither works with central terrasync scenery. We could never push any updates (such as introducing terrasync scenery with the new EDDF runway) without immediately breaking consistency with all previously released FG versions (= their base packages). And we cannot expect all users to run the same FG version - or to even update their FG setups (base packages) on the same day. A bunch of Linux distros still haven't switched to FG 2.6.0... But we can't guarantee backwards compatibility forever for future world scenery releases. The main problem I currently see is a different one however... Terrasync already syncs a global /Models directory, so terrasync scenery can use newer or updated models. We could do the same for nav data. I'd be happy to extend terrasync to sync another global directory, i.e. /Nav (or /Nav810, /Nav850) and then extend FG to consider these directories first, before defaulting to (old) nav/airport/airway data from the base package - which then would only need to match the (old) base package scenery (i.e. before the users pulls terrasync data for the first time). Now, it's good to see these issues getting some attention, but that is not the only issue we are facing: Taxiway signs are distributed via terrasync as stg entries. apt.dat 850 contains the taxiway definitions along with the rest of the airport data. What we do now in genapts850 is to convert the sign format from apt.dat to stg and write the corresponding files. No problem so far (and we always get the correct hight for the signs along the way). If a user wants to edit the signs, he can do it in stg, but that is a one way road. Ideally the edits should go back to upstream so everyone can profit from them. But there is no (official) way back from stg to apt.dat. I was in this situation yesterday and hacked together a quick script to be able to convert the signs. Xplane's WorldEditor (WED), an opensource program, BTW, is perfectly able to create airport layouts, signs and taxiway routes. All of this is read and written back to apt.dat. So our general question should be how to handle this situation in the most optimal way. Should we continue implementing our own xml versions of the apt.dat entries or should we rather try to read as many properties as possible directly from an apt.dat file? And how do we secure the exchange of data between stg and apt.dat? This topic is very complex and I'm sure i forgot many other important aspects, but this is just what i'm currently thinking about. Chris -- 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
ThorstenB wrote: But to be honest, it neither works with central terrasync scenery. We could never push any updates (such as introducing terrasync scenery with the new EDDF runway) without immediately breaking consistency with all previously released FG versions (= their base packages). We could, if the xml parser would not simply discard any new runways that are not already in the apt.dat file. The xml files are small, can be distributed easily and are very fine- grained, meaning that FG only has to parse the data it really needs for the current scenery path, instead of parsing a close-to 100 MB file on every startup (only for the apt data). We could completely decouple the scenery from the base package and finally make it possible again to distribute updated scenery via terrasync, even in smaller chunks (continent-wise or whatever makes sense). I already looked into the code and James has signalled support, so I'd like to hear some opinions. Terrasync already syncs a global /Models directory, so terrasync scenery can use newer or updated models. We could do the same for nav data. I'd be happy to extend terrasync to sync another global directory, i.e. /Nav (or /Nav810, /Nav850) and then extend FG to consider these directories first, before defaulting to (old) nav/airport/airway data from the base package - which then would only need to match the (old) base package scenery (i.e. before the users pulls terrasync data for the first time). You mean to put small apt.dat/nav.dat parts into these directories? Chris -- 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
