Re: [Flightgear-devel] Release 2.10.0: Decision Altitude
Curt, I noticed the SG/FG packages got updated on the mirrors. So I checked them out again: still the same issue. How did you create the source tarballs? Having the version number 2.8 in it looks like they were created from an older, used git clone and not a fresh or cleaned up one. The tarballs should only contain files that are in git, nothing that gets created during configure/compile time. Chris Curtis Olson wrote: Certainly this is my fault, however, I must misunderstand something about cmake for this to happen. Can someone enlighten me and tell me what I need to do to fix this? Maybe there is something we can tweak in the future if the default behavior requires manual intervention to achieve the correct outcome? Thanks for checking this out Chris. Curt. -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release 2.10.0: Decision Altitude
Sorry Curt, but nothing writes into the source dir if you use a sane, clean and proper checkout from git. Your tarballs make me think that you already ran cmake inside the source dir prior to packaging them. Could you run git clean -fdx inside the source dir and tar the result up again? This will eliminate any remains from prior cmake processings. Chris Curtis Olson wrote: Ok, I see now that in simgear-2.10.tar.bz2 the top level file version does report 2.10.0 but the simgear/version.h file is saying 2.8.0 So my question are: 1. for an out-of-source build, why is the build system writing files in the source tree? Can we fix that? 2. what is the proper cmake fix here so it doesn't happen in the future? -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release 2.10.0: Decision Altitude
Hi, while this might be a minor issue, I still want to bring it up here: The SG and FG 2.10.0 release tarballs from the ibiblio mirror contain version.h files with version number 2.8.0. While this should be overwritten by cmake on configure time I just experienced a case where it wasn't with the result that fgfs didn't run because of fgdata/program mismatch. The version.h files should not be in the distributed tarball as they are runtime generated files. Just FYI Chris Curtis Olson wrote: Hi Everyone, I just wanted to send a quick update on the release process. Feb 17 arrives at different times at different places and it is still Feb 16 here for another hour. I have uploaded the source and the mac version of the release to ibiblio.org and the final windows version is being uploaded right now with about 2hr 45min left to go. So it will not finish before I head off to bed. When I get up I will hopefully find that everything transferred correctly. I'll update the kingmont mirror and hopefully the other mirrors will be getting in sync soon too. At that point I'll update the download links on the web site, try to find Stuart's release announcement in my email archives, etc. etc. I have a couple commitments tomorrow so I hope to have most of the release things taken care of by mid-afternoon (MN time) but we'll see. Please be patient if not everything is quite in place by Feb 17 00:00 UTC, we are getting better, but we aren't quite that good yet. :-) I appreciate all the hard work that so many people have put in on so many fronts to make this release happen smoothly! Thanks! Curt. -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release 2.10.0: Decision Altitude
Hi, upon further inspection the problem appears to be more serious: It occurs if SG/FG are built in a separate build dir, as recommended by the cmake process. We then have version 2.8 in the original sources and 2.10 in the build dir. Why 2.8 gets picked up is beyond my knowledge but I would consider this to be a serious issue and we should fix it before getting flamed post-release. Chris Christian Schmitt wrote: Hi, while this might be a minor issue, I still want to bring it up here: The SG and FG 2.10.0 release tarballs from the ibiblio mirror contain version.h files with version number 2.8.0. While this should be overwritten by cmake on configure time I just experienced a case where it wasn't with the result that fgfs didn't run because of fgdata/program mismatch. The version.h files should not be in the distributed tarball as they are runtime generated files. Just FYI Chris -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Howto modify release branch?
Renk Thorsten wrote: Sorry, I don't want to mess up the release branch, and I would much appreciate a helping hand here. Would you just tell us what commits from master you want in the release branch? Of course, yes, if the commit you cherry-picked is based on another one, that won't work without manual merging. So either first cherry-pick the first commit and then the second one, or, if this would bring in too much changes, merge the second commit manually (by resolving the conflict git tells you about). Chris -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Grass and Dirt material declaration
Hi Thorsten, I added these materials, originally with lower-case (unused). Then I wanted to make them consistent with the other landcover names and changed to capitals, not taking care of the already existing names. So this introduced the problem. I corrected it some minutes ago and hope everything is fine again. Chris Renk Thorsten wrote: During the last weeks, someone added the 'Grass' landclass to the 'grass_raw' materials declaration and the 'Dirt' landclass to the 'dirt_rwy' declaration in/ Materials/regions/materials.xml. I would like to undo the changes, or discuss other solutions to fix the problems caused by them - my GIT knowledge isn't good enough to find who committed that, so please get in touch. The problems caused are as follows: * assigning 'Dirt' the dirt_rwy texture changed all rock textures in the summit regions of the Alps in the French custom scenery to dirt runway textures. I realize this isn't as it should be - potentially this could be a scenery-side issue that the summit regions are misclassified as 'Dirt' rather than 'Rock', although I think this unlikely. I've come across similar issues that some landclasses are not really separable - so by some weird effect setting Dirt also previously set Rock for me when I tried this a year ago. I have no good understanding of the underlying issue, but at least till the time this is clarified, I think the error of replacing rock by dirt runway is much worse than replacing dirt by rock. * assigning 'Grass' to 'grass_rwy' seems to suddenly reveal the fact that the green around our airport runways is two different landclasses. Since now 'Grass' gets a size of 75x75 but later AirportKeep Co get a size of 125x125 and in addition specular reflection coefficients, under the right light what formerly seemed a common green now shows pronounced differences in color and texture. For the same reason, the change spoils my RealGrass(TM) overlay texture scheme, which unfortunately inherits size and specular reflection and shows the same differences in an even worse way. I'm not quite sure why these two changes have been introduced, but maybe we can find a solution without such bad side effects? * Thorsten -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear Build 2012-11-28 - MSCV10 - Build failure
Vivian Meazza wrote: Simgear fails to build under MSVC10 today, 2012-11-28, with this error: error C2724: 'SGThread::current' : 'static' should not be used on member functions defined at file scope file D:\Git_New\my_simgear\simgear\threads\SGThread.cxx Line 84 Fixed. Thanks for pointing this out, as jenkins couldn't ;) Chris -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader optimization
Hi Thorsten, Renk Thorsten wrote: FYI, I fixed the snowline problem for custom terrain half a year ago by passing camera altitude as uniform and computing absolute vertex altitude from camera altitude and the vertical difference. :-) The current point seemed to be that Mathias says we _should_ not rely on that even if we evidently can. Maybe it would be better next time to ping some more people and notify them about problems in the scenery toolchain. Emilian did it (http://code.google.com/p/flightgear-bugs/issues/detail?id=888) and we fixed the bug, which means that your additional calculations are unnecessary now for the official scenery anyway and for future builds as well. Chris -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Terragear updates/changes
To all whom it may concern, terragear has seen some bigger updates recently and we are constantly working on improving the toolchain. This also includes some cleanup and thus removal of older tools where better alternatives have been developed in the last 12+ years. I created a branch, named pre_vec3 where these older tools still exist for reference and historic reasons. The development in the master branch now goes towards porting the Point3d classes towards the more proven SG alternatives SGGeod and SGVec3 so that we can finally remove Point3d in TG as well. With this came the removal of the older genapts (810) program, which we decided would be too difficult to maintain along the newer version. As I said, it still exists in the pre_vec3 branch. Just FYI. Cheers Chris -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata trouble
Hi Thorsten, Renk Thorsten wrote: Every fgdata contributor who creates complicated xml/shader files should be able to understand basic git workflow as well... I'm not sure if you really mean every contributor, or every contributor with commit rights to FGData. In the second case I'd agree with you, but in case it's the first: I meant the second case indeed. I don't think GIT is particularly simple, nor have I found a good documentation. The basic tutorials / references which are human-readable are nice, but then all sorts of problems not covered in the tutorial crop up in reality. For instance, for some reason I can't push updates to my devel branch to my repo clone because of some timestamp issue, but remotely deleting and pushing new works fine. A rebase where the file a patch applies to has been deleted on master is a really good puzzle. And so on. On the other hand, the advanced manuals which would presumably treat these problems get into specialized nomenclature like alternative histories, octopus merging and what not and I can't find any understandable answers there. If you need help in a special case, there are always people here who are glad to help. In case of deleted files upstream that you want to rebase upon, yes that can be a bit more difficult, but generally , if the file has been deleted it was deleted for a reason. So in order to understand it on the level you seem to be expecting, I would really need to reserve a week and work through a long GIT reference book. No need for that IMHO. You need to understand essentially 3 commands: git pull --rebase, git rebase, git stash to do 90% of the work that you will ever come along (not counting in commands like git log, git diff and git status here, that are mainly for inspection purpose). It's called specialization. In the physics department we work in, we have for instance administrative secretaries. So, whenever I spend money from my research grant, I don't know all the accounting codes for the various items, nor the procedures, they do. Of course the system could in theory be set up such as to require 60 physicists to learn accounting procedures and follow all the accounting rule changes, but it's been generally acknowledged that it's more efficient if the 4 secretaries do so, and the physicists focus on their business. So you are calling for git monkeys that take care of the tedious process of getting changes into the tree? Of course, you can be of the opionion 'Hey, if you want to contribute here, we require you to learn 'proper' GIT procedures' (whatever 'proper' is...). To which an alternative scenario would be 'If you want my contribution on your GIT server, you make it easy for me to get it there and don't make my jump through 10 hoops.' Everyone is welcome to contribute, but yes, I request those people with commit rights to have a good knowledge of what they do when pushing to the repos. I don't mess with GLSL or Nasal code either if I have no clue what I'm doing. I think asking every contributor to properly work through a GIT manual before he can contribute is about as useful as to ask every contributor to learn the effects and GLSL framework before he can contribute anything - you're just reducing the not so large to begin with pool of contributors. In case of Nasal or shader problems, I usually try to step up and help with a fix if I can, because that's my speciality, I don't argue that everyone must know all Nasal tricks before he can contribute. I would hope that in case of GIT trouble, the GIT specialists step up. The specialists would love to have the possibility to step up, but that's only possible if they are asked *prior* to the push. Once the damage is done in the repo, fixing it is possible, but would include a rewrite of the history and that is not very much what anyone would like to do. Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata trouble
Thanks Thorsten for your clear words, yes, it sucks to see people messing up the history, merging local branches and then pushing them to gitorious. I personally see another problem in the way changes that are merged appear in the history: The merge date is there, but the commits associated to it can be hidden somewhere down in the history. This is a very bad state when it comes to bughunting (bisecting). Every fgdata contributor who creates complicated xml/shader files should be able to understand basic git workflow as well... Chris ThorstenB wrote: On 21 Sep 2012, at 13:03, Anders Gidenstam wrote: The master branch of fgdata has become messed up. A number of commits have become duplicated and some undone (they exist in the history but their effect is gone from HEAD). It has happened again, fgdata history is messed up. It looks as if my last commits (6d46fe7, f722671) were applied to fgdata multiple times now (duplicates are 818b92f and e7452f7). With gitk itself, I can't even see how where these originated (looks as if I had pushed them multiple times). Only the gitorious.org history shows that these were indeed not pushed by me: https://www.gitorious.org/fg/fgdata/commit/818b92fa07a49c333f80ac21f483b33fd5e2b7c7 https://www.gitorious.org/fg/fgdata/commit/e7452f70358e67824e499294fd32d6d6f8d3dd93 Can we please make it a requirement that _local_ merge operations must not become visible on our public repository, so _everyone_ has to rebase before pushing anything? The only merge/branch operations that should be visible in our public repo should be those that affect public branches (release branch creation/merges etc). There's really no reason why other people should see that user XYZ has merged his local branch 1-15 times with gitorious, before pushing back. It only results in the git history becoming unreadable. And apparently it results in more issues. If you compare simgear's or flightgear's history with fgdata's history, you'll see how nice and readable a git history can be - since obviously (almost) everyone pushing to sg/fg knows hows how to rebase. Resolving merge operations locally, to reorder and cleanup the history is really simple - and only requires a few seconds. If you have uncommited changes in your local directory, you can temporarily stash them - so that rebase won't complain. For fgdata: git stash git rebase origin/master git stash pop (And for simgear/flightgear: git stash git rebase origin/next git stash pop ) It is also a good idea to check the git history (gitk) before pushing to gitorious: you can read and double check your own changes a final time - and also check the history for local merge or funny duplication issues. If you're having local Git trouble (like duplications), *please* ask before pushing to gitorious. cheers, Thorsten -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear libraries
Hi, I'm already linking all my deps dynamically against SG, but makeing it easier for the static variant would be great as well. Even more so if you take care of the TG changes :) Cheers Chris James Turner wrote: Hi, For some time, Simgear has had the option to build shared libraries (DLLs on Windows) - this is only really useful for developers, since it can reduce link times. However, when I made this change, I organised Simgear into 'core' and 'scene' libraries; the 'core' part is also what we call 'headless' simgear, i.e can be compiled without requiring OpenSceneGraph or any GUI systems. (Which is how SG is used by terragear and potentially some other users). Mathias has suggested, and I agree, it would be sensible to also package the *static* libraries this way. So instead of having many static libraries, we will have only two: libSimGearCore.a and libSimGearScene.a This will likely mean some small changes to the CMakeFiles for the downstream projects; I will take care of FlightGear and TerraGear directly, and will of course help fix any other affected code. Any comments or objections on this change? Note this DOES NOT increase the linked binary size of executables created from SimGear - linkers already discard unreachable code when linking against .a archives. All we're doing is giving the linker one .a to unpack into objects, instead of a group of them. James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] commit 75087095b132ec7a42e14000c7c8b3b09147d720
Alexis Bory wrote: While taking the time to fix that or find a solution so FG got the best from the optimisations, could it be possible to have some guide line to revert on our local git only the necessary commits, so we can continue the work on the instruments and use the other latest developments ? Alexis (xiii) Sure, what about this: git checkout -b revert-tim-change git revert 75087095b132ec Now you work on the revert-tim-change branch until the fix is committed. Then you just switch back to next and delete the revert branch. Cheers Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] PAPI/runway lights size - Rembrandt
Hi there, the size of the PAPI lights has been bothering me for quite some time. It looks just too big for me. Going through the simgear git history I found out quickly that it was changed by commit 1dfde64ac2e6ed0a Use bigger point sprites for airport lighting. I reduced the size locally to 14 for the PAPI and 8 for the runway lights. All was good until I started FG with Rembrandt enabled. Then the PAPI lights do not show up during daytime now. This looks like a Rembrandt bug to me. I think the sizes should be reduced for the non-Rembrandt users as this is still our main audience. Fred, do you have a clue what is going on? Cheers, Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGCom - cmake
Awesome! I waited for just that, because current fgcom has not seen any change for a long time. Alreadey did a quick test and I think you will get some merge requests soon :) Cheers, Chris HB-GRAL wrote: Hi all The last weeks Geoff McLane and me forked fgcom temporary at gitorious (http://www.gitorious.org/fgcom) and made some significant changes. Origin source is still available at http://sourceforge.net/projects/fgcom/ - Most important change is moving fgcom to cmake build and trying to get fgcom compiling on all platforms again. - updated perl scripts to generate positions and freqs files with recent apt.dat/nav.dat - In CMakeLists you can see that is possible now to set paths to positions and frequencies files with: -DSPECIAL_FREQUENCIES_FILE=fgcom-data/special_frequencies.txt -DDEFAULT_POSITIONS_FILE=fgcom-data/positions.txt - Some minor changes for OSX: clenaing here and there, 10.5/6 i386/x86_64 universal support, individual (or macports) plib 1.8.5/PLIB.framework support, skipping osx 10.4 support, update iaxclient thread policy etc. Most work have been done by Geoff McLane with this cmake support now, many thanks to Geoff working on all this stuff and help to incorporate my osx changes to ONE single branch for all platforms. fgcomx as another fork on gitorious have been deleted. Now we need some testers and reporters for all platforms. When you want to help please checkout master and compile fgcom for your platform, install it and make echo tests or use it with your flightgear version. You will need current simgear and other dependencies of course (see readme, cmake 2.8, plib, OpenAL and current simgear needed). Thanks a lot, Yves PS. For next macflightgear release I would recommend to skip the old and buggy fgcom shipped with and replace it with a new build from this fork. After successful testing of course. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AirwaveXtreme150 Hang glider converted to JSBSim
Thank you once more for your efforts. The merge is done, just that everyone knows. Chris Hugo Meier wrote: Hello, after bringing back airwaveXtreme150 in February I noticed that a hang glider without environment interaction is unacceptable. Therefore a conversion from UIUC to JSBSim was due. The aim of my February release was the restoration of the original state, where I tried to change as less as possible. In contrast to this the JSBSim-Version is an extensive further development: - more realistic appearance (e.g. twisted wing) - added legs and shoes - running animation - view animation - highly configurable - FDM is more or less a 1:1 conversion from UIUC to JSBSim (No weight shift - this is planned for another hang glider in the future) Note the difference in reference system on ground and in air: On ground the glider rotates around the pilot and in air the pilot rotates in the glider system (animation and FDM). If something is going wrong in flight, don't hesitate to press } and a rescue chute will open. AirwaveXtreme is now a 3 in 1 hang glider: You could configure it as a novice (single surface, kingpost), intermediate (double surface, kingpost) or high performance (double surface, without kingpost) hang glider. Also individual colors and wheels could be chosen. Since real life hang gliders are built in different sizes to match different pilot weights a Performance Settings menu allows you to configure pilot weight, sail area and glide ratio. All appearance and performance settings could be chosen independently. In order to prevent inexperienced users to configure weird unrealistic settings a few pre-configured versions are also available. Flying this hang glider is great fun. I found that flying in ridge lift conditions close to the terrain is (and looks) quite realistic. With appropriate wind settings a astonishing good agreement compared to real life is achievable. I really think this hang glider simulator could assist hang gliding instructions (e.g. flying and landing in strong wind conditions; demonstrating the considerable increased sink rate in the lee of mountains) and if you once tried the cold front weather scenario in FlightGear you will never ever try this in real life! Recommended flying sites: A very beautiful site is the real life hang gliding launch Hafelekar which is located near LOWI (--lon=11.377417 --lat=47.30525 –heading=180 --on-ground). Choose 15kt wind from 180deg for all altitudes and soar up to the summits. A more challenging flight is Fort Funston near KSFO. It's a famous hang gliding site located at the coast with an altitude difference of only (250ft). Unfortunately directly at Fort Funston the FlightGear terrain is too smeared to produce sufficient ridge lift but a little bit further south (--lon=-122.4942234 --lat=37.6980674 –heading=270 –on-ground) ridge lift works perfectly. Choose wind with 20kt from 270deg. Be careful with the angle of attack on ground. Turn left after launch and fly very close to the cliff. Play with the performance settings to explore their influence on sink rate and wind-penetration. My original plan was to release this hang glider after I finished everything without any bugs. But I have to learn that modeling an aircraft in FlightGear is a NON-convergent process. Every time I implement one feature I get ideas of two new ones. However I think that the actual state is worth to be released. Known issues are - kingpost contact point is not working - FDM on ground not complete (only pitch input is taken into account) - multiplayer: generic variables (e.g. for running animation) don't work For the latter issue help from the experts is highly appreciated (and needed). The versions settings are transmitted correctly but customized colors, the various toggles and the variables for running animation (all defined in sim/multiplay/generic) do not work. I am at a loss. Still missing features are winch and aero-towing. It's a shame that aero towing is not yet implemented since we have towing planes (Dragonfly / Flash2A) in FlightGear since years. This isn't realistic at all. In real life hang glider pilots are always looking for tow planes and not vice versa. :-) The files are already waiting for a merge. This is my first merge request. Hopefully everything is fine. See you in the air. My dream is seeing a bunch of hang gliders at the same time and at the same site in multiplayer. All with different colors and performance settings like in real life! Best regards D-NXKT -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats.
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
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
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] [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
[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] 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
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] 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] 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
[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] 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
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] 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] 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] 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] 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
[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
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
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 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 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: 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 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
[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 and 2 Arc Second elevation data
Martin Spott wrote: We're not yet there. On a first test earlier today, 'genapts' ended in a segfault with the recent changes but I ran out of time, thus I have not yet verified if the source change in 'simgear' really was the culprit, Confirmed here. And I thought first it was the new terragear Doing a debug session now... -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear and 2 Arc Second elevation data
Martin Spott wrote: We're not yet there. On a first test earlier today, 'genapts' ended in a segfault with the recent changes but I ran out of time, thus I have not yet verified if the source change in 'simgear' really was the culprit, Confirmed here. And I thought first it was the new terragear Doing a debug session now... -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
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-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
[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] 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
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] 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] 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] 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] 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] 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] 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 - 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, 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 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] 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] 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] 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] 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
[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] 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
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
[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
[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
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
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
[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] 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
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
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
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; 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] 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] 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] 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
[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] 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
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
