Re: [Flightgear-devel] Autumn colors
I'm not sure this is necessary. I think an opt-in checkbox would suffice. After all FlightGear has been around for personal experiments for a very long time. So why not this option. I don't mind leaving it - the rational for deleting it is that the texture sheets take up space and download bandwidth and the shader instructions take up GPU registers for everyone - even those who are not interested. So, let me just try to explain better, because we do have a case study to see what's likely to happen next. Lauri introduced the skydome shader a while ago. That was controlled by Rayleigh, Mie and density sliders. I think these are pretty technical terms - I'm not sure the average user knows or is interested in what Rayleigh scattering is. So we have a new project with impressive graphics arriving on the scene. What was the reaction? The developer community largely supported it, someone coded a place in the GUI. What I did not hear are Mathias' remarks that all this is a very bad idea and Lauri should have done it differently. I did not hear that Rayleigh, Mie and density are complicated concepts and we need to simplify that because the user gets confused otherwise. I did not hear that cranking density all the way down or up it is completely possible to generate an airless Mars-sky or a super-dense greenish gas giant atmosphere and that we need to prevent the user from moving the sliders that way. I did not hear that we shouldn't implement this because it produces glaring graphical artefacts due to the mismatch with the terrain shading. I did not hear that it doesn't work under any amount of heavier fog, because the skydome is never fogged. The user by and large community loved it. There are series of screenshots from the time where you can see that users happily accept playing with Rayleigh and Mie, accept looking at obvious mismatches with the terrain just to get the sky pictures. (Well, there was one rather critical voice - that was me. But since I believe in constructive criticism, I didn't point out the flaws before I had read up O'Neill's original article, concluded that he doesn't understand what he's really solving, re-derived the scheme from scratch by just solving the integrals analytically, and then concluded what was missing in order to make things realistic, and when I started pointing out the flaws, I could offer a clear path to correct them. As it turned out, I also ended up implementing it myself.) We may conclude that the user loves shiny and exciting graphical features, is willing to accept an un-intuitive GUI that can produce unrealistic outcome and is even willing to accept massive graphical artefacts under some conditions. The funny thing is - when I finally fixed the artefacts by writing the matching terrain shader, THEN everyone started complaining why effect XY didn't work any more when the skydome was on. It was irrelevant that the artefacts matching terrain and skydome were gone, but the fact that one could not longer have bumpmapped planes together with the skydome shader really bugged people. We may conclude that the user *really* loves shiny graphics, no matter the cost otherwise. (Btw, - could anyone tell Mathias what the end user wants? The user wants an ubershader - that's the single most requested feature I had to deal with in the last year...) Of course, the skydome shader is a non-trivial beast with lots of dynamics in, so once one changes from the isotropic default skydome to the dynamical beast, the minimal matching terrain shader suddenly uses 220 lines of light and fog code rather than just 2 lines. Pretty much anyone can tell you that if you make a system 100 times more complex, it's going to take some time to get it free of all trouble. At which point it's very helpful if the surrounding community realizes that simple fact and tries for some constructive input - which may be as simple as one or two more folks who explain forum users how the FG shader system works and why effects can't simply be switched on in a new framework and why this is not a bug, or helps by diagnosing flaws rather than just pointing at them. It turns out that in the event I was also able to remap the Rayleigh/Mie/density parameter space to a 2-parameter space covering all the situations relevant for the Earth atmosphere, ths preventing unrealistic input, handing one of the new parameters to the weather system and leaving the other under user control. In principle this implies we could have removed the Rayleigh/Mie/density control - but when I asked if that should be done, the decision was made here to keep it (!). So, what do I learn from that case study as it applied to a potential procedural season model? 1) Users are likely to love it, no matter if the GUI has three additional sliders or not. Enthusiastic forum responses seem to confirm that. 2) In the case of the skydome, I was able to get a heuristics throwing out the
Re: [Flightgear-devel] Textures bug
__ Od: Arnt Karlsen a...@c2i.net Komu: flightgear-devel@lists.sourceforge.net Datum: 31.01.2013 02:15 Předmět: Re: [Flightgear-devel] Textures bug On Sat, 26 Jan 2013 16:18:14 +0100, mer...@centrum.cz wrote in message 20130126161814.7b021...@centrum.cz: Hello, with current Git version of Flightgear, i'm experiencing textures bug. See screenshots. http://www.imagehosting.cz/?v=fgfsscreen.jpg http://www.imagehosting.cz/?v=fgfsscumu.jpg http://www.imagehosting.cz/?v=fgfsscxcx.jpg http://www.imagehosting.cz/?v=fgfssccic.jpg I tried many combinations of Rendering options and some commandline options without success. I'm running Ubuntu 12.10 with radeon driver. ..first verify you have _all_ the firmware this driver needs, on Debian we need firmware-linux-nonfree for the KMS stuff, Ubuntu is similar. E.g. dpkg -l |grep firmware-linux I don't think I need this. But: $ dpkg -l | grep firmware ii linux-firmware 1.95 all Firmware for Linux kernel drivers $ sudo apt-get install linux-firmware-nonfree It didn't make any difference. ..later, you are also able to test with the radeonhd and fglrx drivers and post the output and pix of FG runs with those drivers, to help pinpoint the bug you found. These latter 2 drivers require you disable KMS, and possibly even a reboot. I cannot use fglrx because none of my cards is supported by current version of this driver. Gnome Shell didn't work with it in previous version. I don't like binary blob, made my computer unstable. I tried two different graphic cards with the same result. RV630 [Radeon HD 3600 Series] Cape Verde PRO [Radeon HD 7700 Series] $ ./run_fgfs.sh --version FlightGear version: 2.11.0 Revision: 11f15a9b36ef3ca8e1bdc53b52e9e7f316ccc102 Build-Id: none FG_ROOT=/media/mermar/aaa/fgfs/install/fgfs/fgdata FG_HOME=/home/mermar/.fgfs FG_SCENERY= SimGear version: 2.11.0 PLIB version: 185 There are no error messages in the console. With version 2.6 from Ubuntu repository, I'v got the same wrong output. Version 2.4 worked fine. ..does it (FG-2.4) _still_ work fine? ..if you no longer have it installed, you should be able to install it adding a deb line from whichever older version Ubuntu you had when you had FG-2.4, and install FG-2.4 with e.g. aptitude -t experimental install flightgear (modify as you see fit, experimental - your old Ubuntu version), and test it with your current Ubuntu's radeon, radeonhd and fglrx drivers. I didn't manage to install version 2.4, but e.g. 0ad seems to run just fine. Is there something I can do to fix this? Or can someone please help me? ..first, the exact commandline you use to start FG, then the output from that commandline in that xterm. If this is a radeon bug, the radeon team will have a bunch of things they want you to do. Do you have reportbug installed? If not, install it now, e.g. reportbug radeon gives you a nice intro guide on writing bug reports. Don't know what is and what to do with reportbug. Exact commandline with current git: $ ./run_fgfs.sh Enabling ATI viewport hack KMA20 audio panel initialized KI266 dme indicator #0 initialized loading scenario 'nimitz_demo' Trim Results: Altitude AGL:4.4 wdot: 2.00e-04 Tolerance: 1e-03 Passed Pitch Angle: 0.047 qdot: 7.59e-05 Tolerance: 1e-04 Passed Trim Statistics: Total Iterations: 61 Sub-iterations: wdot: 219 average: 3.5902 successful: 0 stability: 2 qdot: 131 average: 2.1475 successful: 61 stability: 2 Run Count: 1322 Electrical system initialized KAP140 power up $ I found two forum topics with the same problem: http://flightgear.org/forums/viewtopic.php?f=37t=18921 http://flightgear.org/forums/viewtopic.php?f=37t=18964 So the problem persists, but thanks for your help. Martin M. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- 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_d2d_jan ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- 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/
Re: [Flightgear-devel] Autumn colors
Hi THorsten, On 02/16/2013 09:13 AM, Renk Thorsten wrote: So, let me just try to explain better, because we do have a case study to see what's likely to happen next. I really want to respond to all this but I feel I'm not really entitled to because I did little coding for FlightGear the past two years. Let me emphasize that while I joined FlightGear because it really was an accurate simulator rather than in-flight game concept like all the other simulators at that time I do bribe about FlightGear these days, pointing out the realistic weather conditions for soaring for example. Your work is highly appreciated by many and please take criticism more like there's room for improvement in this area rather than your implementation is rubbish because it's not .. 99% of the time which is a great achievement! Your comments do let me believe that an opt-out checkbox might indeed be a better idea. The user base of FlightGear Starts to shift from 'real aviation/simulator enthusiasts' and more towards users who are used to Microsoft Flight(simulator). The latter will be impressed by many other things than the accuracy of the Flight Models (which is more or less taken for granted nowadays). Anyhow, don't feel frustrated. Take criticism for what it's worth and reject it if it sounds unrealistic. Also there's no need to defend yourself every time, you for one have proven yourself to be highly capable at your area of expertise (which for FlightGear was sparse until now). Erik -- http://www.adalin.com - Hardware accelerated AeonWave and OpenAL for Windows and Linux -- 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: final tags for 2.10.0
Am 15.02.2013 16:16, schrieb Torsten Dreyer: If no one shouts out loudly _NOW_, I'm going to tag the release branches tomorrow (Saturday) morning (Central European Time) and give the package managers the GO to build and distribute the bundles. That should give us a ready-to-download release just in time on Sunday the 17th. Done. The tag version/2.10.0-final exists on fgdata, simgear and flightgear. Please start creating the tarballs, installers, binaries et.al. for the final FlightGear 2.10 release from that tag. FWIW, I have also merged the release/2.10.0 branch into the master branch on simgear and flightgear. Both had conflicts on a few files. I resolved these conflicts by checking out the files of the release branch (git checkout --theirs while sitting on master) and committing those versions. This has been documented in the merge commit. There is still one open item: To push the final pdf and html documentation to the mapserver site. I do not have write access, so may please somebody who knows how to do that and is able to do so take care of it? Torsten -- 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
Hy Yves Sorry, I do not understand your question. Could you clarify, please? Torsten Am 16.02.2013 00:17, schrieb ys: Hi Torsten What does mean no public answer in this list for this decision ? -Yves Am 15.02.2013 um 16:16 schrieb Torsten Dreyer tors...@t3r.de: Hi all, at one point during every ILS approach you reach the decision altitude with two options: continue approach or go around. Being the copilot on our approach into the 2.10 release, I'd call out minimum, approach lights in sight, continue! If no one shouts out loudly _NOW_, I'm going to tag the release branches tomorrow (Saturday) morning (Central European Time) and give the package managers the GO to build and distribute the bundles. That should give us a ready-to-download release just in time on Sunday the 17th. Greetings, Torsten -- 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 -- 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 -- 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: final tags for 2.10.0
Hi Torsten, De : Torsten Dreyer tors...@t3r.de Envoyé le : Samedi 16 février 2013 10h48 There is still one open item: To push the final pdf and html documentation to the mapserver site. I do not have write access, so may please somebody who knows how to do that and is able to do so take care of it? To my knowledge, this is a fully automated task, which is croned at each update. So for the online stuff everything seems to be fine. The only thing I do not know is who is taking care to update the getstart.pdf files pushed into the installers and tarballs for the release. -- 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: final tags for 2.10.0
To my knowledge, this is a fully automated task, which is croned at each update. So for the online stuff everything seems to be fine. The only thing I do not know is who is taking care to update the getstart.pdf files pushed into the installers and tarballs for the release. Ah, good news. I just love automated tasks ;-) Stuart took care of the getstart.pdf for this release, so I assume we are all set w.r.t. documentation this time. Thanks Torsten -- 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] OSX 10.5 compilation
On 15 Feb 2013, at 23:56, ys flightg...@sablonier.ch wrote: Ok, can we have a decision that SimGear/FlightGear is not supporting OSX 10.5 on intel anymore ? FG 2.8 is doable, and maybe 2.10 with some further tweaks too, but after looking to what's coming up with next I see that more and more tweaks are needed and that core developers do not take 10.5 into account anymore (what I can understand very well, but it's not mentioned anywhere, when I'm not wrong). Fact is that all dependencies still supports osx 10.5 on intel, but sg/fg doesn't anymore (since 2.8 this is also posted at flightgear.org for mac release, = 10.6). As stated by James sg/fg code is not tested against 10.5 by core developers anymore, so please ... I my view a small message should come to changelog which can be referenced by supporters at forums and elsewhere for this fact. Or do you think this is completely wrong ? Hmm, I'm not sure what to say - I'm not aware of any 'upcoming' stuff in next that makes 10.5 support harder. There's changes, e.g. the file-dialog stuff, if it does't work with 10.5 (and I've no idea if does or not), can simply be #ifdef-ed based on the system version. That's the *only* think I can think of in next which would affect system support. And I maintain, that 10.5 support is pretty doable with the 2.10 codebase, or 'next', if someone wishes to invest some time. So making an 'official statement' seems a bit silly - just like it would be odd to make a statement saying we don't support FreeBSD or Cygwin or Windows 2k. I imagine some of those platforms need a similar amount of tweaking to Mac 10.5, to work out of the box, since no one tried them in years, but if someone cares to make them work, they will work - and I'm happy to apply patches to support them, so long as they don't break existing stuff. (Actually I think FreeBSD does work, precisely because someone did that work, for 2.8) So we can make such a statement, and if someone asks, the reason for making the statement, is because you asked for such a statement! - but I don't really see who that benefits? It will still be possible to #ifdef some code and support 10.5, if there's a person interested / motivated enough to make it happen. Regards, James -- 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] Iceland textures
Did you test your airfield grass with some of the newer generated terrain (LOWI in my case)? No, I didn't. Shouldn't make a difference for rendering purposes how you created it, at this stage it's all vertices and pixels and the shaders don't care where they come from or how they connect. Noticed that despite the surrounding area got some light snow cover the airfield are had no snow cover. It *should* get some, although not quite the same as terrain, just like the runway should get some cover, but considerably less than terrain (I think I know how to keep roads free of snow, so that's going to come as well). Beside that i noticed some small transparency issues with 8.5 markings / lines. All the 8.5 lines have a small white boarder that is not visible without the atmospheric light scattering enabled. I'm not sure how much the shader can affect this - as I said, at this stage it's all vertices and pixels. We have seen some taxiway marking issues reported in the forum http://www.flightgear.org/forums/viewtopic.php?f=5t=19097 is the problem perhaps somehow similar? Otherwise, is there perhaps a flaw in the underlying geometry that isn't apparent in the default rendering but becomes apparent using Light Scattering? Since the scheme uses much more properties of the geometry (default essentially uses only z-depth of the fragment) it is also more prone to producing artefacts if there is an actual flaw in the geometry (I've seen fog clinging to bad terrain meshes, I've seen illumination discontinuities where there is a 2 m elevation jump in the water, there's the skydome flaw,...). * Thorsten -- 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] OSX 10.5 compilation
Hi James I'm still trying to be this 10.5 person these days, I don't give up that fast of course ;-) And I spent a lot of time this week in this believe me. It started with having all dependencies right, and now I'm still trying to get simgear/flightgear the right way. When I succeed I will need some tests (by real 10.5 users, but also by users up to 6/7/8). I will clone the sg/fg repositories and add the directives, send some merge requests. Actually there are only two small changes in code checked in by you: The cocoa clipboard code in flightgear source (the patch I already sent), and in simgear svn_cmdline_create_auth_baton and svn_client_checkout3 which can't be used with sdk 10.5. But the alternatives here are already in place, it just needs a clever directive using the SVN_VER_MINOR already there. I got also the sound working now for 10.5, and I'm actually building a FGx 2.10 against SDK 10.5. When I succeed I will post a download link at forums to test, and then I will bring the small changes I made to a clone/merge request to verify. Thanks, Yves Am 16.02.13 15:15, schrieb James Turner: On 15 Feb 2013, at 23:56, ys flightg...@sablonier.ch wrote: Ok, can we have a decision that SimGear/FlightGear is not supporting OSX 10.5 on intel anymore ? FG 2.8 is doable, and maybe 2.10 with some further tweaks too, but after looking to what's coming up with next I see that more and more tweaks are needed and that core developers do not take 10.5 into account anymore (what I can understand very well, but it's not mentioned anywhere, when I'm not wrong). Fact is that all dependencies still supports osx 10.5 on intel, but sg/fg doesn't anymore (since 2.8 this is also posted at flightgear.org for mac release, = 10.6). As stated by James sg/fg code is not tested against 10.5 by core developers anymore, so please ... I my view a small message should come to changelog which can be referenced by supporters at forums and elsewhere for this fact. Or do you think this is completely wrong ? Hmm, I'm not sure what to say - I'm not aware of any 'upcoming' stuff in next that makes 10.5 support harder. There's changes, e.g. the file-dialog stuff, if it does't work with 10.5 (and I've no idea if does or not), can simply be #ifdef-ed based on the system version. That's the *only* think I can think of in next which would affect system support. And I maintain, that 10.5 support is pretty doable with the 2.10 codebase, or 'next', if someone wishes to invest some time. So making an 'official statement' seems a bit silly - just like it would be odd to make a statement saying we don't support FreeBSD or Cygwin or Windows 2k. I imagine some of those platforms need a similar amount of tweaking to Mac 10.5, to work out of the box, since no one tried them in years, but if someone cares to make them work, they will work - and I'm happy to apply patches to support them, so long as they don't break existing stuff. (Actually I think FreeBSD does work, precisely because someone did that work, for 2.8) So we can make such a statement, and if someone asks, the reason for making the statement, is because you asked for such a statement! - but I don't really see who that benefits? It will still be possible to #ifdef some code and support 10.5, if there's a person interested / motivated enough to make it happen. Regards, James -- 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 -- 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] OSX 10.5 compilation
Am 16.02.13 18:54, schrieb HB-GRAL: I got also the sound working now for 10.5, and I'm actually building a FGx 2.10 against SDK 10.5. The sound problem is not related to 10.5 of course, I got the sound working for arch i386 and sdk 10.5/6 (x86_64 worked from beginning, building against sdk 10.6). There are four possibilities that made it running finally now, independent of the machine, I don't know which one (or all of this?) I should take into account for my build, I will check all of this again: 1) building against OSG 3.1.3 instead of trunk (3.1.5) 2) rebuilding plib and not using macports plib (at least for 10.5 this is necessary anyway because I can't use 10.6 macports plib of course) 3) enable fgpanel and getting glut with this (huh?) 4) building with RTI=off But I'm only talking to myself here, sorry for that. I promise I will get more overview soon and shut up. -Yves -- 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
[Flightgear-devel] BufferedLogCallback in simgear
Hi James I guess this is the next commit https://gitorious.org/fg/simgear/commit/318c5000ce58a07a279053f084a28faaef5c422d that breaks simgear compilation against osx sdk 10.5 and target 10.5 on intel (for 2.11, and I get no problems against 10.6): Output: simgear/simgear/debug/BufferedLogCallback.cxx: In member function ‘unsigned int simgear::BufferedLogCallback::threadsafeCopy(std::vectorunsigned char*, std::allocatorunsigned char* )’: simgear/simgear/debug/BufferedLogCallback.cxx:92: error: ‘class std::vectorunsigned char*, std::allocatorunsigned char* ’ has no member named ‘data’ simgear/simgear/debug/BufferedLogCallback.cxx:92: error: ‘class std::vectorunsigned char*, std::allocatorunsigned char* ’ has no member named ‘data’ make[2]: *** [simgear/CMakeFiles/SimGearCore.dir/debug/BufferedLogCallback.cxx.o] Error 1 make[1]: *** [simgear/CMakeFiles/SimGearCore.dir/all] Error 2 -Yves -- 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] Manual update request (Was: Updated Short Reference for 2.10.0)
Hi Olivier, Stuart,
Current Manual on mapserver is broken at the midstream of section 8.10
(The autopilot).
And I noticed that unintentionally disappeared chapters exist:
Chapter 9, Chapter 10, Chapter 11, Appendix A, Appendix B
Maybe, Olivier's commit to basic.tex 15 hours ago was something wrong:
http://gitorious.org/fg/getstart/commit/4bb44e69eead605fd626a83e7535640b9ad908ce
I guess,
basic.tex line 1859:
\weblong{https://dealer.bendixking.com/servlet/com.honeywell.aes.utility.PDFDownLoadServlet?FileName=/TechPubs/repository/006-18034-_3.pdf}
should be
\weblong{https://www3.bendixking.com/servlet/com.honeywell.aes.utility.PDFDownLoadServlet?FileName=/TechPubs/repository/006-18034-_3.pdf}{https://www3.bendixking.com/servlet/com.honeywell.aes.utility\\.PDFDownLoadServlet?FileName=/TechPubs/repository\\/006-18034-\_3.pdf}
I also request minor (low priolity) corrections in section 5.2 (Keyboard
controls) of:
http://gitorious.org/fg/getstart/blobs/master/source/flight.tex
Lines 280-287 (Autopilot controls are as follows.):
-- should be deleted.
Line 306 and 309:
Table 5 and Tableau 5 shoud be Table 4 and Tableau 4.
Line 324 and 327:
Table 6 and Tableau 6 shoud be Table 5 and Tableau 5.
Line 341 and 344:
Table 7 and Tableau 7 shoud be Table 6 and Tableau 6.
Line 375 and 378:
Tab.\,6 and Tableau\,6 shoud be Table 7 and Tableau 7.
Lines 387 - 409 (When the autopilot is enabled...):
-- Please temporary comment out, because table contents (tab*.tex) for
Additional Autopilot controls is not currently prepared.
Cheers,
Toshi
--
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 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. On Fri, Feb 15, 2013 at 9:16 AM, Torsten Dreyer wrote: Hi all, at one point during every ILS approach you reach the decision altitude with two options: continue approach or go around. Being the copilot on our approach into the 2.10 release, I'd call out minimum, approach lights in sight, continue! If no one shouts out loudly _NOW_, I'm going to tag the release branches tomorrow (Saturday) morning (Central European Time) and give the package managers the GO to build and distribute the bundles. That should give us a ready-to-download release just in time on Sunday the 17th. Greetings, Torsten -- 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 -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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
