Re: [Flightgear-devel] Time option --start-time-gmt broken?
On Sat, Oct 29, 2011 at 11:55 AM, Durk Talsma wrote: Has anybody recently touched any time related functions? I'm trying to start flightgear with the commandline option --start-date-gmt=2011:10:29:16:30:00 When I look at the property browers, I see that time is listed as /sim/time/gmt=2053:08:26T09:xx:xx (note that I'm not giving the minute and second readings, because they're constantly updated. Any ideas? What might have caused this? Hi Durk, Does this option work properly in v2.4? Not to point fingers :-) but James did do some refactoring of the command line option handling post-v2.4. I ran into an issue yesterday which really had me spinning my wheels (couldn't specify multiple --generic options), but in the end it was a easy fix to enable multiple instances of some additional specific options.. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] fgdata: Important note
On Thu, Oct 27, 2011 at 7:09 AM, James Turner wrote: On 27 Oct 2011, at 12:58, Jari Häkkinen wrote: Sorry for the rant-like appearance of this message. No need to apologise, I'd say it's 100% accurate - including the lack of a single leader, the fact that project does 'okay' without very tight central leadership, mostly, and the attendant responsibility on the people making the decisions :) Let me add a couple comments -- Jari, think through the work load of what you'd like a single leader to do. To be intimately involved in all the major projects and efforts going on. Respond to every issue and question in a timely manner. Have a deep understanding of every corner of the code and the project. Now imagine people who have day jobs -- who might need to be focused on something else for a good chunk of the day so they can eat and provide shelter for themselves. Oh, and imagine some of these people could have families and kids and spouses that want to have some interaction once in a while. Oh, and not everyone lives on redbull and doritos so there needs to be some sleep planned into the schedule. Should a flightgear leader be allowed to take the night off to watch a sports game or visit friends? So just remember we are doing this all for free on top of all our other life commitments. Maybe I'm wrong, but I suspect that for someone to fulfill your expectations, they would need to be 100% full time dedicated to that single task. And if the FlightGear project can't offer full time pay to that person, how can we expect them to dedicate all their available work time to the task? From my perspective, the FlightGear project has grown way beyond what a single person can hold in their head all at once. This is why we work towards systems that distribute the load and give more access. We aren't perfect and maybe we don't always act quickly enough and certainly we all are human beings and are open for heavy criticism if that's the direction we would want to take this. We are a group of individuals coming together with a common interest. I would hope we realize our own limits and flaws and thus are a somewhat flexible when encountering the limits and flaws in other people. But yet despite our collective limits and imperfections, together we are doing our best to make positive contributions to this wonderful project. Best regards, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] CMake, tomorrow (Sunday 23rd)
On Sat, Oct 22, 2011 at 10:03 AM, James Turner wrote: Hello again, Barring last-minute objections, I would like to declare CMake 'the' build system, from tomorrow onwards. Since my last email I've added a README.cmake to flightgear, and I'm working on ensuring the 'make dist' features of automake are replicated in CMake (via CPack) so when 2.6 time comes around, we don't have too many surprises. My plan is to disable the automake builds on Jenkins tomorrow (Sunday), and then start removing the automake build machinery, and the projects/ subdirectory, from the simgear and flightgear source trees. (I can create a Git tag prior to removing any files, if that's of interest?) If there's lingering queries about Cmake, or requests on the 'best' way to handle the transition, please let me know. Feedback on the README file would be appreciated too, or even commits / patches to improve it! It might be a bit extra work, but it would be good to take the source.tar.gz files that cmake creates, unpack them in a new directory and just make sure we can do a clean build from them. This always seems to expose a file or two, or a header that someone forgot to add to the automake.am so it never got included in the source distribution. (i.e. you could build from git just fine, but things were missing in the source distribution.) These are usually easy to fix, but it's good to catch them earlier rather than later. Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Scenery Question on .fit files
On Thu, Oct 20, 2011 at 6:46 AM, Martin Spott wrote: Jason Cox wrote: is our data for heights taken from the chopped up DEM/HGT files or is the terrafit files used? Both. Array files are a mandatory requirement, terrafit output is for optional enhancement - from a quick glance I guess the respective code section should be this one: http://mapserver.flightgear.org/git/gitweb.pl?p=terragear-cs;a=blob;f=src/Lib/Array/array.cxx;hb=HEAD#l73 Anyhow I never attempted to translate the entire array output into terrafit format and just provide an empty array file as a dummy - might be worth a try ;-) This is off the top of my head, but I believe that the array file is used as the official elevation source when interpolating elevations of all the other elements. The fit file is the list of elevation nodes that are actually included in the output tile (along with any other points that are introduced because of polygon boundaries and things like that. We discovered (or were told) that you can approximate the same scenery with the same error tolerance using 4-6x fewer triangles -- if you use an adaptive mesh versus a regular grid. So the regular grid (array) file is used to interpolate elevations for any new points that are introduced in the tile, but the fit file lists the nodes of the irregular mesh that we use to approximate the terrain. Hope that helps. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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@Ciosco 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] FlightGear aircraft repository
, 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 -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] FGData Split Completed - a.k.a. Life after the Split
Question on the new repository layout: I would like to pull every aircraft from https://gitorious.org/flightgear-aircraft/ Is there a way to do this in a single command or do I have to manually identify each aircraft in the repository and manually clone it here? If someone adds a new aircraft to this repository, will it get automatically fetched on my next git pull or do I have to manually check for new aircraft and manually pull them each individually? Thanks, Curt. On Wed, Oct 19, 2011 at 8:59 AM, George Patterson wrote: On 19 October 2011 19:29, Cedric Sodhi man...@gmx.net wrote: https://gitorious.org/flightgear-aircraft Last night, the discussion came up where the above page is slow to load, in part it's due to 1.2MB of HTML code, plus the CSS, plus the any images in use. Not very browser friendly. I hacked together a php script that will parse a locally stored version of the above page and display urls to the individual aircaft projects. On irc, Zorg, Gijs and perhaps a few others in the #flightgear channel had a poke it and gave it a nod. Tonight I have improved it, and it now validates as XHTML 1.0 Strict. I guess, what essential information do we require from the above Gitorious resource page. I can add parsing of the each aircraft's RSS/atom feed, but will need to work on caching first. Currently I have been periodically fetching the above page and saving it as a static resource that is then referred to as requested. It should help those that are on slower connection or pay a high data rate for traffic. (Or those who are pressed for time. :-) ) The url is http://fgfs.dyndns.info/aircraft.php I haven't linked it from the front page ofhttp://fgfs.dyndns.info as yet. Regards George to officially publish your planes as part of the Flightgear project. 2. Assuming the answers are no, yes, to #1, will all these repositories be centrally located so one can track new or modified ac of interest? If you do not wish to publish your planes under the conditions outlined above, for instance because you don't want to use Gitorious or because your plane is not GPL, then, so Thorsten, you will not be entitled to be listed and tracked centrally (I personally don't agree with that). -- regards, ManDay -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] FGData Split Completed - a.k.a. Life after the Split
On Wed, Oct 19, 2011 at 10:14 AM, TDO_Brandano - tdo_brand...@hotmail.comwrote: Not automatically, as far as I know, but it should be relatively simple to script this. the main issue is how to script something that will work across platforms. I can do this in less than 20 lines of python, but of course not everyone has python installed on his windows machine We (someone?) definitely needs to do something here. I'm sitting here now having cloned the fgdata-new repository with zero aircraft and zero instructions for fetching them. I know enough git and I know the root path, so I could go do this -- but for 350 aircraft, this would be weeks of manual work interleaved with lots of waiting to get all of them and then a major pain to update them all in the future or notice and fetch new aircraft. Sure we can script it out, but do I have 2-3 days right now to fiddle with a script? Not this week myself. What about new users coming to the project? We need to have some instructions and a reasonable mechanism that works for everyone. Right now we've replaced a one-line command with several weeks of manual work. (Or so it appears.) I understand the reasons, and we need to move forward, but I think this is a logic gap here -- an unforeseen side effect, and a problem we (someone) needs to scramble on to address. Anyone have any good ideas? Can anyone knock something out quickly? With svn you can just checkout the top level, or checkout any subtree underneath that individually. Is there any similar concept with git? Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] FGData Split Completed - a.k.a. Life after the Split
On Wed, Oct 19, 2011 at 10:48 AM, James Turner wrote: The intention is create a super-module which has each aircraft as a submodule. Eg an 'all-aircraft' repository, for people who want this. Ideally someone with some scripting skills would automate creating that repository, and then we're back to a few steps: clone init submodules pull (which will recursively pull, and take ... some time) Hi James, A super module sounds ideal if that's doable in git. Looking forward to it! For now, maybe I have to sluff along with the aircraft from the old fgdata repository. Thanks! Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] FGData Split Completed - a.k.a. Life after the Split
On Wed, Oct 19, 2011 at 11:03 AM, Curtis Olson wrote: Hi James, A super module sounds ideal if that's doable in git. Looking forward to it! For now, maybe I have to sluff along with the aircraft from the old fgdata repository. Replying to myself: Once we have a super-module for all the GPL aircraft in our central repository, it would be interetesting to begin work on a 2nd super-module for all the available externally maintained aircraft repositories we can find. Thanks once again, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] FGData Split Completed - a.k.a. Life after
On Wed, Oct 19, 2011 at 11:03 AM, Martin Spott wrote: Curtis Olson wrote: Anyone have any good ideas? Yes, revert the dissection of 'fgdata' until a practical solution is in place which doesn't require lots of people to waste extra time just to achieve the previous state which simply works for them. Spending some thoughts on how to compensate the drawbacks of a split repository wouldn't be bad either. We certainly are discovering that git is not the perfectly elegant solution for every situation. Splitting the repository certainly has it's own set of issues and challenges and in the end do we still end up with the exact same challenges as when we started along with some new ones we add? I'm willing to be frustrated in the short term and run with the decisions of some of our trusted developers, but I sure hope we have at least a few people who are willing to scramble here right now and help us work through these issues and also help document the new process for new people just arriving. We can't depend on (or force) everyone to get a phd in git to participate in the project and forcing people to run scripts or install a scripting language is also a huge addition of complexity to our once relatively simple system. I'm not looking forward to downloading another 8Gb of aircraft repositories spread across 350 clones, but I'll do it since that's the direction we are going, but will a super module buy us much over the situation we just came from? Will we still have one huge download? Now we have an 8Gb download instead of a 9Gb download? Or we have to manually do all the individual aircraft, or we require everyone install python and learn how to launch scripts (and edit paths, etc.) Are we advancing the ball here? And if we are, let's make sure we don't drop the ball or cough it up with a bad pass (depending on what sports analogy you prefer.) Trying to be patient!!! I know this stuff takes time. It helps to be patient if I know someone is addressing these concerns and we'll have a reasonable solution in a timely manner. It just stresses me out to get caught in limbo. I am not a git-guru, and I can script, but I don't have time right now to spend 3 days on what used to be a single command I could copy/paste into my terminal. Thanks! Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] FGData Split Completed - a.k.a. Life after the Split
On Wed, Oct 19, 2011 at 11:03 AM, Curtis Olson wrote: A super module sounds ideal if that's doable in git. Looking forward to it! For now, maybe I have to sluff along with the aircraft from the old fgdata repository. Hi James, One more super module question: if I start plowing through 350 aircraft by hand, and then next week you come out with a super module, will that require me to redownload everything, or can that be retrofitted on top of the modules I've already fetched? Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] FGData Split Completed - a.k.a. Life after
On Wed, Oct 19, 2011 at 11:55 AM, Martin Spott wrote: A super module sounds ideal if that's doable in git. Looking forward to it! Gitorious will be pleased if everybody starts pulling everything from scratch - and developers will be pleased by Gitorious' performance when everybody starts pulling everything from scratch. Previously there was a packaged bare repository for download via HTTP to start from in order to save Gitorious from the load and to save the developer from waiting hours until the fetch was complete And I presume that this package has been made invalid since it points to the old fgdata repository, and it will be substantial work to bring it up to match the new fgdata + all the aircraft? So I'm still sitting here with zero aircraft, and not being sure I want to start down the path of a lengthy manual process that will need to be redone anyway, or a lengthy scripting session (that might have to be run many times before it's completely debugged.) Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] FGData Split Completed - a.k.a. Life after
My main point (or thought) is just that if we are going to push forward with this split, then we need to go the whole way and make it work reasonably for everyone. The people pushing this and doing the initial work, can't just take it half way and then leave it because their personal concerns are dealt with. They need to consider the broader user and developer base and make sure our new approach and structure isn't a significant regression or inconvenience for people. It's one thing when you are in your own sand box, but this is the whole playground we are redoing, so their is a much more significant responsibility for making this work really well for everyone. I was reacting to the series of emails that indicated the split was done, everything is finished, nothing more to see here, every one move along -- but I'm sitting here with zero aircraft and a major hassle to get them all back and keep them updated. Gijs has indicated that we are going to have a do-over which is fine -- I've done enough sys admin stuff to know that it usually takes a couple tries to catch all the lose ends. When I install a new OS on a PC, I'm usually in it for 6-12 attempts before I get all the partitioning and configuration options just the way I want without messing something up critically in the process. ;-) I just want to make sure that we are considering the different issues and concerns; that the process and end results are being thought through carefully; and that those doing the leg work on this (and pushing the change strongly) don't leave it half baked because we ran into a problem that no one considered and no one knows what to do about it, and the original people are happy enough with only a 1/2 dozen aircraft to play with. Thanks! Curt. On Wed, Oct 19, 2011 at 12:41 PM, Jari Häkkinen wrote: I actually lost track of who is doing what in the splitting of fgdata but there is a tremendous response pointing out issues related to the split. I want to express support for the splitting team. I support the split if only for the reason that aircraft maintainers will get commit rights to their private spheres in fg-land (if I understand things properly). With the previous monolithic fgdata only a selected group of people had commit privileges. Once the dust settles I think we will see the benefits of giving aircraft developers direct access to their repos. At least the need for setting up other repos will decrease (assuming that not all aircraft developers are anti-GPL) because I think one major reason for setting up external repos are (lack of) commit privileges in fgdata. For those of you who are impatient with the progress, is the now frozen fgdata unusable? Why not stay with it until the new fgdata is to your liking? I haven't pulled the latest fg-state lately so I don't know if this is possible to stay old-school? Cheers, Jari -- 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@Ciosco 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 -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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@Ciosco 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] FGData Split Completed - a.k.a. Life after the Split
On Wed, Oct 19, 2011 at 1:45 PM, Jacob Burbach jmburb...@gmail.com wrote: Seems like most people are just banging their heads against the wall trying to make a new system the same as the old, which is counter productive and unfortunate. It is highly unlikely ANYONE needs every single aircraft from git that they were previously forced to take, which is the whole point of the change. If people are honest with themselves I think they would realize they only need such aircraft that they plan to use or do development on. Personally I am extremely happy that I will no longer need to pull down hundreds of aircraft I have no intention of ever touching just so I can work on and test development new development in flightgear. In the end this will make it much, much easier for new developers and testers to get up and running and get to work. A developer that needs to make download packages for every available aircraft? A developer that wants to check if a source code change will impact the available aircraft (or gauge what the level of impact would be if they made a particular change.) A developer that needs to update code, and also fix all the associated aircraft to track a code change. A user who likes to be a collector and have everything available to browse through whether they plan to use a particular aircraft today or not. I could probably think of many more if I thought for a while longer. We can't be short sighted here and do a major regression that causes problems for a lot of people, just because there are some vocal people who don't have a personal need for every usage case. I know we all worship at the alter of git, but isn't the main problem here is that we are forcing everyone to download the complete binary history of everything in the data package, and this is not scaling well for us? If we put it to a vote, I wonder how our general user population would respond to: Do you want (a) the entire binary history of everything (b) the entire set of aircraft. We are committed to git, I'm not suggesting otherwise, but the entire binary history of the data tree is pushing 10Gb. My understanding is that splitting off the aircraft wouldn't reduce the total size, but would allow us to deal with smaller chunks and optionally cherry pick just the parts we want. But if the result is that it is an immense effort or very difficult to get all the data and all the aircraft for people that want it (for any reason) then we have a problem. Telling them they don't need it and shouldn't download it is not really a good answer. Here's another way to look at it. We need to keep policy and capability as separate as possible. If we end up with significantly reduced capability, just redefining our policy is going to make a lot of people unhappy. Ideally we should find a solution that offers the required capabilities to support different policies. People that just want a few aircraft can establish that policy for themselves, people that want all the aircraft can establish that policy for themselves. We can't go around telling people what they should want or what they should do in response to taking something away from them and implying there's something wrong with them if they think otherwise. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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@Ciosco 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] Cmake (soon)
Hi James, Thanks. I was off line all day test flying our UAS so it looks like I have some serious catch up to do here on several fronts. :-) Curt. On Tue, Oct 18, 2011 at 3:40 AM, James Turner zakal...@mac.com wrote: On 17 Oct 2011, at 18:38, Curtis Olson wrote: Would it be possible to write a quick howto for doing some basic coding/developer things in cmake. Like: how to add a new source file to the project. Or how to add a new module/library to the project.Maybe a few quick summeries of how to install in a custom directory, how to build with custom compiler options, how to configure for debug vs. release build, or some the more subtle build options that invoke different levels of optimizations or warnings. I've written this up, at least a first attempt, will commit it later today, and people can review it for sanity / correctness / omissions :) Either that, or our cmake experts need to be willing and ready to respond to frustrated dumb questions in a timely manner -- and do that over time if we don't have central place to find this information without investing the required time to become cmake experts ourselves. I'm assuming that's true regardless :) James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Cmake (soon)
Hi James, One thing that stresses me out is large scale technology changes with no documentation or howto's to back them up. This change might be fine for people who are cmake experts. And I know anyone can start from scratch and read the cmake manual from cover to cover. But that takes time and a lot of effort, and there is not enough time in our lives to be experts in everything, but we often need to know some basics in just about every subject. Judging by the number of tweaks and changes I see through the change logs that are cmake config related only, there is a lot of subtle nuance and expertise required to make cmake do the equivalent of autoconf/automake (and the auto tools required a lot of expertise too.) Would it be possible to write a quick howto for doing some basic coding/developer things in cmake. Like: how to add a new source file to the project. Or how to add a new module/library to the project.Maybe a few quick summeries of how to install in a custom directory, how to build with custom compiler options, how to configure for debug vs. release build, or some the more subtle build options that invoke different levels of optimizations or warnings. Either that, or our cmake experts need to be willing and ready to respond to frustrated dumb questions in a timely manner -- and do that over time if we don't have central place to find this information without investing the required time to become cmake experts ourselves. Thanks! Curt. On Mon, Oct 17, 2011 at 12:10 PM, James Turner wrote: It's been a month since I announced the intention, to switch all the main FG platforms to use CMake, and to deprecate and remove the other build systems from Git. There's been many small improvements in the Cmake files since then, which I hope have eased some people's concerns about the switch. (Notably Brisa' compile scripts have been updated to use Cmake!) I still have some work to do, to ensure the 'make dist' rules are handled property in CMake, so we don't get a shock when releasing FG 2.6 in a few months. Are there are any other issues people have, areas they think should be tested, etc? I'd love to know the status of cygwin and mingw, but only people who run those environments can test or improve them. Barring last minute surprises, my intention is to declare the other build systems 'dead' next weekend (the 21st), and then gradually start disabling Jenkins jobs, removing files, and so on. The idea is to force everyone who runs FG from Git, to definitely be testing and using CMake, in plenty of time for the 2.6 release. Regards, James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] SGMath headers
On Mon, Oct 17, 2011 at 7:01 PM, Csaba Halász wrote: While investigating a reported compilation error, I had a look in the SGMath headers. I noticed some of them don't properly include their dependencies (for example, SGMisc is missing SGCMath, SGGeodesy is missing SGVec3 and SGGeod, etc.). I am wondering if they are supposed to be available for standalone use, or only via the SGMath.hxx header, which does at least try to include the dependencies (even though it doesn't get the order right.) Hi Csaba, I brought this up one time myself, and I believe the intention for the math library is that you will include SGMath.hxx first and then everything else is included automatically. Regards, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] fgdata is frozen!
Hi Thorsten, One question: if we have our own local branches of the fgdata repository for our own experimentation, will it be straightforward to hang these off the new repository? Thanks, Curt. On Sun, Oct 16, 2011 at 2:31 PM, ThorstenB wrote: Jorg and Gijs are working on the new fgdata repo now. Therefore the existing fgdata repo is frozen as of now - even commit privileges are removed - hopefully permanently for the (historic) fgdata repo. They'll start a new (temporary) repository. Once the new repo is all setup and working as expected, we'll switch (shuffle the names) and add committers. cheers, Thorsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Display existing path?
Hi Adam, It took me a while, but I finally got a chance to take a look at this, thanks! I can see that I probably want to do it totally different, but I like quite a bit about your approach and how you track the points you draw so you can remove them cleanly. For myself, I'd like to draw the route manager route, rather than data from an external csv file. I'm also playing around with circle holds about a fixed point so it would be interesting to draw the center reference point surrounded by the desired path. But I have a starting point now I can fiddle with. Thanks again! Curt. On Sat, Sep 24, 2011 at 11:10 AM, Adam Dershowitz, Ph.D., P.E. wrote: On Sep 11, 2011, at 10:30 AM, Adam Dershowitz, Ph.D., P.E. wrote: Is there any easy way to show a prior route in Flightgear? In other words, if I have a set of recorded GPS points (lat,long, alt) in a text file can I display them in 3-D space, as I am flying in flightgear? Ideally I would like points (some box or sphere icon?) connected with line segments. There are three different approaches that occur to me, so I figured I would check if anyone has done anything like this, and see if anyone can offer any guidance. 1) It is probably possible to generate some custom scenery that has my desired path as custom made objects. But this seems like it is likely the most difficult approach? 2) It seems likely that it could be done with nasal, but I have really not done any nasal coding. One approach might be to hard code a bunch of objects, representing points, in the right locations into a nasal file. This is not very flexible, as each nasal script would be for a given single path. 3) Finally, what seems most general would be to write some code in nasal that can read in a csv file, and then to display objects in those locations. Is this feasible? Can nasal import a csv file or other general file format that could contain points? If any of you have any existing code, or suggestions, I would love to hear it. Thanks, --Adam I wrote some NASAL to accomplish this, and I thought that I would pass it back to the group, as there was some interest (Curt), and I don't have commit access. To use this, put show_points.nas into data/Nasal. The 4 geometry files go into data/Models/geometry and finally data is read from a csv file put in fg-aircraft. I included a little sample file to show a few points. To turn this on do: --prop:/sim/rendering/LLpoints=1 (or change this in flight to turn it on an off) You can change the interpolated points, between the actual points, by doing: --prop:/sim/rendering/LLpointsInterp=50. By default there is effectively no interpolation, only the actual points are displayed. A value of 50 will put a point every 50 meters, in a straight line between the existing points. Finally, you can change the data file name (although not the path) with --prop:/sim/rendering/LLfile=latlong.csv (although this is the default value). The sample lat/long file will put a few points around SFO, just for demo purposes. I hope that this is helpful. -- 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 -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] autopilot frame rate
There is also a frame rate throttling option, but it's pretty buried /sim/frame-rate-throttle-hz Also consider setting your sync to vblank option in your video hardware. That can help limit FlightGear to run at your display's refresh rate. Curt. On Fri, Oct 7, 2011 at 8:48 AM, Alan Teeder wrote: -Original Message- From: Arnt Karlsen Sent: Friday, October 07, 2011 1:12 PM To: flightgear-devel@lists.sourceforge.net ..chk output of fgfs -v -h |less , should offer frame rate throttling on recent and git versions of FG. Arnt I assume you mean fgfs --model-hz=n This will run the whole FDM at n iterations per second, not just the autopilot system. Alan -- 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 -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Default 3d clouds in Local Weather
On Fri, Oct 7, 2011 at 11:33 AM, thorsten.i.r...@jyu.fi wrote: Somehow, that didn't work out for me. * clouds are now black (see also http://flightgear.org/forums/viewtopic.php?f=5t=7358start=435#p139537 in the Forum - I'm not the only one with that problem - the common theme might be an NVIDIA GPU here (?)). I've temporarily fixed that by setting top_factor and middle_factor to 1.0 - it seems the shader itself is working fine, it just doesn't get the right values. * cloud placement altitudes are offset to what they were previously. I had measured out an offset value for each cloud type which places that cloud at exactly the right altitude, that's now 3000 ft different from what it was - something can't be right here... * the problem that clouds move upward as I increase distance is still there :-( On my machine, currently the weather system only produces crap *sigh* - rain works randomly, rain and haze are offset from clouds, clouds appear at unpredictable altitudes... Maybe we should revert to the previous state till that is sorted out - or am I a small minority experiencing such problems? * Thorsten Me too on the black clouds now ... nvidia graphics card + latest git. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Scenery Creation/TerraGear problems
On Thu, Oct 6, 2011 at 3:35 PM, James Turner zakal...@mac.com wrote: I've committed an updated BTG reader/writer to simgear/next, which supports the current format, and a higher-versioned format with 32-bit indices. Based on some conversions, 32-bit indices (all zeroes so far) compress down with gzip -9 to a tiny size increase over 16-bit indices (less than 4%), but I've also added code on the write path to check the maximum index size, and select the output format - so tiles will be in the current format until they exceed 2^16 vertices. If someone could incorporate the revised sg_binobj.cxx from simgear/next into simgear-cs, and verify the results with terragear, I'd be fascinated to know if the 'swirlies' are gone! (Or, of course, if you encounter any issues - perish the thought) What could possibly go wrong? :-) Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear and 2 Arc Second elevation data
You might need to do some work with the tool that chops up the dem's into TerraGear tile sizes. There are different terrain formats so you might need to adapt the code to read a different format as well. This part sounds like it should be pretty straightforward if you have clear docs for the input format. On Thu, Oct 6, 2011 at 6:40 PM, HB-GRAL wrote: Hi all Can terragear handle 2 arc second elevation data ? I read only about 1 arc and 3 arc data for the terragear toolchain. Cheers, Yves -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ 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 -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On Tue, Oct 4, 2011 at 3:10 AM, James Turner zakal...@mac.com wrote: On 2 Oct 2011, at 19:00, J. Holden wrote: Still, as a scenery developer and not a programmer, I'm still wondering what the limit is before the swirlies start floating around. Is it vertices? Fans? Triangles? It's 65536 vertices per BTG, in total. Strictly, this isn't true - the BTG format already supports 2^32 vertices / normals / colors in the file, but any object (tri / strip / fan) can only specify any index from 0..65535, so the higher vertices can't be used in any meaningful way. The good news is, I have the code to read a newer version basically done, which will make all the indices 32-bit, while of course keeping compatibility with existing BTG files of the current versions. Bad news is, we also need to update the writer code, and then measure how much the file size increases, after gzip compression. Hi James, Here's a random idea on the writer side: Would it be possible to do something like: if (size of any of my structures are 65535) then write_32bit_index_btg() else write_16bit_index_btg() endif Then we'd be spending are larger index bits on the files that need them, but not paying the penalty across the board on every scenery file. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On Tue, Oct 4, 2011 at 7:53 AM, James Turner zakal...@mac.com wrote: Entirely possible, yes - however I *suspect* it's unnecessary since gzip will compress the larger indices back down to a few % larger than what we currently have. Of course, I can't confirm or deny that suspicion until I upgrade the writer code path too :) Yes, but real world data can really spoil a fun theoretical discussion. :-) Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] FlightGear Newsletter - September 2011
On Mon, Oct 3, 2011 at 4:47 PM, Gijs de Rooy wrote: The issue was fixed today, which is why I publish the newsletter now ;-) I just thought that putting all those images as thumbs isn't nice either (the screenshot challenges for example are all about the images and have very little text), so I resized them slightly. Hi Gijs, Those images definitely look good larger. Low light / dusk / night images really lose a lot when they get sized down. All those cool point lights drop out. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On Sat, Oct 1, 2011 at 9:29 AM, James Turner wrote: Just looking at the relevant Simgear code - it already runs through GZip, so I'm not worried about overhead there - and the versioning system looks pretty sane to deal with too. There's already the version check for short-vs-unsigned-short counts, adding a new version increment and making the values longs looks pretty easy. BUT, if I modify the current Simgear code on 'next', is that the only place that needs to be changed, or is there another copy of this code somewhere in the terragear repo? I know terragear depends on simgear, but I've not looked at which code is actually shared. Hi James, the answer is yes. :-) We need to modify the loader in simgear as well as the format generation code in terragear. Right now the indices are packed as 2-byte short ints in the binary .btg file so of course making a change only to the simgear side will do nothing to fix the problem. Whatever we do needs to happen in close coordination with the terragear code in order to make sure that the changes match and are sane and reasonable from both perspectives. Regards, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Scenery Creation/TerraGear problems
I think the original intention was to keep the read/write together and centralized so it was easier to keep format changes compatible. That said, I haven't been tracking terragear-cs changes so I don't know what version of simgear they are using or if they've made other changes around this area. Curt. On Sat, Oct 1, 2011 at 10:51 AM, James Turner zakal...@mac.com wrote: On 1 Oct 2011, at 15:37, Curtis Olson wrote: We need to modify the loader in simgear as well as the format generation code in terragear. Right now the indices are packed as 2-byte short ints in the binary .btg file so of course making a change only to the simgear side will do nothing to fix the problem. Whatever we do needs to happen in close coordination with the terragear code in order to make sure that the changes match and are sane and reasonable from both perspectives. 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 -- 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 -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Atmospheric haze modelling
On Sat, Oct 1, 2011 at 11:13 AM, Vivian Meazza vivian.mea...@lineone.netwrote: Emilian and I have been working on the water shader, and have run into some show stoppers caused by the lack mf vertices in the ocean tiles - there are just 4 so far as we can see, so the junctions between tiles always show up as you speculate. It might be we can do something about this in due course. Hi Vivian, Another interesting thing is to turn on wireframe rendering and you can see exactly where the triangle seams are in the ocean surface. I noticed visual seams in the sea foam and reflections that weren't related to the underlying structure and seemed more likely to be a texture wrapping problem (i.e. one of the textures wasn't fully tileable?) Either that or there is a texture coordinate problem introduced in the latest water effects code. The original ocean auto-gen code was intended to keep things simple and keep polygon counts low. We certainly could generate more vertices in the ocean auto-gen code. That shouldn't be too hard and probably is worth doing now with computers that could easily handle a few more polygons. The challenge would be mating these autogen tiles up with adjacent terragear-generated tiles that are part land part ocean. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Scenery Creation/TerraGear problems
All that weird stuff is quite easy to explain. The binary .btg scenery format uses 16 bit integers as indices for the vertex, normal, texture coordinate lists. At one point we were using signed 16 bit integers, but I'm pretty sure we sneakily changed the flightgear btg loader to use unsigned 16 bit ints. So this changed the original limitation of a max of 32,768 vertices/texture coords/normals, etc. up to 65,535. However, I don't know if the terragear-cs tools ever got this fix on the scene generation side. So if your scenery exceeds these limits, this is exactly what you will see. The ultimate solution will be to expand the btg format to 3 or 4 byte integers -- but that will again require changes in the terragear-cs tools as well as changes in the flightgear btg loader. Conveniently we have a versioning system in the btg format so we can extend the format and maintain backwards compatibility if we want. The downside is that this index is used so much in the scenery files that going to a larger int size will have an immediate corresponding proportional impact on the btg sizes of all the files. There may be other ways to tackle this problem too ... maybe the btg format emitter could detect if the size exceeds the threshold of the current format and output just the tiles that require the extended format in the extend format. (Sorry it's late friday, I hope that makes sense.) :-) Curt. On Fri, Sep 30, 2011 at 8:54 AM, James Turner zakal...@mac.com wrote: On 30 Sep 2011, at 11:56, Martin Spott wrote: Hah, I managed to find the web page I've been searching for weeks, Bruce did a pretty nice writeup of the problem: http://www.cullam.com/flightgear.htm A very useful description, yes! James -- 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 -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Scenery Creation/TerraGear problems
On Fri, Sep 30, 2011 at 4:22 PM, joac...@gmx.de wrote: Am Fri, 30 Sep 2011 16:10:39 -0500 schrieb Curtis Olson curtol...@gmail.com: The downside is that this index is used so much in the scenery files that going to a larger int size will have an immediate corresponding proportional impact on the btg sizes of all the files. Ten years ago 16 Bit hurt much more than 32 Bit nowadays... And, wouldn't a compressor (tgz, bz2, ...) solve that issue, at least for distribution (trafficwise)? That could very well be true ... and I don't think it would be a huge coding change ... but it should be done in a way that bumps up the btg version number and picks a new packet id so as to maintain backwards compatibility with all the existing scenery out there. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Atmospheric haze modelling
On Thu, Sep 29, 2011 at 1:10 PM, ThorstenB wrote: Well, I have little to add. I can just confirm your and Curt's descriptions: yes, the tile loader reads the visibility property. When is has increased above a certain threshold (or when the position has moved into another area), it starts loading more scenery. And it always requests all tiles within the range defined by visibility (limited to the max-lod range though). It could be changed easily to watch for some other property - such as a specific ground visibility property, when that's provided. But yes, loading scenery is a major performance/memory factor - so we shouldn't be loading much more scenery than we do now - unless the fundamental concepts are also improved (such as better LOD support for scenery tiles). And it'd be rather complicated to implement any other tile loading method instead of the current concept of loading all tiles within a certain range. The tile loader lives in a simple 2D world. It knows nothing about elevation of certain tiles etc. Just to add a couple more bits of information. The tile loader knows (or can compute) the exact dimensions of the tiles. I thinks in terms of square rings if that makes sense. There is the tile which you are over right now. There is a ring of 8 tiles surrounding your current tile. There is a ring of 16 tiles surrounding that and a ring of 24 tiles surrounding that. 3x3 = 9 - the inner tile = 8. 5x5 = 25 - the 3x3 block = 16, etc. So the tile loader loads the 'current tile' which you are over the top of it and proceeds to load as many surrounding 'rings' as needed to cover the current visibility distance. As Thorsten B. points out though ... there is a memory/performance/disk-io price when loading tiles. And if we are pushing scenery complexity at the same time as pushing visibility out, this price will grow exponentially ... so it's worth paying attention to. Regards, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Atmospheric haze modelling
, objects,...). It's also tricky but crucial to apply the same technique to the terrain, otherwise the horizon line never matches up. So, at this point, I thought I better start asking for some thoughts before finding myself in a difficult place. * Is this something we want to do at all (it's reasonably obvious that I want to do it, but I don't think I can develop this as a harmless addon mode)? * Is there a good way to implement this concept *without* causing too many problems for global weather or the default terrain rendering (for instance, right now, my version of skydome.vert and skydome.frag only run with global weather when some parameters are manually entered via property browser - not user-friendly... but in principle the parameters necessary could be computed from weather info), or is it acceptable that only non-shader rendering stays how it was, but shader-based rendering gets all changed? Or that global weather can't use the skydome shader any more? * Is there a way to implement this without altering every single terrain type/object/... shader and to put the equations for fading of objects with distance into one single place where they are easily updated? Some thoughts are very welcome at this point (possibly also some help in the implementation - I can derive the math quite alright, but to get GLSL to run for me takes an awful lot of time - I'm essentially learning by reverse engineering and trial and error). Cheers, * Thorsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ 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 -- 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] git
On Tue, Sep 27, 2011 at 4:00 AM, Michael Sgier wrote: Hi I've messed up weather in fgdata. How could i discard local changes and only get changes/original files? Git says to be up to date but weather is broken. Later I'll do my first upload. (groundnetworks.xml etc.) I do alike the wiki and after commit simply do a git push? Hi Michael, If you know the specific file(s) that need to be returned to official git head version, then just run: git checkout file1 file2 file3 ... That (unceremoniously and without any confirmation) will discard your local changes to those named files. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Any alpha testers with a bit of extra time on their hands?
On Tue, Sep 27, 2011 at 4:36 PM, Arnt Karlsen a...@c2i.net wrote: ..tried to set camera target to some place on-shore with the camera operator click-to-point-to-orbit, on climb-out this is over-ridden to Carrier, Hi Arnt, There is some logic going on there to try to automatically guess what an operator is most likely to want or a user will find most interesting to look at. I won't claim this handles every situation, but in the short term why not get airborne, climb out and then find the spot you want to look at? This is intended to be a demonstration of a few different uav concepts implemented in FlightGear. just like on the Alphas. Beta02 is a step in the wrong direction, the drone climbs to ~800ft before diving into the drink. A couple things: I haven't tested with the Nimitz -- sorry, can't vouch for what might or might not work there. I've only flown with the Vinson. It's basically a problem that I lack infinite time. Is this still on your tablet pc that gets 2-3 fps. Honestly, this demo will never work with frame rates that low, sorry. What version of FlightGear are you flying? I'm testing with v2.4 and git here, again I don't have infinite time to test on earlier versions. Again sorry about that. ..on resets, launch is uncommanded, one engine dies, The only time I've see the f-14b engine flame out has been due to lack of fuel? You might try calling the fuel truck over and topping you off if you have problems with your engine not running. and the drone drives and dives in to that side off the bow. ..incompatible with FG-1.9.1, unless we fix it. Yeah, sorry, there's a limit to the number of combinations of versions and scenarios I can test and try to support. This was developed for the v2.4 release so going forward you can ding me for not being backwards compatible with v2.4, but it's hard to ask for something developed today to be compatible with 2 1/2 year old release of our code. Anyway, I appreciate you trying it and sorry it didn't work out. I think if I try to put together another demo like this, perhaps it will be base on a heavier than air balloon ... Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Any alpha testers with a bit of extra time on their hands?
On Tue, Sep 27, 2011 at 9:47 PM, Ron Jensen wrote: On Tuesday 27 September 2011 15:53:26 Curtis Olson wrote: a heavier than air balloon ... Would that be a Led Zeppelin? That's more clever than what I was thinking. :-) Open-humor. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] FlightGear development entered state
On Mon, Sep 26, 2011 at 6:30 PM, Martin Spott martin.sp...@mgras.netwrote: Alex D-HUND wrote: plib: Version 1.8.6. Why and how to obtain it can be found here [1]. Pretty old but still up to date, as far as I know. BTW, just for the record (and to finally purge this thread from my inbox): I remember a rule which says that FlightGear releases are requested to rely on public releases for 3rd party dependencies only. The latest PLIB release is 1.8.5, as far as I can tell. Hi Martin, I believe this is still the goal, unless someone can make a very compelling case otherwise. I realize the world isn't always perfect and sometimes it makes more sense to adjust and work around that, but it does lead to problems if we depend on a version that is taken from some random point in time or is not yet released. It can make downstream support of FlightGear pretty difficult. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Flying the f-14b...
On Sun, Sep 25, 2011 at 4:46 PM, Citronnier - Alexis Bory alexis.b...@gmail.com wrote: As always, thank you for a GREAT aircraft ;=)) Thanks Geoff :-) The f-14b has tons of little easter eggs and details! Definitely a fun and interesting aircraft! Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Any alpha testers with a bit of extra time on their hands?
Here's one for your guys. Do any nasal errors pop up on the console when things go bad? Are you able to manually fly the f-14b (non-uas version) around just fine? Once in maybe 20-50 flights I do see something go goofy with the f-14b stability augmentation's roll control. Maybe this same issue is popping up less rarely for some people? I haven't dug into how the SAS is implemented on the f-14b ... it's intricately woven I can tell ... maybe there's something lurking down in the guts of the f-14b SAS. Curt. On Fri, Sep 23, 2011 at 8:35 PM, Arnt Karlsen a...@c2i.net wrote: On Fri, 23 Sep 2011 23:44:02 +0200, Citronnier wrote in message 4e7cfda2.7060...@gmail.com: Le 23/09/2011 23:12, Curtis Olson a écrit : Geoff and Arnt and anyone else who is interested. I just updated the zip file overlay with a few changes. Geoff: you may be getting tired of being a bunny, but I played around with the roll controller and limited max target roll angle to +/-35 degrees. I also dialed down the gains a bit on final approach which will hopefully slow down the wild swings. More adjustment may be necessary, but I'd be interested in hearing if any of this helps your situation. ..a wee bit, now takes off and makes it ~1000 feet up, then it rolls to the right and makes it ~200 feet into the drink, and repeats the stunt seated in the cockpit (rather than in the camera), uncommanded on Reset button pushes. ..it's trying to orbit the carrier in the vertical plane? ..trying the operator click mode on targets like the merchantman near the Nimitz, works, until the demo is airborne, then it picks the Carrier target and tries a vertical orbit around it. ..refetching the merchantman with the operator mouse click mode, dives the demo into the drink between the 2 vessels. ..debug idea for Curtis: try the Nimitz too. I also set the default carrier speed to zero so if we get a few people out there playing around with this, we should be able to see each other via MP. That could be an additional fun element. I was just out there dodging XIII who trailed me around the pattern and let me live thankfully. :-) Here is the link with the zip file overlay download + installation and operation instructions: http://www.flightgear.org/uas-demo/ MP Call Sign: Shrike :-) Woot :-) so I missed the update, I just read this post after posting the previous one. And was wondering who was flying around there ! Model view ought to be interesting in case of one other tester just encounter problems. Greetings, Alexis Maybe see a few of you out there? Curt. On Fri, Sep 23, 2011 at 1:12 PM, Citronnier - Alexis Bory wrote: Le 23/09/2011 16:47, Curtis Olson a écrit : Hi Geoff, I'm starting to run low on ideas here. I assume you don't have any crazy/severe turbulence turned on or your plots would be all over the place. Are you running out of fuel and your engines dying? If you open the autopilot dialog (F11) you can see the target speed and if you have the hud turned on you can see the actual speed in any view. If you are circling with a target speed of 150 and your airspeed is less than than and you are decending, then definitely check your engine output. There is a fuel dialog box under the f-14b menu and you might double check that to see if you have any fuel in your tanks. For what it's worth, I'm rock solid in circling and the only time I have ever stalled out of the sky or really got out of kilter is when I've had severe turbulence turned on. Moderate turbulence at all levels is actually pretty interesting because despite getting thrown all over the sky, I still hit the carrier deck pretty spot on every time. Curt. Still no tests yet but just a though, In normal use (without the UAV script) I know that after TO (flaps down) you have to rise the flaps in before engaging the attitude autopilot mode. If you rise the flaps after engaging attitude autopilot mode, the a/c start to pitch up consistently. This has to be documented or fixed. I'll try to bring the maintainer to his workstation ASAP. Alexis On Fri, Sep 23, 2011 at 9:35 AM, Geoff McLane wrote: Hi Curt, Ok, removed my joystick, and entered a '5', but still crashed while just in 'circle' mode - no route entered ;=(( As usual Atlas provides a good 'view' as to what happened - added - ATLAS=--atlas=socket,out,IP,5500,udp to output to Atlas running in a 2nd machine... See - http://geoffair.org/tmp/uas-01.jpg
Re: [Flightgear-devel] Any alpha testers with a bit of extra time on their hands?
Hi Geoff, I'm starting to run low on ideas here. I assume you don't have any crazy/severe turbulence turned on or your plots would be all over the place. Are you running out of fuel and your engines dying? If you open the autopilot dialog (F11) you can see the target speed and if you have the hud turned on you can see the actual speed in any view. If you are circling with a target speed of 150 and your airspeed is less than than and you are decending, then definitely check your engine output. There is a fuel dialog box under the f-14b menu and you might double check that to see if you have any fuel in your tanks. For what it's worth, I'm rock solid in circling and the only time I have ever stalled out of the sky or really got out of kilter is when I've had severe turbulence turned on. Moderate turbulence at all levels is actually pretty interesting because despite getting thrown all over the sky, I still hit the carrier deck pretty spot on every time. Curt. On Fri, Sep 23, 2011 at 9:35 AM, Geoff McLane wrote: Hi Curt, Ok, removed my joystick, and entered a '5', but still crashed while just in 'circle' mode - no route entered ;=(( As usual Atlas provides a good 'view' as to what happened - added - ATLAS=--atlas=socket,out,IP,5500,udp to output to Atlas running in a 2nd machine... See - http://geoffair.org/tmp/uas-01.jpg for a graph of the flight... The two blips in the graphs show the first stall, but it recovers and begins to climb back, and the 2nd the second stall, this time too low to recover, so into the drink ;=(( CRASH! This is a view of the 'crazy' flight track http://geoffair.org/tmp/uas-02.jpg Obviously the pig-tail loops are the 'stalls'... remember with NO joystick attached and starting with centered controls (NumPad 5)... And if you want to load this track into Atlas, or further study speeds, etc, then this is the Atlas track data :- http://geoffair.org/tmp/uas-01.txt Then on the NEXT flight I tried :- IO=--generic=file,out,10,uas-02.csv,playback Then I added a header line, to help analyze it in say an OpenOffice spreadsheet import - see - http://geoffair.org/tmp/uas-02.csv On this 2nd flight, this crash took longer, since it (randomly) turned left first, where as mentioned it holds more stable, but then eventually went into a right turn, stalled, recovered, stalled again, and CRASHED... And as you know well, downloading this file, and using say - $ ./fgfs --fg-root=/point/to/fgfs/data --timeofday=noon \ --aircraft=f-14b-uas --carrier=Vinson \ --generic=file,in,10,uas-02.csv,playback --fdm=external you too can enjoy this fateful flight ;=)) In 'chase' view, you can clearly see the right roll increase, the nose coming up, and the stall, recovery, then repeated, and BANG, into the water... I know it is difficult to work on, debug, fix something that obviously does not happen in your case... Maybe if you do not enter any route, or something... And this is all with SG/FG git of 2011-09-14... Any other ideas? Regards, Geoff. On Thu, 2011-09-22 at 14:00 -0500, Curtis Olson wrote: On Thu, Sep 22, 2011 at 1:25 PM, Geoff McLane wrote: Hi Curt, A pleasure, and FUN ;=)) Yes, I know a low frame rate can play havoc when you are trying to fine control an aircraft from its attitude feedback, and I should have mentioned my rate, but is always in the high 50-70 fps range in this Ubuntu machine... so should NOT be a factor... Ok, 50-70 should be perfect. I just did another few runs, and this time it crashed just while circling... it was in a right bank, which got too much and the nose came up, and it stalled... I am mostly in the 'chase' view... This is really strange. I have seen nothing like this except when I inadvertantly applied external control inputs through a strange combination of linux virtual desktops and flightgear capturing the hotkey to come back to the FlightGear virtual desktop. So two thoughts here. If you have a joystick connected, could you try unplugging it to see if that helps? Could you also press 5 on the numeric keypad to make sure all the flight control inputs are centered. Because of the way the F-14b FCS is wired together in combination with the yasim flight surfaces, you can still input elevator and aileron and trim and cause conflicts that you might not see in other simpler aircraft that use aileron and elevator directly. The first time this happened at 2000 feet, it caught itself - leveled a bit and bumped the throttles, and began climbing back... But a little later, 20-30 secs, it happened again, and this time was still too low to recover, and SPLASH... I had not previously let it fly in the 'circle' mode for too long, but now note if I leave it in circling
Re: [Flightgear-devel] Any alpha testers with a bit of extra time on their hands?
Geoff and Arnt and anyone else who is interested. I just updated the zip file overlay with a few changes. Geoff: you may be getting tired of being a bunny, but I played around with the roll controller and limited max target roll angle to +/-35 degrees. I also dialed down the gains a bit on final approach which will hopefully slow down the wild swings. More adjustment may be necessary, but I'd be interested in hearing if any of this helps your situation. I also set the default carrier speed to zero so if we get a few people out there playing around with this, we should be able to see each other via MP. That could be an additional fun element. I was just out there dodging XIII who trailed me around the pattern and let me live thankfully. :-) Here is the link with the zip file overlay download + installation and operation instructions: http://www.flightgear.org/uas-demo/ MP Call Sign: Shrike :-) Maybe see a few of you out there? Curt. On Fri, Sep 23, 2011 at 1:12 PM, Citronnier - Alexis Bory wrote: Le 23/09/2011 16:47, Curtis Olson a écrit : Hi Geoff, I'm starting to run low on ideas here. I assume you don't have any crazy/severe turbulence turned on or your plots would be all over the place. Are you running out of fuel and your engines dying? If you open the autopilot dialog (F11) you can see the target speed and if you have the hud turned on you can see the actual speed in any view. If you are circling with a target speed of 150 and your airspeed is less than than and you are decending, then definitely check your engine output. There is a fuel dialog box under the f-14b menu and you might double check that to see if you have any fuel in your tanks. For what it's worth, I'm rock solid in circling and the only time I have ever stalled out of the sky or really got out of kilter is when I've had severe turbulence turned on. Moderate turbulence at all levels is actually pretty interesting because despite getting thrown all over the sky, I still hit the carrier deck pretty spot on every time. Curt. Still no tests yet but just a though, In normal use (without the UAV script) I know that after TO (flaps down) you have to rise the flaps in before engaging the attitude autopilot mode. If you rise the flaps after engaging attitude autopilot mode, the a/c start to pitch up consistently. This has to be documented or fixed. I'll try to bring the maintainer to his workstation ASAP. Alexis On Fri, Sep 23, 2011 at 9:35 AM, Geoff McLane wrote: Hi Curt, Ok, removed my joystick, and entered a '5', but still crashed while just in 'circle' mode - no route entered ;=(( As usual Atlas provides a good 'view' as to what happened - added - ATLAS=--atlas=socket,out,IP,5500,udp to output to Atlas running in a 2nd machine... See - http://geoffair.org/tmp/uas-01.jpg for a graph of the flight... The two blips in the graphs show the first stall, but it recovers and begins to climb back, and the 2nd the second stall, this time too low to recover, so into the drink ;=(( CRASH! This is a view of the 'crazy' flight track http://geoffair.org/tmp/uas-02.jpg Obviously the pig-tail loops are the 'stalls'... remember with NO joystick attached and starting with centered controls (NumPad 5)... And if you want to load this track into Atlas, or further study speeds, etc, then this is the Atlas track data :- http://geoffair.org/tmp/uas-01.txt Then on the NEXT flight I tried :- IO=--generic=file,out,10,uas-02.csv,playback Then I added a header line, to help analyze it in say an OpenOffice spreadsheet import - see - http://geoffair.org/tmp/uas-02.csv On this 2nd flight, this crash took longer, since it (randomly) turned left first, where as mentioned it holds more stable, but then eventually went into a right turn, stalled, recovered, stalled again, and CRASHED... And as you know well, downloading this file, and using say - $ ./fgfs --fg-root=/point/to/fgfs/data --timeofday=noon \ --aircraft=f-14b-uas --carrier=Vinson \ --generic=file,in,10,uas-02.csv,playback --fdm=external you too can enjoy this fateful flight ;=)) In 'chase' view, you can clearly see the right roll increase, the nose coming up, and the stall, recovery, then repeated, and BANG, into the water... I know it is difficult to work on, debug, fix something that obviously does not happen in your case... Maybe if you do not enter any route, or something... And this is all with SG/FG git of 2011-09-14... Any other ideas? Regards, Geoff. On Thu, 2011-09-22 at 14:00 -0500, Curtis Olson wrote: On Thu, Sep 22, 2011 at 1:25 PM, Geoff McLane wrote
Re: [Flightgear-devel] Any alpha testers with a bit of extra time on their hands?
#protected cells: 0 #wasted: 0 Wildfire fire summary: #created cells: 1 #cells still burning: 0 AL lib: ALc.c:1420: alcDestroyContext(): deleting 4 Source(s) AL lib: ALc.c:1818: alcCloseDevice(): deleting 3 Buffer(s) ~/fg/fg16$ On Wed, 2011-09-21 at 22:03 -0500, Curtis Olson wrote: I have something here that I think is kind of fun. I've been fiddling with this off and on since last fall and decided it was time to clean it up a bit and quit hording all the fun for myself. Basically I have taken the F-14b and created a high performance Navy drone out of it. It can auto-launch from a carrier, auto fly a route (if you've input one) and can do circle holds (compensating for wind.) I've added a simulated gyro stabilized camera that will point at anything you click on and then hold that view steady no matter what the airplane does (similar to what real uav's can do.) Finally, you can command it to return home and it will find the carrier, setup a reasonable approach and nail the landing perfectly every time (factoring in wind, carrier speed, etc.) I put together a quick web page that includes more of an explanation and description of what the demo does. I have a link to a zip file you need to download. This must be extracted over the top of the existing f-14b as per the installation instructions on the following web site: http://www.flightgear.org/uas-demo/ I'm hoping to get a few people that would like to try this and report back on a couple things: - were you able to get it to work? Were there any missing files or major blunders in the .zip file package? - are there places where my web page instructions stink, and can you help me write better or more accurate instructions, especially for the Mac - I already know my instructions for setting up the vinson demo aren't good, but it's been so long since I tried to do this on windows I forget all the fgrun details. Maybe there is an easier way now? - finally, what do you think? general impressions? things you thought were especially cool, or especially stupid? You probably can think of a dozen feature requests, and I have some things in the pipeline already. (For instance I have a refueling mode that is currently disabled, but almost is close to working. And I've done some preliminary work on adapting all of the auto-land logic for runway landings.) - if you happen to go look at the nasal code that does all the magic, please don't judge me (quoting Eskeletor from nacho libre) -- that was actually a fun sub-project (for a former computer scientist.) :-) - Oh, and eventually I'd like to add pictures to the instructions. If you happen to catch an especially cool looking view (weather, clouds, time of day, sun, sun glint, scene composition, etc.) then please feel free to send me a picture or two (or even a youtube movie) so I can make the instructions prettier and more exciting. :-) If I can get this demo all cleaned up and generally running pretty well, I have another UAS demo that is similar, but centered around the ATI Resolution-3 airframe (which is a 92 2.33m composite marinized flying wing.) Then if that all goes well, I have actual embedded C code to do much of these same sorts of things that can run on a gumstix embedded computer (or similar.) This code is able to talk directly to flightgear via udp packets, and has actually flown in a couple different UAV airframes using real sensors and real actuators. So you might see a progression developing here from pure simulation with all the logic prototyped in nasal, to software in the loop running pure C/C++ code, to the same software running on actual embedded hardware (using FlightGear as reality), to the end result of an actual real life UAV. (And I've been using drone, UAS, and UAV pretty interchangeably here.) Thanks! Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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 -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All the data continuously generated in your IT infrastructure contains a definitive record of customers
Re: [Flightgear-devel] Any alpha testers with a bit of extra time on their hands?
it confused on the long boat ride half way around the world... Well just to summarize, if your frame rates are solid in the 30-60+ range, then the next thing I'm wondering about is a joystick or other means of extraneous control inputs that could be confusing the F-14b AFCS. Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Any alpha testers with a bit of extra time on their hands?
Arnt, you have hijacked my thread, but if you are at 3fps with v1.9 then I'd recommend spending $10 on ebay to get yourself a decent video card and maybe $35 to get yourself a decent computer. :-) :-) :-) On Thu, Sep 22, 2011 at 2:28 PM, Arnt Karlsen a...@c2i.net wrote: On Thu, 22 Sep 2011 20:42:58 +0200, Arnt wrote in message 20110922204258.605fc...@nb6.lan: On Wed, 21 Sep 2011 22:03:43 -0500, Curtis wrote in message CAHtsj_cKv-ZEsXm-1h_+QVZtRUez6yUBHmLzccs=4jk=myr...@mail.gmail.com: I have something here that I think is kind of fun. I've been fiddling with this off and on since last fall and decided it was time to clean it up a bit and quit hording all the fun for myself. Basically I have taken the F-14b and created a high performance Navy drone out of it. It can auto-launch from a carrier, auto fly a route (if you've input one) and can do circle holds (compensating for wind.) I've added a simulated gyro stabilized camera that will point at anything you click on and then hold that view steady no matter what the airplane does (similar to what real uav's can do.) ..you saw these? TDL allows tracking moving targets, like your A380: http://www.youtube.com/watch?feature=player_embeddedv=1GhNXHCQGsM http://info.ee.surrey.ac.uk/Personal/Z.Kalal/ http://www.engadget.com/2011/03/31/zdenek-kalals-object-tracking-algorithm-learns-on-the-fly-like/ I put together a quick web page that includes more of an explanation and description of what the demo does. I have a link to a zip file you need to download. This must be extracted over the top of the existing f-14b as per the installation instructions on the following web site: http://www.flightgear.org/uas-demo/ ..now, will FG run on a pee wee eeepc? ..yes, @ 3fps, so the C172p is landable even without rudder control, I overshot 28R and used 28L instead, centerline touch down at taxiway N, aiming straight for full stop 'n exit on taxiway P. ;o) ..I'm on FG-1.9.1 with 3fps, what frame rate can I expect with FG-2.4? -- 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 -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Any alpha testers with a bit of extra time on their hands?
I went with the Vinson because it is spiffier. Everything should (theoretically) work the same and just as well from the Nimitz. I believe the deck geometries are identical in FlightGear (conveniently.) ;-) Curt. On Thu, Sep 22, 2011 at 5:02 PM, Arnt Karlsen a...@c2i.net wrote: On Thu, 22 Sep 2011 22:36:45 +0200, Citronnier wrote in message 4e7b9c5d.6080...@gmail.com: Le 22/09/2011 22:04, Arnt Karlsen a écrit : On Thu, 22 Sep 2011 14:00:49 -0500, Curtis wrote in message CAHtsj_crOGWDX43J5oKw7F6g12AWsRePoceNGW=a1b0txod...@mail.gmail.com: On Thu, Sep 22, 2011 at 1:25 PM, Geoff McLane wrote: You seem to be deliberately holding its speed down around 150 - I see air-brakes come up when greater than this, and throttle back - and although flaps (I think full flap?) are still applied, 150 must be quite 'low' for this sleek bird... Normal landing approach in the real aircraft I believe is about 120 kts? I fly 135 kt approaches in the simulator. It should be able to hold 150 kts with the flaps down pretty easily. ..the Navy guys fly approaches using AOA, not speeds, AFAIK. And a max 6000 lbs fuel in the tanks. FG's f-14b is quite tricky to fly with what is *supposed* to be the right AoA for approach. Side departure happen easily if your aren't smooth enough in your final turn. ..and it does not like to T/O and climb on idle power, all Launch!!! button action I see is wild pre-crash oscillations, the Reset button tosses me into the cockpit rather than in the camera. ..Curtis, any reason your demo needs the USS Vinson, rather than a renamed USS Nimitz copy? ..Alexis, any changes to the f-14b since FG-1.9.1? Curt, I didn't test yet, sorry, lake of time, but the last mods on properties in engines.nas and instrument.nas should be comited soon. Happy to see you all playing with the beast :-) Alexis -- 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 -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Mapping Airspace
https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ 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 -- 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] Mapping Airspace
On Wed, Sep 21, 2011 at 11:12 AM, Gene Buckle wrote: On Wed, 21 Sep 2011, Curtis Olson wrote: 11: RC Pilot. Stays under 400' AGL and outside a 3 mile radius from any airport. Probably flying at a club site and doesn't care about air spaces. Has no way to estimate if he's over or under 400' AGL and probably is flying a plane that can climb 500' per second and hover at 2 clicks of throttle. Is annoyed when a VIP flies into the big airport 30 miles away and his club field is just barely inside the TFR radius and he can't even go out there and fly a paper airplane for several hours. 11a: RC Pilot. Flies out of backyard whenever the hell he wants, regularly sees how high he can get using a 2lb electric Slow-Stik and a fancy altimeter downlink. Doesn't worry about how tiny a 40 model is at 2000ft, has FPV goggles for that. 11b: Smart RC Pilot: Doesn't post publicly about his misadventures, and has never been above 400' or anywhere close to inside or above the clouds. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Any alpha testers with a bit of extra time on their hands?
I have something here that I think is kind of fun. I've been fiddling with this off and on since last fall and decided it was time to clean it up a bit and quit hording all the fun for myself. Basically I have taken the F-14b and created a high performance Navy drone out of it. It can auto-launch from a carrier, auto fly a route (if you've input one) and can do circle holds (compensating for wind.) I've added a simulated gyro stabilized camera that will point at anything you click on and then hold that view steady no matter what the airplane does (similar to what real uav's can do.) Finally, you can command it to return home and it will find the carrier, setup a reasonable approach and nail the landing perfectly every time (factoring in wind, carrier speed, etc.) I put together a quick web page that includes more of an explanation and description of what the demo does. I have a link to a zip file you need to download. This must be extracted over the top of the existing f-14b as per the installation instructions on the following web site: http://www.flightgear.org/uas-demo/ I'm hoping to get a few people that would like to try this and report back on a couple things: - were you able to get it to work? Were there any missing files or major blunders in the .zip file package? - are there places where my web page instructions stink, and can you help me write better or more accurate instructions, especially for the Mac - I already know my instructions for setting up the vinson demo aren't good, but it's been so long since I tried to do this on windows I forget all the fgrun details. Maybe there is an easier way now? - finally, what do you think? general impressions? things you thought were especially cool, or especially stupid? You probably can think of a dozen feature requests, and I have some things in the pipeline already. (For instance I have a refueling mode that is currently disabled, but almost is close to working. And I've done some preliminary work on adapting all of the auto-land logic for runway landings.) - if you happen to go look at the nasal code that does all the magic, please don't judge me (quoting Eskeletor from nacho libre) -- that was actually a fun sub-project (for a former computer scientist.) :-) - Oh, and eventually I'd like to add pictures to the instructions. If you happen to catch an especially cool looking view (weather, clouds, time of day, sun, sun glint, scene composition, etc.) then please feel free to send me a picture or two (or even a youtube movie) so I can make the instructions prettier and more exciting. :-) If I can get this demo all cleaned up and generally running pretty well, I have another UAS demo that is similar, but centered around the ATI Resolution-3 airframe (which is a 92 2.33m composite marinized flying wing.) Then if that all goes well, I have actual embedded C code to do much of these same sorts of things that can run on a gumstix embedded computer (or similar.) This code is able to talk directly to flightgear via udp packets, and has actually flown in a couple different UAV airframes using real sensors and real actuators. So you might see a progression developing here from pure simulation with all the logic prototyped in nasal, to software in the loop running pure C/C++ code, to the same software running on actual embedded hardware (using FlightGear as reality), to the end result of an actual real life UAV. (And I've been using drone, UAS, and UAV pretty interchangeably here.) Thanks! Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] the stutter/lag in the big terrain scene using the file format ive
Hi Nicegood, Unfortunately I haven't done a lot of work in the scenery / paging engine lately. I would recommend asking about this on our developers mailing list. Hopefully the developers who have worked more in these areas will see your question and be able to respond with some suggestions. Best regards, Curt. 2011/9/19 nicegood nicegood_7...@163.com Dear Mr Curtis: We have met across the stutter/tag in the big terrain scene, the terrain format is the ive(using the osgdem of the vpb tools) ,Otherwise even the frame rate is more than 60 fps,the stutter/lag still exist,how to solve this problem? the following is the problem that we think to cause 1.In addition to the pre-compiled function, are there other features of OSG to avoid loading all the need textures of a frame during the process of rendering the frame ? 2、How to pre-load PagedLod sub-blocks using pre-compiled function? 3、 How to extend the time interval between a tile being loaded into memory by the DatabasePager and being rendered to allow sufficient time for pre-compiled? Can you give us some good ideas? thanks nicegood -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Openstreetmap vs. G**gl
Right -- outside the USA, much of the x-plane airport data is hand entered and submitted by end-users with no quality control other than people are welcome to research and fix problems they find as they find them. I wouldn't be surprised if some of the entries are complete guesses or crazy typos. Inside the USA we have the FAA data to reference. For a while DAFIF was world wide, but more recently I think they pulled that back and just maintain the USA data. Quality + free GIS data is often hard to find. We are very lucky to have some of the products we do have ... like SRTM and VMAP. Curt. On Thu, Sep 15, 2011 at 8:42 PM, John Denker j...@av8n.com wrote: On 09/15/2011 05:15 PM, Martin Fenelon wrote: I like to think that the positional errors of many (most non US?) aerodromes are due to mistakes made when changing from one datum to another. Well, that's not what I think, based on looking at the data. The very first non-US example I looked at was ES03 Hova for which the apt.dat position is off by hundreds of meters, to the southeast. Nearby we have ESVF Frolunda for which the apt.dat location is off in another direction, and the relationship of its two runways to each other is wrong. It is hard to see how a change in datum could have a different effect on two nearby airports ... and there is just no way it could have a different effect on two runways at the same airport. There aren't that many different datums to play with. Errors in runway orientation at unmodifed airfields (with default layouts) appear to be caused by confusion between magnetic and true bearings, with magnetic being used as true. Uhh, in apt.dat the runway heading for ES03 is off by more than 35 degrees. The local magnetic deviation is more like 4 degrees. Bottom line: Many of the apt.dat entries are just wrong. You don't need any ultra-sophisticated geodetic expertise to understand what is going on. The entries are just wrong. If you want something to be accurate to a few centimeters, or even a few meters, then some expertise is required, but that's not what we're talking about here. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ 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 -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frame rates in git version?
2011/9/12 Mathias Fröhlich I just set CC, CXX, CFLAGS, CXXFLAGS and export them. Then cmake just takes them. This works just the same than with automake too. At least current cmake versions behave that way. Older ones were way harder to convince that I know my cflags :) Alternatively ccmake in the build directory or on win32 cmake-gui gives you interactive access over all the build flags if you need. As far as I know, You can also prepare a partly populated CMAkeCache.txt into the build directory. I think that the already provided values are taken mostly as is. Also I have checked in a default build type of release, which should accelerate the default build. Part of my script to set up all flightgear related projects is about: export CFLAGS= ... export CXXFLAGS= ... cmake \ -D CMAKE_BUILD_TYPE=RELWITHDEBINFO \ -D CMAKE_DEBUG_POSTFIX= \ -D CMAKE_MINSIZEREL_POSTFIX= \ -D CMAKE_RELEASE_POSTFIX= \ -D CMAKE_RELWITHDEBINFO_POSTFIX= \ -D CMAKE_VERBOSE_MAKEFILE=TRUE \ -D CMAKE_INSTALL_PREFIX=$prefix \ -D ENABLE_RTI=ON \ $srcdir Which should cover most of the interresting everyday cmake options. Hi Mathias, Indeed, telling cmake you would like a release build seems to improve the performance of the executable dramatically. I suppose it is good to ask dumb questions once in a while so this basic information can get in the archives and become google-able. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/___ 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
On Mon, Sep 12, 2011 at 7:32 AM, Curtis Olson curtol...@gmail.com wrote: On Mon, Sep 12, 2011 at 7:24 AM, Martin Spott wrote: Done :-) http://www.freshports.org/games/flightgear/ Martin. Thanks, I'll update the flightgear.org site. I know those FreeBSD guys are pretty passionate about their unix and hate getting overlooked. :-) By the way, I got a note from the official Fedora FlightGear package maintainer and he indicated that he will likely only provide packages for Fedora 16 (the upcoming, not yet released fedora) and 17 (the next version after the one that hasn't been released yet.) Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Strange/unknown input to controls/flight/aileron when switching virtual desktops
Ok, here's a really weird one. I have noticed the effects of it for a long time, but this afternoon was the first time I managed to isolate it to something I can repeat and perhaps explain. I do not have a joystick plugged in, I'm not in mouse control mode, just normal mouse-runs-the-gui-mode in flightgear. I am running Linux (fedora 15) with a number of virtual desktops. Every time I switch away from the FlightGear desktop to a different desktop, and then switch back, the value of /controls/flight/aileron gets -0.05 added to it. So I can center the controls, and then flip to a different desktop, come back, and the value is -0.05. If I switch away and back again, the value bumps to -0.10. This is very repeatable. I have verified (by using a remote telnet connection) that the value is changed when I switch back to the FlightGear desktop. I am running FlightGear on desktop #4 and using the keyboard to switch desktops. I have a keyboard accelerator mapped to desktop switching so I can type Alt-1, Alt-2, Alt-3, etc. to switch to that correspondingly numbered desktop. So here's what appears to be going on. When I type Alt-4 to return to the FlightGear desktop, FlightGear is seeing that keystroke as well as my desktop and interpreting it as a numeric-keypad-4 press. If I move my flightgear window to desktop #6 and then type Alt-6 to flip to that desktop, the ailerons will move one notch to the right. There is a pattern here. FlightGear is somehow capturing a keystroke it shouldn't be catching. When I am on desktop #6 and looking at my flightgear window, I can press Alt-6 all day long and the ailerons do not respond, it's only when I'm flipping from some other desktop back to the flightgear desktop where my Alt-number hot key is accidentally caught and interpreted as a numeric keypad press. I know this is really weird, and probably something deep in the bowels of OSG, but does any one have any thoughts or suggestions on this? I usually run with 6 virtual desktops and two monitors and have different things happening on different desktops and am frequently switching desktops and when I run FlightGear, it is frequently catching these stray/unwanted keystrokes and affecting my flights. Any ideas on how to fix this??? It's really bugging me Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Display existing path?
Hi Adam, This has been something I thought would be a nice feature too. It should be possible. I've placed other models using nasal to create interesting scenes. It would be kind of cool for simulated UAV work to see your exact waypoint target in 3d space. Curt. On Sun, Sep 11, 2011 at 12:30 PM, Adam Dershowitz, Ph.D., P.E. wrote: Is there any easy way to show a prior route in Flightgear? In other words, if I have a set of recorded GPS points (lat,long, alt) in a text file can I display them in 3-D space, as I am flying in flightgear? Ideally I would like points (some box or sphere icon?) connected with line segments. There are three different approaches that occur to me, so I figured I would check if anyone has done anything like this, and see if anyone can offer any guidance. 1) It is probably possible to generate some custom scenery that has my desired path as custom made objects. But this seems like it is likely the most difficult approach? 2) It seems likely that it could be done with nasal, but I have really not done any nasal coding. One approach might be to hard code a bunch of objects, representing points, in the right locations into a nasal file. This is not very flexible, as each nasal script would be for a given single path. 3) Finally, what seems most general would be to write some code in nasal that can read in a csv file, and then to display objects in those locations. Is this feasible? Can nasal import a csv file or other general file format that could contain points? If any of you have any existing code, or suggestions, I would love to hear it. Thanks, --Adam -- 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 -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Frame rates in git version?
Sometime in the last week I noticed the Flightgear frame rates on my machine went to about 1/3 of what they were previously. I haven't worked super hard on this, but here's what I can say. When I fire up the Cub at --airport=KANE with clear skies I get: v2.4 = 90 fps (bounces around a bit but usually 90 or above) git = 20-25 fps (same options, same aircraft, same clear skies.) This gets even worse when I fly the f-14b off the Vinson ... even out at sea with just a few clouds it seems like my frame rates are usually less than 20 (12-17 range) with the git version. Has anyone else noticed this or should I be looking for a local build problem? It doesn't seem to be related to my video driver update since v2.4 runs with the frame rates I expect. I recently moved over to trying to build with cmake by default, but cmake hides the compile options so I honestly don't know how to even check what compile options I'm building with now that I switched to cmake. Can anyone tell me how to figure that out? Is there a detailed build log that gets saved somewhere? Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New experimental mapserver
On Fri, Sep 9, 2011 at 2:49 PM, HB-GRAL wrote: Hi Curt Thank you very much taking time for this. Now this is very interesting, a curved surface with a natural looking slope and correct hills. Can you point me to an example for this ? I guess my current examples like KSFO and EHAM etc. do only provide really flat areas. I did not see any small hills and valleys in FlightGear unless I saw the some artificial shaders from Frederic Bouvier Hi Yves, every airport is an example of this, but maybe hills and valleys is a bad description on my part. What it amounts to is that airports try to be as flat as possible, but even flat areas aren't often as flat as we might first think. Go to any detailed airport chart and look at the runway elevations for the ends of each runway. Another way to think about this is that if you make all the airports completely flat, you will have to deal with cliffs around the edges ... either the airport is sunk down at some parts, and raised up in others relative to the surrounding terrain. Albuquerque, NM is one of the worst offenders I found. You can't fit a flattened airport into the surrounding terrain without the result looking awful. One solution would be to adjust the terrain to blend in with the airport and that would be an ok thing to do. But the problem is that I like to torment myself. Here is approximately what I came up with. 1. Sample the raw terrain elevation across a regular grid that covers the area of the airport. 2. I pick a 3d function that is sufficiently curvy so that it can flex enough to reasonably match the terrain surface, but stiff enough so that it doesn't have all kinds of crazy ups and downs. Then I do a least squares fit of this function to the data. For example, let's say my function is z = a*x^2 + b*y^2 + c*x*y + d*x + e*y + f. Then the least squares fit would pick the best coefficients: a, b, c, d, e, f to fit this function through the sampled terrain data. Very much like a best fit of a line through x, y data except extended to 3d with a bit more complicated function. 3. Now that I have the coefficients for this function, I can use this function to adjust the elevations of everything on the airport surface. The cool thing is that now when you look at an airport built on crazy terrain with maybe a valley falling away between two runways on one side, the edges all around the airport match up reasonably well with the surrounding terrain. 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. Hm, indeed, for the moment I was only looking to the two dimensional triangles and saw that genapts (or terragear) is calculating some small areas and probably unnecessary triangles like here at KSFO http://maptest.fgx.ch/screens/wired.png There are also a lot of duplicate items, or it looks like in the wire-frame view, but maybe this items are just very close to each other ... Very likely this is a result of items very close to each other ... especially if the airport designer placed or sized anything visually. One huge problem you run into over and over and over and over again in terragear/genapts work is numerical precision. Things just get weird when you get a gap between polygons that is about the size of one bit difference between two double floating point values. Logically correct polygon manipulation code can blow up due to small numerical problems. And when you throw real world data (and the whole world) at your code, you *will* find every possible way that numerical issues can blow up your code. Anyway, how do you get the natural curved surface without height data Well it's terragear so we have all the processed srtm heigh data already available to just use. ? How are you interpolating between points ? I will try to understand this. Of course, I should not be that lazy and should have a look to the genapts or terragear code instead, right ;-) Once we do the least squares fit of our function, then we can look up a z value for any x, y point within our airport area. Generally I see that I miss some points here with airport generation and it is very different from generating shapes for a map. Hope that helps clarify a bit. Curt -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how
[Flightgear-devel] substantial base package size increase
I just noticed when I pushed out the latest developer snapshot build that our setup.exe size has grown from about 410 Mb to 500+ Mb. I think (?) this may be the new dds textures? I'm not making a judgement, or calling for a particular action here, but it might be worth thinking/discussing if there is a way to push the size back down, or are we ok with 500Mb+ (1/2 a Gb) on our setup.exe size? Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Openstreetmap vs. G**gl
I don't know the specific answer in this case, but it does illustrate one of the surpreme challenges in mixing different gis databases ... you end up with information from different sources, adhering to different standards, appropriate for different scales, using different datums, different surveying techniques etc. Sometimes manually processed or manually entered/created, processed in different ways, etc. etc. Asking a cartographer where is it? is just about as difficult a question as asking an astronomer what time is it? Curt. On Sat, Sep 10, 2011 at 5:54 PM, HB-GRAL wrote: Hi all Unfortunately I just run into another problem with my map. This is what I see on my currently generated map using 8.10 taxiway data and 8.50 runway data (this is no reference and a crude mixup of course, I apologize in adnvance): http://maptest.fgx.ch/screens/mapping.png But now, I discovered something really strange. I was looking to different maps while exploring this area with FLightGear. This is what I see in with recent terrasynced scenery: http://maptest.fgx.ch/screens/flightgear.png This is the same position on mpmap02 server: http://maptest.fgx.ch/screens/google.png This is exactly the same position on OSM: http://maptest.fgx.ch/screens/openstreetmap.png I am just curious why FlightGear and OSM have the same accurate position, and Google map shows another one. I am sure, there are different problems, but some enlightenment will be greatly appreciated here. Beside of that, where does this inexisting taxiway to the left come from ? Is this a FlightGear feature ? Something like we-have-no-taxiways-so-there-is-probably-one-to-the-left ? Cheers, Yves -- 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 -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] New experimental mapserver
/ ___ 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 -- Why Cloud-Based Security and Archiving Make Sense Osterman Research conducted this study that outlines how and why cloud computing security and archiving is rapidly being adopted across the IT space for its ease of implementation, lower cost, and increased reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
So I have nothing against cmake, it sounds like it offers some nice features. But I assume those that want to push this change forward, will take some time to write up some basic howto's so that people who have never used it as a developer can get up to speed without too many problems? Right now when I poke around on the wiki and I'm sure the getstart manual, all the instructions are automake based. Hopefully we can do some proactive hunting of automake references in our instructions scattered around and get those cleaned up in advance? Are there any cmake based build instructions available anywhere? I'm not seeing them. When building OSG, you run ./configure; make; make install like any other project. However, ./configure is an automake/conf generated in flightgear. For a cmake dummy, how do you even go about building flightgear with cmake? (I of course know everything, but I do have a friend who's a little inexperienced with cmake.) Is there a way to do the equivalent of make dist in cmake to generate .tar.gz source releases? Has this been tested to see if it includes all the necessary files? We have some extra automake rules to help create the data archives (which is important because this officially defines what goes into the release installer for both Mac and Windows as well as the data archive for people building from source code (who aren't doing 3Gb of git for the data tree.)) I'm just hoping the cmake jocks will put themselves in the position of non-cmake jocks and help ease the transition from multiple fronts for many of our different classes of users/developers. Thanks! Curt. 2011/9/5 Mathias Fröhlich mathias.froehl...@gmx.net Hi, On Monday, September 05, 2011 14:47:44 Alan Teeder wrote: Please don´t. I reverted from VC100 to VC90 as the Cmake process was always failing. There is a difference between Hudson saying that all is OK with Cmake and Visual Studio VC100 producing working executables. This was all with the de-facto standard 3rd party package from ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/. I could get the system to work, but then it would all go wrong after a few days or weeks. On the other hand the current VC90 project files seem quite robust. Then please tell what is going wrong. This is like every piece of code lingering around in this and similar projects. The people doing the changes do their best to make it work. But if there is something failing on some other platform/configuration/... feedback is needed. Thanks Mathias -- 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 -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Cmake
Is there support for the --prefix= concept of autoconf? I really struggled to find anything like that in OSG's cmake config and it appeared I would be forced to define a really ugly/long list of environment variables before running make install in order to accomplish a similar thing (installing somewhere other than /usr/local/ or using an installation somewhere outside of /usr/local/ In the end I just gave my hope to manage a couple different versions of osg, and just wrote over my older version with the newer version. Thanks, Curt. On Mon, Sep 5, 2011 at 11:25 AM, Martin Spott wrote: Curtis Olson wrote: I'm just hoping the cmake jocks will put themselves in the position of non-cmake jocks and help ease the transition from multiple fronts for many of our different classes of users/developers. With CMake there's a list of flags you're appending to the 'cmake' call similarly to calling 'configure' with custom flags - and with no flags at all it'll create a default build for you depending on the prerequisites installed on your system. Thus, there's nothing terribly different from Automake except from the fact that you will _always_ have to append the source directory for CMake - which will be a simple trailing dot for in-tree-builds ;-) Rest assured that work to bring the CMake build system for SimGear and FlightGear onto the same level as the former build systems is already in progress. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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 -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Cmake
Is this an option to cmake at the configure step, or to make at the
build/install step? Can this work as an environment variable? What if I
want to pick up build libraries from a non-standard location ... maybe I'd
like to install a particular version of FG and a particular version of all
it's prerequisites somewhere strange like /opt/FlightGear-2.4/ so everything
it needs is self contained there and I can have other versions of the
prerequisites elsewhere?
The automake --prefix= option was sort of an all in one thing. It not only
added this to the *front* of the include and library search path for
compiling, but it also defined the install paths such as $prefix/lib,
$prefix/include, $prefix/bin, etc. where everything would be placed when
make install is run.
Thanks,
Curt.
On Mon, Sep 5, 2011 at 11:37 AM, Martin Spott martin.sp...@mgras.netwrote:
Curtis Olson wrote:
Is there support for the --prefix= concept of autoconf?
-D CMAKE_INSTALL_PREFIX=${FG_HOME}
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
--
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
--
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
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] FlightGear v2.4 is Released!
Curt doesn't know the password! Ok, the system does know about one of my more ancient email addresses ... and now I'm back in. Martin (or anyone else). If you have a freshmeat account, I can add you to the project so presumably you can make updates and edits to the content. I see there is a checkbox that anyone can submit changes (and they are moderated by the freshmeat.net staff) but it would be nice to get one ore more other developers attached to the flightgear entry to help with maintaining the info. Thanks! Curt. On Fri, Aug 26, 2011 at 8:28 AM, Martin Spott martin.sp...@mgras.netwrote: Martin Spott wrote: and now the always recurring question: Who owns the Freshmeat account !? ;-) I just noticed that Freshmeat has been updated today - at least a new Recent releases entry has been added. Anyhow most of the entries in the Links section are pointing to outdated or invalid pages. I suspect that Curt is still the sole owner of the FlightGear project at Freshmeat ping Curt Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ 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 -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Links for new FlightGear pilots
I'd like to find a few really good quality links (web pages really) that are especially helpful for new FlightGear pilots. I get quite a few questions from people who fire up FlightGear for the first time and have little aviation experience and zero prior FlightGear experience. They need really basic help, like how do you start the engine. Or they need basic description of how to install aircraft or scenery. I know some of this is scattered around on the wiki and the manual ... but I'm hoping people can send me some really good links for basic beginners -- nothing is too obvious here, assume I know nothing. :-) - basic engine startup and taking off. - basic installation of aircraft / scenery - good tutorials targeted towards new pilots The goal here is to get a brand new user over the very first hump and see some initial success very quickly. Thanks! Curt -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Content protection for modders?
On Thu, Aug 25, 2011 at 5:50 AM, Jan Mattsson jan...@gmail.com wrote: 2011/8/25 li...@stockill.net: You wouldn't even need to do that - how can you have a closed format when the code for reading it would need to be open source? An encrypted file? The whole idea certainly seems contradictory to the spirit of the project. Do other sims offer content encryption or content protection? For instance, I've been able to locate and test a blender plugin that can open up many MSFS aircraft models. How about xplane? It's been a *long* *long* time since I fiddled with their package, but at the time I was paying attention, all their 3d formats were open and well defined. Often the commercial sims will store things in their own binary formats, but in most cases these aren't encrypted and the end users figure these out pretty quickly -- so they can either edit the content or create new content with the same format. I wouldn't consider a binary format much of a content protection scheme ... especially in an open source project where the source to load and store the binary format is readily available. I understand the desire for content creators to not get ripped off. But also understand that one of the main reasons that FlightGear can be successful is because we make all the source code and content open. If we didn't make everything open, then we wouldn't get nearly the same amount of volunteer contributions and high quality volunteer contributions is the critical reason why FlightGear has been so successful. If we were a closed off commercial outfit, who would want to pitch in and help someone else make money? But with everything open, you know that your contributions can be enjoyed equally by everyone else, just as much as you are enjoying everyone else's contributions. There are some low-lifes out there that try to make a profit on other people's work, and will gladly lie and misrepresent things to swindle as much money as possible from unsuspecting end users. But the truth is that these people have always existed, and will always exist. They are remarkably good and persistent at copying things ... going so far as to break copy protection schemes, reverse engineer hardware designs, copy the exact look of products (even including the logo.) This isn't a problem that is unique to the FlightGear project -- and it's something we would still face no matter how hard we worked to create copy protection schemes. If you designed a binary content format, someone will reverse engineer it. If you design an encryption scheme, someone will just modify the sim code to dump out the decrypted version after it's been loaded into memory by the proprietary decrypting plugin. (If not outright break the encryption scheme or steal your encryption keys.) In all these case, the content can still be easily copied, replicated, sold, etc. The best scheme I've seen is something that has a node-lock key that will only run on a single PC (key'd to mac address, or processor id.) But this implies a more complicated 2 step install where the user must come back to you after installing the product, report their unique id, get a key, and then install that key before they are able to run. And the problem with all of this is that in an open source project, someone could simply compile a new version of the simulator that skips the key check or accepts a trivial key, or any key. I'm just thinking down various avenues here, but hopefully you can see that what seems like a simple request at first is actually quite complex and creates all kinds of down stream issues (both technically and with user support.) And at the end of the day, the bad guys can usually find work arounds anyway and aren't slowed down too much. When farmers grow crops, they have to put up with weeds. We can try reasonable things to minimize the weeds, but if you are too aggressive at killing the weeds and don't tolerate a single one, then you most likely end up killing much of your crop too. So it's my view that this is something we just have to put up with. We can try to take reasonable steps to minimize the problem, but we can't eliminate all the bad guys without harming all the good things about our project. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Slackware packages for 2.4.0
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've seen several questions on our facebook page about ubuntu packages, and I'm sure there are nearly as many people wondering about fedora/redhat .rpm packages. Also, we have older packages that were available for Sun, sgi, and FreeBSD. Can anyone comment on the latest package versions available for these platforms and if we still want to list them on our download page? Who's going to be the first to come out with an Android package? :-) Thanks! Curt. On Sun, Aug 21, 2011 at 1:56 PM, Jon Stockill li...@stockill.net wrote: Slackware packages for the FlightGear 2.4.0 release can now be downloaded from packages.flightgear.org.uk (and it appears there are a few people already doing just that!) Packages are available for Slackware 12.2 and the 32 and 64 bit versions of Slackware 13.37 Enjoy! -- Jon Stockill li...@stockill.net -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ 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 -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2___ 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
On Sun, Aug 21, 2011 at 3:00 PM, Erik Hofman e...@ehofman.com wrote: On Sun, 2011-08-21 at 14:32 -0500, Curtis Olson wrote: Also, we have older packages that were available for Sun, sgi, and FreeBSD. Can anyone comment on the latest package versions available for these platforms and if we still want to list them on our download page? Who's going to be the first to come out with an Android package? :-) Android (ARM) won't work since ARM only supports float´s in hardware and not double's. I don't know about all hardware, but on ARM7/9, software double floating point is actually surprisingly good, much better than you'd probably imagine. But finding hardware with enough RAM and drive space might be the bigger challenge (and I'm not sure about support for compiling raw C/C++ code, although I heard that might exist or could possible exist in the future.) The omap3 has good hardware floating point (double) support. So I'm sure there are existing chips that wouldn't do so well, but there are also existing chips that should do pretty well. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2___ 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
Next year we'll probably see android tablets running at 2 ghz with umpteen (that word passes my spelling checker so it must be legit) :-) gigabytes of storage. Hey, if anyone comes up with cool PFD/MFD type displays that run on Android, definitely let me know about it! I'm very interested -- not so much yet in trying to get FlightGear to run on android, but getting maps or displays running on android that work in conjunction with FlightGear would be a very cool step. We are starting to see some decently looking 10 android tablets at prices ordinary people could begin to consider ... and these are probably the first things that can give the ipad a run for it's money. It will be really interesting to see what kind of tablets are available by Christmas, or this time next year. Curt. On Sun, Aug 21, 2011 at 5:46 PM, TDO_Brandano - tdo_brand...@hotmail.comwrote: Actually I bought an el cheapo (EKEN m009s) android tablet for the explicit purpose of trying to use it as a rudimentary MFD, exploiting also the touch screen interface. Currently I am playing a bit with HTML5 features, but a native implementation would probably be better and would free up CPU cycles on the machine running FlightGear. To: flightgear-devel@lists.sourceforge.net From: martin.sp...@mgras.net Date: Sun, 21 Aug 2011 21:35:05 + Subject: Re: [Flightgear-devel] Slackware packages for 2.4.0 Curtis Olson wrote: Also, we have older packages that were available for Sun, sgi, and FreeBSD. Providing packages for FreeBSD is a waste of effort as FlightGear is available as a port on FreeBSD and I'm convinced they'll upgrade to 2.4.0 soon. SGI is almost dead as a platform and, well, Sun last time I looked at building FG on Sun there was too little interest in maintaining platform compatibility with compilers on Unix who don't support certain GCC'isms. Therefore I'd probably recommend to move these packages into an attic section. Can anyone comment on the latest package versions available for these platforms and if we still want to list them on our download page? Who's going to be the first to come out with an Android package? :-) There is a rudimentary X-Plane for the iPhone but I'm uncertain if it's worth the effort adapting the main sim to such a low-end graphics system. Flying X-Plane on the iPhone starts as a big fun but becomes pretty boring pretty soon. Anyhow, having a gadget like a remote instrument panel on these devices might look really cool ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ 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 -- 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] FlightGear v2.4 is Released!
And for whatever it's worth, I uploaded all the v2.4 aircraft zip files yesterday, waited about 12 hours to give the mirrors a chance to sync, and now I've posted the v2.4 aircraft download page on the web site. Best regards, Curt. On Thu, Aug 18, 2011 at 8:07 AM, henri orange hohora...@gmail.com wrote: Le jeudi 18 août 2011 08:58:46, thorsten.i.r...@jyu.fi a écrit : SNIP Thanks for that as well! For the next release, I'd just have one suggestion: Feature freeze for aircraft 2 weeks after feature freeze for core, so that aircraft can be tested against what is to become the release candidate and still committed in time. Apart from that - just keep it this way. Cheers, * Thorsten Wasn'it the case ? since the wiki says: Detailed Time Schedule and Checklist Dec/Jun 17th: Development stream is declared frozen or yellow. And a NEW Aircraft which is right now within fgdata FG2.4 had been commit at Tuesday June 28 2011 https://www.gitorious.org/fg/fgdata/commit/b456113e124b82a81927aff67ef0e72aa53c2294 This more or less 2 weeks. Am i wrong ? Kind regards. Henri -- -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ 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 -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 2 Questions about library prerequisites
I have 2 quick questions: 1. What is our official minimum version of OSG required for the v2.4 release? 2. What is our official minimum version of boost required for the v2.4 release? I'd like to make sure the information on our web site is accurate. Thanks! Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear v2.4 is Released!
Here is a quick announcement that FlightGear v2.4 is now officially released! You can read the full announcement on the flightgear.org web site here: http://www.flightgear.org/announcements/flightgear-v2-4-0-released/ A huge !!!THANK YOU!!! to all the developers and contributors involved in making this the best version of FlightGear ever! Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
Also with sending/receiving UDP packets, you need to use different ports for the sending and receiving channels. On Tue, Aug 16, 2011 at 2:28 AM, Anders Gidenstam anders-...@gidenstam.orgwrote: On Tue, 16 Aug 2011, Derrick Washington wrote: One last thing is there a way to ensure that FG is sending out its outputs in floating point format, because I'm not sure it is, I have the generic file setup for binary mode, but I'm not convinced that FG is transmitting data as floats, I think it might actually be transmitting data as integers or something else. I make this observation because the data I did get cause an action in my algorithm which didn't make sense. The auto pilot switched to flight mode while still on the ground, it wasn't susposed to do that until it reached 1800 feet, so thats why I'am assuming that the output it received from FG as the altitude couldn't have been in floating point format it must have been an integer or maybe a double, or something but whatever it was it wasn't a float. The good way to verify if the transmission of float values work is to print the value in your receiver and compare that to the value of the property you transmit in FG. Btw. if your generic protocol is set to use network byte order (endianness MSB) you have to take that into account when unpacking the float value. I looked at the perferences file in the FG directory, and I changed all the double types to float, should that do it? I loaded it under the configuration option in the advanced options menu, but when I started FG back up and hit the / key and looked at the outputs the values still said double. No, don't do that. It should have no influence on this issue. The sender code converts the property value to float before encoding it. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- 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 -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
Right, as you noticed, it doesn't appear that the generic interface code is setup to transmit and receive at the same time. You can't open up the same device twice, so you two command line options won't work either. As far as I can tell this will require some code modifications if you want to use direct serial communcation. Another option might be to write a thin glue layer that talks to FlightGear over the network, and talks to your hardware over a serial port and then does all the appropriate data translation as required. What properties are you importing into FlightGear? You can open up the property browser and check to see if they are being changed as you expect. Curt. On Mon, Aug 8, 2011 at 9:21 AM, Derrick Washington ddwas...@gmail.comwrote: So I tried it with the joystick unplugged and nothing changed, FG will transmit, and it will receive just not at the same time, no matter how I try to trick it, I can't even get it transmit on one port and receive on another (using serial). Is it possible that someone can create a fix for this? On Sun, Aug 7, 2011 at 5:44 PM, Derrick Washington ddwas...@gmail.comwrote: OK So I believe I've got it to work on COM27 by using the \\.\COM27syntax. I still have a problem sending and receiving at the same time, FG will not allow me to open up multiple generic serial protocols to the same COM port for in and out, only one at a time and bi directional doesn't seem to be supported. On Sun, Aug 7, 2011 at 12:39 PM, Gene Buckle ge...@deltasoft.com wrote: On Sun, 7 Aug 2011, Frederic Bouvier wrote: Gene, Unless you've got 26 other serial ports on that machine, I'd strongly suggest researching what caused Windows to assign COM27 to your device. It's NOT typical behavior. You can assign any number you want to a COM port when it is driven by a USB-to-COM or Ethernet-to-COM adapter. Simply go to the Device Manager and set it between 1 and 255. I know that, but most of the time you don't specifically set a COM port number by hand - you let Windows pick the next un-used port #. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ 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 -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
Press the / key or it should also be a menu option. On Mon, Aug 8, 2011 at 10:12 AM, Derrick Washington ddwas...@gmail.comwrote: As far as I can tell this will require some code modifications if you want to use direct serial communcation. Yeah I figured that, hmmm I'm not very familiar with FG's source code at all, and I downloaded the exe, can any of you make a suggestion as to what I might attempt to correct? What properties are you importing into FlightGear? You can open up the property browser and check to see if they are being changed as you expect. I included the xml file I am using in the email, and I'm afraid I don't know how to open up the property browser, but I'll look at the documentation and check. On Mon, Aug 8, 2011 at 10:27 AM, Curtis Olson curtol...@gmail.com wrote: Right, as you noticed, it doesn't appear that the generic interface code is setup to transmit and receive at the same time. You can't open up the same device twice, so you two command line options won't work either. As far as I can tell this will require some code modifications if you want to use direct serial communcation. Another option might be to write a thin glue layer that talks to FlightGear over the network, and talks to your hardware over a serial port and then does all the appropriate data translation as required. What properties are you importing into FlightGear? You can open up the property browser and check to see if they are being changed as you expect. Curt. On Mon, Aug 8, 2011 at 9:21 AM, Derrick Washington ddwas...@gmail.comwrote: So I tried it with the joystick unplugged and nothing changed, FG will transmit, and it will receive just not at the same time, no matter how I try to trick it, I can't even get it transmit on one port and receive on another (using serial). Is it possible that someone can create a fix for this? On Sun, Aug 7, 2011 at 5:44 PM, Derrick Washington ddwas...@gmail.comwrote: OK So I believe I've got it to work on COM27 by using the \\.\COM27syntax. I still have a problem sending and receiving at the same time, FG will not allow me to open up multiple generic serial protocols to the same COM port for in and out, only one at a time and bi directional doesn't seem to be supported. On Sun, Aug 7, 2011 at 12:39 PM, Gene Buckle ge...@deltasoft.comwrote: On Sun, 7 Aug 2011, Frederic Bouvier wrote: Gene, Unless you've got 26 other serial ports on that machine, I'd strongly suggest researching what caused Windows to assign COM27 to your device. It's NOT typical behavior. You can assign any number you want to a COM port when it is driven by a USB-to-COM or Ethernet-to-COM adapter. Simply go to the Device Manager and set it between 1 and 255. I know that, but most of the time you don't specifically set a COM port number by hand - you let Windows pick the next un-used port #. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ 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 -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
Inputs: what inputs are you sending? Are they getting overwritten by internal processing? If you are inputting position and orientation (for instance) you need to turn off the internal flight dynamics engine (--fdm=null) If you are inputting control surface positions, you probably don't want a joystick plugged in, etc. On Sun, Aug 7, 2011 at 6:12 AM, Arnt Karlsen a...@c2i.net wrote: On Sat, 6 Aug 2011 23:09:44 -0400, Derrick wrote in message CAF74wjbov8xiA26W3_n2EA6HX04B2_8+U6mPn=9votkv8hu...@mail.gmail.com: OK so I found a solution, I think, I changed the COM port number to COM3. That seems to work but now FLIGHTGEAR will not accept inputs for some reason, when I set as shown below, FG just sits there and spins its wheels. If I set it up for output that works just fine. In addition to that I can't setup two generic protocols one for input and one for output, when I do that I just get an error can not open com port. I'm beginning to think that communication through the serial port doesn't work at all. C:\Program Files\FlightGear\bin\Win32\fgfs.exe --fg-root=C:\Program Files\FlightGear\data --fg-scenery=C:\Program Files\FlightGear\data\Scenery;C:\Program Files\FlightGear\scenery;C:\Program Files\FlightGear\terrasync --aircraft=f-14b --control=joystick --enable-random-objects --enable-ai-models --enable-clouds3d --fog-disable --geometry=1280x1024 --bpp=32 --texture-filtering=16 --timeofday=noon --atlas=socket,out,5,localhost,5500,udp --generic=serial,in,3,COM3,115200,FlightGear_GPI ..tried --generic=serial,in,3,\\.\COM3,115200,FlightGear_GPI? -- ..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. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ 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 -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
I personally have never tested the generic protocol over a serial port on windows. I'm not sure I have tested any IO over a serial port on windows since the very early days of the project back when we were building with cygwin. I do recall at the time being (this is maybe 10 years ago at least?) being confused between using COM1 vs. COM1: (with a colon at the end.) I honestly don't remember which one worked and which one didn't. Have you tried it both ways? Personally I run Linux 99% of the time, so anything I've done with serial ports and FlightGear (in recent memory) has been under Linux. Perhaps you could also try sending nmea out instead of the generic protocol to see if that work? Maybe someone here or on the forum has done serial port coms with windows recently and can speak up??? For what it's worth, my UAV autopilot has an ethernet interface so I've been doing my HIL sensor/control surface interface through the network ... Regards, Curt. 2011/8/3 Derrick Washington ddwas...@gmail.com -- Forwarded message -- From: Derrick Washington ddwas...@gmail.com Date: Aug 2, 2011 12:49 AM Subject: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified. To: curtol...@gmail.com Hi Curt I have been trying for a few weeks now to get FG to transmit data to a serial port COM27 via the generic protocol, and for some reason unknown to me the simulator simply will not comply. I have several other programs which use this port with out a problem, I am using a usb to serial cable GigaWare I'm not sure what exactly is going on but I really could use some developer insight on this one. I had planned to use FG as a the simulation platform for my autopilot design. I have the hardware and software already to go, just need to get FG talking to the serial port. 3 - 'C:\Program Files\FlightGear\terrasync' C:\Program Files\FlightGear\bin\Win32\terrasync.exe -S -d C:\Program Files\Flig htGear\terrasync -p 5500 Airports/K ... Error opening serial device COM27 The system cannot find the file specified. Error opening device: COM27 Error opening channel communication layer. I/O Channel config failed. C:\Program Files\FlightGear\bin\Win32\fgfs.exe --fg-root=C:\Program Files\FlightGear\data --fg-scenery=C:\Program Files\FlightGear\data\Scenery;C:\Program Files\FlightGear\scenery;C:\Program Files\FlightGear\terrasync --airport=KMDW --runway=13L --aircraft=f-14b --control=joystick --enable-random-objects --enable-ai-models --enable-clouds3d --fog-disable --bpp=32 --texture-filtering=16 --timeofday=noon --atlas=socket,out,5,localhost,5500,udp --generic=serial,out,5,COM27,9600,FlightGear_GPO -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ 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 -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The state of things in Flight Gear
I agree there is always a need for more and better documentation and I certainly agree that FlightGear is under documented. However; it is not like we have a complete absence of documentation. There is a ton of information on the wiki. There is a ton of information included in the documentation directory of the source code. There is an entire doxygen tree you can generate for simgear that has been pretty carefully constructed. We have a mailing list, forum, and irc where people can ask questions about things where they haven't found adequate documentation. Most developers are pretty open about their identity so it's often possible to contact someone directly if you have a specific question about their work. There are some additional documentation challenges not mentioned yet. Everyone approaches the FlightGear project from a different background, different direction, different amounts of capabilities, different amounts of experience, and different goals for what they want to get out of their experience. It is pretty overwhelming to think about creating a body of documentation that would adequately address the information needs of everyone at all times ... not to mention FlightGear is a pretty rapidly moving target. One response to all of this that we see frequently and is greatly appreciated (!!!) is when someone comes to our project, recognizes a need or lack of something (like documentation) and decides they are going to roll up their sleeves and do something about it. FlightGear is never going to have top down authoritarian leadership like a large corporation might have. This is good in many ways, but is also creates challenges in many ways. I often see my roll more as a facilitator for the efforts of developers who are working on their own priorities rather than a corporate style manager that rules with an iron fist and dictates exactly what each developer is going to work on at any given time. One of the the core reasons that FlightGear is successful is because developers can come here and outlet their creative energy in a relaxed environment ... getting away from their stressful day job where they are told what to do and how soon it needs to be done. Best regards, Curt. On Wed, Jul 27, 2011 at 12:37 PM, Hal V. Engel hven...@gmail.com wrote: ** On Wednesday, July 27, 2011 04:04:09 AM Slavutinsky Victor wrote: Moreover, that explanations not provided not for me only but for anyone. It's open source but way it open it can not be developed by ones for whom it seems to be open. That's the real problem what I can not solve, and, I suppose, no one outside of FG community can. The lack of internal documentation is an issue for many of not most open source projects. One reason for this is that it is a big undertaking to completely document a system of the complexity of FG. For example I just finished (meaning that it is good enough - not that it is perfect) documenting a Class for another project. This was a relatively simple class with about 22 methods. I spent the better part of a week's full time effort to document it and I wrote the code so I knew what it did before I started working on the documentation. I have not looked at the FG internals but I would guess that it has hundreds of Classes and many of these are likely more complex than the one I just documented. So writing detailed internal documentation for FG would probably keep some one occupied full time for the better part of a year. In the long run having this documentation would help the project but it is a huge undertaking. In addition, it is an undertaking that has little if any short term impact on the project which makes it even less attractive for potential contributers. Hal -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ 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 -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Martin is responding slowly ....
Wow, congratulations!!! Hope everyone is healthy and doing well! On Mon, Jul 25, 2011 at 10:14 AM, Martin Spott martin.sp...@mgras.netwrote: Hi, if anyone is wondering why I'm responding even slower as usual, this might be caused by the simple fact that I'm being distracted by our daughter who was given birth last night. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Storage Efficiency Calculator This modeling tool is based on patent-pending intellectual property that has been used successfully in hundreds of IBM storage optimization engage- ments, worldwide. Store less, Store more with what you own, Move data to the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ ___ 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 -- Storage Efficiency Calculator This modeling tool is based on patent-pending intellectual property that has been used successfully in hundreds of IBM storage optimization engage- ments, worldwide. Store less, Store more with what you own, Move data to the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG 2.4 consistency
/appsumosfdev2dev ___ 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 -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG 2.4 consistency
Every road runs in two directions, and if we are all willing to go a little bit beyond half way to meet each other, we most often will get there. On Wed, Jul 13, 2011 at 1:01 PM, Martin Spott wrote: Curtis Olson wrote: I think Gene put it well. We need to give them the benefit of the doubt and cut them some slack due to potential language/translation issues [...] Sure, I doubt that this is a translation issue here: Does it strip the affront off an affront just by passing it through a slightly too straightforward translation ? I'd recommend to apply the potential language/translation issues on a case-by-case basis. Likewise I hope they will [...] be willing to learn our project culture in return. Precisely this is the point. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ 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 -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG 2.4 consistency
The nice thing about FlightGear is freedom. The grth_team is free to do what they wish. They can develop what ever they want and they can support whichever versions they deem best as long as they abide by the terms of the gpl. It might take some time to realize this, but it is very hard to guilt and bully open-source folks into doing something. For many of us, we put up with too much of that in our day jobs and we come to projects like FlightGear to outlet our talents in a more relaxed and positive environment. The Cat is a cool airplane (I've flown in one myself when I was 5 years old), but it seems a little childish if someone wants to threaten that they will take all their toys and go home if we don't do things exactly as they wish. I've heard many variants on that theme over the years. I want to do whatever I can to create an environment where people can have a positive outlet for their talents and energy, and I want to encourage that process as much as possible. But if people don't feel that this is the place for them, why make a big deal out of it and setup various ultimatums and backhanded threats. Find someplace better, may the force be with you, thanks for all the fish. Peace! Curt. On Wed, Jul 13, 2011 at 5:56 PM, Csaba Halász csaba.hal...@gmail.comwrote: On Wed, Jul 13, 2011 at 3:24 PM, grth_team grtht...@gmail.com wrote: We have learnt we must not contribute to GPL update within FG, since the FG team answers does not convince us to contribute, we do not want to waste time. To please to the users, our model will be ever checked against an FG stable version. We will start that rule with FG 2.4, offering our models within our pages, but, under an other license. I fail to see how your problem has anything to do with licensing. -- Csaba/Jester -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ 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 -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 63, Issue 5
Hey Guys, The era of respect is only over if people choose to abandon it. I think we can all hope for something better than that. Let me summarize how things generally have worked and (I believe) should work. An author of an aircraft (or a section of code) generally enjoys a certain level of ownership over that work. If someone would like to make some substantial changes to that work, they really owe the author (out of respect) some communication and interaction and willingness to defer to the wishes of the original author if there are differences in ideas. Ideally this communication would happen on our developers mailing list so that others can pitch in with their thoughts. Sometimes the original author is busy at the moment, or may not care if others make changes or improvements. Sometimes they might care, or have a different or better way to solve an issue that they would prefer. The author on the other hand contributes their work to the project under the terms of the GPL knowing that they do give up some control. The benefit is that if some other part of the code is changed, and your work needs to be tweaked to continue to operate correctly, someone else can make those tweaks automatically while they are fixing everything else. If someone does cross the line from either side and do too much with too little communication, I think it's worth examining the intentions and remembering that git gives us the opportunity to have communication after a problem is discovered and back track if needed or find a better solution. Also, please, when it comes to respect, if someone does make an error, shouldn't our first reaction be to assume the best intentions? Especially when the person has a history of working hard to improve the code and aircraft? Getting upset is maybe ok later after we've exhausted reasonable attempts to resolve the situation respectfully. At the end of the day, if people push the GPL to the limits of what they can get away with, we end up with another proflightsim situation where everyone is upset and no one is happy. The legal terms set ultimate boundaries, but they don't necessarily imply policy or culture, and they don't mention respect at all. Instead people should of course treat each other with respect. Both in handling each others work, and in communication on this mailing list or the forum. And let's also be willing to cut each other a *little* bit of slack if someone steps on or near our toes. Let's first try to steer conflicts in a positive direction. And too often someone(s) from the sidelines are a bit too quick to jump in with their own me too comments which usually just make the situation worse. Seriously, life is so much better and so much more pleasant when we work together. Even friends will not agree on everything, so there can be some healthy discussion. That is good. I've had enough ideas myself to know that not every one of them is going to be a winner. But there are a few people (and maybe a few combinations of people) that should seriously consider these words and really could try to do better. I want this email to be positive, so that will be the extent of my scolding. :-) I think most of us here are adults and understand how to interact with fellow human beings in a positive constructive way. I know there are younger folks here too, and I bet they have also already learned how to be positive and get along. Some of us just happen to forget once in a while I guess. Regards, Curt. On Mon, Jul 11, 2011 at 1:52 PM, Melchior FRANZ mfr...@aon.at wrote: Now I have to clarify: I assume Thorsten just did what he does since a while: fix bugs. Which is great. He probably either thought the bo105 is no longer maintained, or didn't know the (now obsolete?) maintenance principle. But there were certainly no bad intentions. What I'm more concerned about are those people who apparently think that maintainers (who are usually the *creators* -- who spent hundreds of hours for an aircraft) should just shut up and let others interfere without complaining. Now, you may claim that by not committing much in a long time to the bo105 I have already given up maintenance. Wrong. As long as I haven't explicitly said so and am still reachable via email in a reasonable time, I have not. Of course, I have plans to continue the bo105. But guess who makes the schedule? m. -- 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-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson
[Flightgear-devel] Hudson build question
The latest git/next windows build on the Hudson server expects osg78 dll's, however the newest 3rd party stuff appears to include osg80 dll's. Is this a temporary glitch or transition in the hudson server, or is there something I need to know in terms of policy about what packages go with which packages to create a running system. Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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-d2d-c2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Hudson build question
Update ... fgrun.exe seems to be built with osg78 dll's fgfs.exe seems to be built with osg80 dll's What would it take to get fgrun building against osg80 dll's so we only have to ship one version of osg? Thanks, Curt. On Tue, Jul 5, 2011 at 11:09 AM, Curtis Olson curtol...@gmail.com wrote: The latest git/next windows build on the Hudson server expects osg78 dll's, however the newest 3rd party stuff appears to include osg80 dll's. Is this a temporary glitch or transition in the hudson server, or is there something I need to know in terms of policy about what packages go with which packages to create a running system. Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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-d2d-c2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Hudson build question
One more update: I went on the hudson server and manually requested a rebuild of fgrun and the newest build seemed to automatically pick up the latest osg libs. I guess there's no dependency link with the 3rd party updates (not sure if that's even possible if it comes from an external source.) Hopefully I'm good now ... Curt. On Tue, Jul 5, 2011 at 11:43 AM, Curtis Olson curtol...@gmail.com wrote: Update ... fgrun.exe seems to be built with osg78 dll's fgfs.exe seems to be built with osg80 dll's What would it take to get fgrun building against osg80 dll's so we only have to ship one version of osg? Thanks, Curt. On Tue, Jul 5, 2011 at 11:09 AM, Curtis Olson curtol...@gmail.com wrote: The latest git/next windows build on the Hudson server expects osg78 dll's, however the newest 3rd party stuff appears to include osg80 dll's. Is this a temporary glitch or transition in the hudson server, or is there something I need to know in terms of policy about what packages go with which packages to create a running system. Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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-d2d-c2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A new goodie for FlightGear presentations
On Fri, Jul 1, 2011 at 1:23 AM, Torsten Dreyer tors...@t3r.de wrote: Hell, No! Isn't buying a complete plug'n play panel contrary to the spirit of an open-source project? Despite the fact that it it goes way beyond the limits of our budget, our own tool fgpanel is able to deliver convincing results for the gauges. At LinuxTag and FSWeekend, we were able to fool many visitors with our setup and some still did not believe what they saw untilt they actuallty touched the screen. I'll back up Torsten on this! There's a sim company (ATC Flight Sim) in California that I've done some work for over the years. They use FlightGear as their software core (and have achieved FAA certification for their sim by the way ... which means FlightGear is FAA certified or is FAA certifiable depending on how carefully the marketing guys want to word things ... other sims like X-Plane perhaps are a little sloppy with how they refer to their own sim with respect to FAA certification). ATC Flight Sim does exactly what Torsten does ... draw the instrument gauges in 2D on an LCD display and then put a flat panel over the top with holes cut out for the instruments to show through. ATC goes a step further and machines bezels to go around the perimeter of the openings and even has knobs right on the panel where they are supposed to be. We took their simulator to an AOPA convention one year and it was quite entertaining to listen to comments as people walked up. Guys would approach and quite confidently say ... Oh, they are using Company ABC's gauges. People would sit down, fly for 10 minutes, and afterwards not believe us when we told them the gauges were all drawn with computer graphics on an LCD screen. We had to let some people touch the screen before they'd believe us and even then I'm not sure. Lots of advantages to using an LCD screen: no calibration or adjustment, instant startup, no need to unwind the altimeter for 60 seconds to start the next session on the ground. No rats nest of wires behind the panel, no need for a boatload of little embedded cpu's to drive all the PWM out signals. Another issue is the radio stack (which is unfortunately missing mostly in our Cessna). I'm looking for a used, preferrably nonfunctional stack of King (kx155/165 etc.) radios, so I can use the original controls and replace the electronics by some microcontroller driven hardware. Yeah, that's a harder one. ATC actually designed their own stack with very realistic looking seven segment displays, knobs, and panels. They did all the backend hardware and computer interface too. Doing this on a second display with computer graphics would be an option, but the knobs would be in the wrong place and it just wouldn't be nearly as convincing or nice as dedicated hardware. (Please ignore how I start this message praising 2d graphics on an LCD screen and then finish the message praising dedicated hardware.) :-) Looking forward to seeing what you guys come up with. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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-d2d-c2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Matrox TripleHead2Go
Yes, John (LFSTech.com) has done some very nice work developing code that will do image warping and edge blending right inside FlightGear which is very cool. My understanding is we are waiting for Tim to review the changes and integrate them into the code base. Regards, Curt. On Sun, Jun 26, 2011 at 11:13 PM, John Wojnaroski cas...@mminternet.comwrote: On Sun, 2011-06-26 at 16:38 -0700, Gene Buckle wrote: On Sun, 26 Jun 2011, Torsten Dreyer wrote: Buenos Dias Ezequiel and welcome aboard! We have a fairly complex multi-monitor display setup on our presentation machine. You can find our configuration from last year's FSweekend at http://wiki.flightgear.org/FSweekend_2010. In rendering.xml, the first two camera entries show how to define viewports within one single window. You can define the frustum or perspective for each single viewport. For the correction of the parabolic distortion, I have no idea. But I remember that there was something presented along with the collimated display http://wiki.flightgear.org/FlightGear_Newsletter_November_2010#Amateur_built_collimated_display Maybe Gene or Tim can chime in here? Perhaps you might also look at the March 2011 newsletter. http://wiki.flightgear.org/FlightGear_Newsletter_March_2011 I know there was some work done in order to pre-warp the output from FG, but I'm not sure what the status of that is. Because of NThusim+, I wasn't paying that close attention to it (and I should have been). -- 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-d2d-c2 ___ 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 -- 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-d2d-c2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download / built-in
I think Thorsten has been doing a marvelous job. I see the changes flow by in the commitlogs emails, and it probably goes unsaid too often, but it's clear who has been putting in the effort to deal with user bug reports, tricky bits of code, and a whole host of other issues. There are always a few negative voices in any forum and they often project too loudly and too often. Sometimes saying things once and then letting it be is a better strategy. Thoughts and ideas take time to sink in, and bashing people over the head repeatedly does not usually accelerate the process. There are a few developers who are very smart, have a good knowledge of FlightGear, and are well intentioned, but have trouble unwrapping a negative tinge from many of their messages. I think they find that this style is an effective way to communicate their concerns, and probably feel that it will motivate others to take their words more seriously. But I'm serious in saying that for each one of these, there are 50 or maybe 100 others out there who do see the effort and who do appreciate it, but hesitate to contribute to the discussion for any number of reasons. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear used in brain-control programm
On Sun, Jun 5, 2011 at 8:20 AM, Gijs de Rooy wrote: Interesting use of FlightGear! http://www.northeastern.edu/news/stories/2011/05/http://www.northeastern.edu/news/stories/2011/05/braincontrol.html braincontrol.htmlhttp://www.northeastern.edu/news/stories/2011/05/braincontrol.html Cool project! Thanks for sharing the link. I wonder if we could get someone from the team to write a 2-3 paragraph newletter article with a picture or two? Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] gnome 3 ?
This weekend I took the plunge and upgraded my main desktop machine to Fedora 15 + Gnome 3. Out of the gate I hit some serious culture shock, but I'm starting to get the hang of the new gnome interface and it's growing on me quickly. There are many good reviews posted online explaining the new gnome 3 interface, but I figured I'd post my own thoughts too: http://gallinazo.flightgear.org/technology/fedora-15-and-gnome-3/ FlightGear seems to compile and run pretty much exactly as before with Fedora 14, so no complaints there. So far so good ... ! Curt. On Fri, Jun 3, 2011 at 3:24 AM, Chris Baines wrote: I use Gnome 3 and FlightGear and it works well. I do like the Shell, and after a while it does grow on you. The main problem I think is that people logically think that as Gnome 3 is released the Shell is completed, where that is far from the truth, much of the work is still to be done. As you point out its hard to configure and might not be as intuitive as it could be but it looks like an alright base to work from. On 3 June 2011 08:54, Stefan Seifert n...@detonation.org wrote: On Friday 03 June 2011 06:10:24 Curtis Olson wrote: Looks like the linux desktop folks have stopped chasing windows and are now chasing mac? Quote from an online review: gnome 3 gives you any color theme you like ... if you like black. s/linux desktop/Gnome/ There's still KDE and all the lighter desktops available which do not force anything on you. And according to a phoronix comparison, the KDE window manager seems most of the time to be the one affecting performance the least. And if that's still too much, deactivating desktop effects is just a shortcut away. http://www.phoronix.com/scan.php?page=articleitem=linux_desktop_managers1num=1 Stefan -- 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. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- 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. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ 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 -- 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. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] modelling an battery powered electric motor MAV
Hi Gaurav,
For questions specific to JSBSim code, you might also ask on the jsbsim
mailing list (details at www.jsbsim.org) -- although I'm sure several of the
developers are subscribe to both flightgear and jsbsim devel lists.
One other thought if you want to avoid changing C++ code or you wish to
support versions of FlightGear that are already released, is that you might
be able to create a simple battery model using Nasal (flightgear's embedded
scripting language.) You could perhaps limit maximum throttle position
based on the output of your battery simulation to simulate the what happens
as your battery is used up (or to simulate an aging battery, etc.)
I know batteries are pretty complex if you dig into them, but you could
probably hack something simple really quickly that would get you 90% of the
way there and cover most of the situations you would be concerned about.
Curt.
On Fri, Jun 3, 2011 at 2:49 AM, Gaurav Tendolkar grvtendol...@gmail.comwrote:
I am modelling an battery powered electric motor MAV.
In JSBsim the battery does not discharge.
00178 FGElectric::CalcFuelNeed(void)00179 {00180 return 0;00181 }
now i want to write a code where fuel is the power supplied by battery.
by knowing the total stored energy we will calculate time to discharge.
How do i make the changes to the code come to effect in flightgear ?
--
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. Discover what all the cheering's about.
Get your free trial download today.
http://p.sf.net/sfu/quest-dev2dev2
___
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
--
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. Discover what all the cheering's about.
Get your free trial download today.
http://p.sf.net/sfu/quest-dev2dev2 ___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 3d model orientation
Hi, I have a question. I have a 3d model of an aircraft that I want to rotate in roll, pitch, and yaw just like any other aircraft. I also have stream lines from a CFD program that I would like to display at the same time over the top of the model. (Hi Matthias) :-) My aircraft is a skydiver and the way the 3d model and FDM are setup, it basically falls straight nose down (pitch -90) so that alpha is close to zero. (The 3d model is adjusted so that it is in the correct pose when falling. When pitch and roll are zero it is standing straight up and down ... so nose over to a -90 degree pitch angle and he is falling face down like he should be.) The streamlines basically need to stay vertical no matter what the orientation the 3d model is at since we are always falling pretty much straight down or close enough. I had been copying off some of our fake shadow hacks to rotate the streamline model in -roll and -pitch to keep it aligned straight up and down. That almost works -- except most of the time we are flying very near a pitch angle of -90. This puts us at a euler angle singularity. What happens is that the streamlines stay properly positioned straight up and down as I intend, but as we get closer and closer to that magic pitch angle of exactly straight down, the heading angle starts to blow up. The result is that the streamline heading orientation doesn't track the model orientation correctly and the errors get worse and worse the closer we are to a pitch angle of -90. Is there any other way to attach a sub model to the aircraft model, but control the submodel orientation in NED space rather than having to hack a transform opposite of the model roll/pitch angles? Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] gnome 3 ?
Is anyone here running gnome 3 (and you would probably know if you were.) :-) I just loaded up Fedora 15 on a test machine and my first comment was hmmm... I haven't tried to get FlightGear running. I guess I can't imagine why it wouldn't run just fine although the desktop requires accelerated opengl hardware so I hope there won't be too much competition for resources when running FlightGear. Does anyone have any feed back on issues or problems specific to the new gnome 3 desktop scheme? Building/running FlightGear? Looks like the linux desktop folks have stopped chasing windows and are now chasing mac? Quote from an online review: gnome 3 gives you any color theme you like ... if you like black. Is gnome 3 viable for real work? I've heard gnome 3 and intuitive mentioned in the same sentence. I guess I'm going to have to go lookup the definition of intuitive again -- oh here it is -- something that makes obvious sense after you've figured it out. :-) Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 2d panel visibility
I could be imagining this, but I seem to recall a while back, someone asking if it was possible to keep a 2d panel visible all the time, even in external views. I just took a quick peek at .../Cockpit/panel.cxx and it doesn't appear that we have the ability to do this, but I just thought I'd ask in case there is some other mechanism someone has added? I am working on a project where we are modeling a skydiver in free fall, and we want to display some basic information on the edge of the screen (like decent rate). But because this is not an aircraft, it makes more sense to use external views. Also we are trying hard to avoid needing to modify source code, and we'd like to do this in v2.0 (the most current release). The HUD would be another alternative, but we'd like to avoid needing to extend the HUD code to add our specific widgets. Perhaps we could use gui widgets and display the information numerically, but an instrument communicates the data so much better. Are there any other options or ideas that I'm missing? Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] 2d panel visibility
Thanks everyone for the responses. So far the Anders' suggestion of using screen.nas seems to have the most promise. Torsten: I have another project I want to use the fgpanel system for, but with this project we are trying to keep the logistics of starting things up as simple as possible, also I'm not sure how you would keep the fgpanel display in front of the FlightGear display if you had to click on the flightgear display to interact with it? Hal: it's important with this particular project to have the instrumentation attached to the screen when the view changes or pans around, even in tower or fly-by views we want to see the instrumentation clearly. Regards, Curt. On Tue, May 31, 2011 at 2:51 PM, Hal V. Engel wrote: On Tuesday, May 31, 2011 11:00:58 AM Curtis Olson wrote: I could be imagining this, but I seem to recall a while back, someone asking if it was possible to keep a 2d panel visible all the time, even in external views. I just took a quick peek at .../Cockpit/panel.cxx and it doesn't appear that we have the ability to do this, but I just thought I'd ask in case there is some other mechanism someone has added? I am working on a project where we are modeling a skydiver in free fall, and we want to display some basic information on the edge of the screen (like decent rate). But because this is not an aircraft, it makes more sense to use external views. Also we are trying hard to avoid needing to modify source code, and we'd like to do this in v2.0 (the most current release). The HUD would be another alternative, but we'd like to avoid needing to extend the HUD code to add our specific widgets. Perhaps we could use gui widgets and display the information numerically, but an instrument communicates the data so much better. Are there any other options or ideas that I'm missing? Thanks, Curt. Have you thought about modeling the skydiver as an aircraft with the cockpit being the view out of his/her goggles? The panel would be nothing and the instruments could be just positioned about a meter in front of the pilots point of view. You could then keep the instruments in view as the pilot changed his view direction (IE. look up, down, left, right) by rotating them about the pilots head. You should be able to do all of this using the existing XML. Or you could create a 3D model for the skydivers body and possition the instruments on his/her body (IE on the top of the belly mounted chute pack) so that you need to look down to see them. Hal -- 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 -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] SimGear compilation problem with MS VisualStudio 10
Arnt, different compilers often catch different subtle errors, so it is good and healthy to run our code through a variety of compilers on a variety of platforms. Gcc isn't perfect. Unfortunately I'm can't offer specific help for this particular problem, but hopefully one of our other windows developers can think of something to suggest. Curt. On Fri, May 27, 2011 at 1:36 PM, Arnt Karlsen wrote: On Fri, 27 May 2011 12:55:24 -0400 (EDT), Claus wrote in message : Hello all, I am trying to build FG in Windows 7, using Visual Studio 10. ..ah. Historically, Microsoft has made use of it's tools and tools to discourage the use of other peoples SW, this _may_ be the case here too: http://groklaw.net/article.php?story=2009042327711 A part of that process is simgear, and that gives me some trouble... I eliminated all compile errors with the exception of this one: 1c:\users\claus\desktop\flighgear-dependencies\simgear-2.0.0\simgear\scene\material\effectbuilder.hxx(134): ..are you trying to build simgear-2.0.0 ??? 1error C2440: 'specialization' : cannot convert from 'std::string 1std::_Pair_base_Ty1,_Ty2::* ' to 'std::string 1std::pair_Ty1,_Ty2::* ' 1 with 1 [ 1 _Ty1=std::string, 1 _Ty2=osg::StateSet::RenderingHint 1 ] 1 Standard conversion from pointer-to-member of base to 1 pointer-to-member of derived is not applied for template arguments Googeling only brings up https://svn.boost.org/trac/boost/ticket/3106 which unfortunately doesn't help me much. I am using boost 1.46.1. Any ideas? ..tried alternative tool sets?: http://beans.seartipy.com/2006/12/31/six-popular-ides-for-developing-software-in-cc-on-windows-platform/ http://www.google.com/search?num=100hl=enq=gcc+windows+ide+C%2B%2Baq=faqi=aql=oq= ..if the problem is VS10, one of these should succeed, or give you an _other_ error than yours above here. If it stops on the same error, you have found a simgear bug. -- ..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. -- 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 -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] OSG + vrml plugin
Hi Mathias,
Thanks for the reply. It appears that removing the CMakeCache.txt file did
the trick. Now it finds the openvrml libs and builds the plugin. It turns
out I still can't view the wrl file though ... it's a whole bunch of line
segments which maybe isn't supported by the vrml plugin? I might have to
see if I can hack a script to convert it to ac3d format or find some other
tool that can import the file correctly and then export it again as
something else. Blender unfortunately only supports vrml-1.0 and the file
I'm working with is vrml-2.0.
The wrl file is CFD streamlines around a 3d model so I'm hoping it will look
really cool if I can get it to load and render in flightgear ...
Curt.
2011/5/22 Mathias Fröhlich
Hi Curt,
On Saturday, May 21, 2011 20:19:01 Curtis Olson wrote:
Has anyone built the vrml plugin for OSG under linux (fedora). The
README.txt says I need boost and openvrml installed. I've installed
openvrml and libopenvrml{,-devel}, and rerun ./configure but the vrml
plugin still isn't getting built.
Apparently I don't know enough about cmake to trace through the scripts
and
figure out what the findvrml plugin is looking for specifically. I'm
not
even sure that module is getting run or how to tell cmake to even look
for
openvrml?
Does anyone have any tips or suggestions?
Just a general note on the vrml plugin:
I am using this plugin at work to double check a vrml exporter on linux. It
can read many vrml files. But it fails on some. So if something does not
look
as expected, you might run in one of these failures.
From what you write:
Did you remove the CMakeCache.txt file before retrying the configure step?
If not, try this and then rerun your configure script or the cmake command
you
usually run.
I had some problems to detect and run the vrml stuff due to the openvrml
libs
being not installed in the standard library paths. So, I needed to add some
LD_LIBRARY_PATH et al magic to get that detected and runnning. But since
you
work with the distribution provided stuff, I do not exepct that this will
be a
problem.
May be this helps a little?
Mathias
--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including 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
--
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including 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] OSG + vrml plugin
2011/5/22 Mathias Fröhlich No, the line segments are not supported. At least not in the current release version. My line segment support is checked in with revision 11290. So you may backport that pach to the current release version. BTW, I needed the line segments in vrml for exported models for a cfd visualization where I could not see the streamlines with osgviewer :) Hi Mathias, Sounds strangely familiar! :-) Is there a particular minimum dev version I could find this patch in? I've been hanging around with v2.9.7 of OSG here because of compatibility problems of the newer versions. It looks like there is some IndexedLineSet references in the 2.9.9 version of the code -- is that the patch you are talking about? What kind of CFD are you doing? We are using Fluent, although I'm not directly involved in the CFD portions of the project, just trying to help visualize the end result with FlightGear. What CFD are you using? It would be kind of cool to work out a generalized approach for generating streamlines around our models at different attitudes and configurations (gear up/down, flaps, etc.) and then develop some system to pick the closest streamline model. Maybe it would be a job for nasal since the conditions for each model and related sets of streamlines could be wildly different. Regards, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including 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] OSG + vrml plugin
On Sun, May 22, 2011 at 11:33 AM, Curtis Olson wrote: Sounds strangely familiar! :-) Is there a particular minimum dev version I could find this patch in? I've been hanging around with v2.9.7 of OSG here because of compatibility problems of the newer versions. It looks like there is some IndexedLineSet references in the 2.9.9 version of the code -- is that the patch you are talking about? Hi Mathias, For what it's worth I back ported the v2.9.9 vrml plugin code to v2.9.7 and that compiles and works well. I'm able to see the streamlines in osgviewer at least. VRML is very verbose (especially this file) so load/parse times are very slow. :-( Might still be worth converting to something else for real time rendering. Thanks, Curt -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including 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
[Flightgear-devel] OSG + vrml plugin
Has anyone built the vrml plugin for OSG under linux (fedora). The
README.txt says I need boost and openvrml installed. I've installed
openvrml and libopenvrml{,-devel}, and rerun ./configure but the vrml plugin
still isn't getting built.
Apparently I don't know enough about cmake to trace through the scripts and
figure out what the findvrml plugin is looking for specifically. I'm not
even sure that module is getting run or how to tell cmake to even look for
openvrml?
Does anyone have any tips or suggestions?
Thanks,
Curt.
--
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including 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
