Re: [Flightgear-devel] Possible bug in yasim (not sure though?)
George Patterson wrote: Thanks Andy. I just completed a nice flight from KSFO to KLAX with 3D clouds turned on. Mistakenly misread 25L as being 24L. George Ooops, stop by the FAA office, do not pass Go, do not collet $200 ... Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runtime error 0.9.9 on Debian/Testing
Alex Perry wrote: I haven't tried to debug this yet, but thought I'd report it. $ fgfs opening file: /usr/local/share/FlightGear/Navaids/carrier_nav.dat /usr/local/share/FlightGear/Navaids/TACAN_freq.dat RenderTexture Error: glXCreateGLXPbufferPtr() failed. Initialising callsign using 'Aircraft/c172p/Models/c172p.xml' freeglut (fgfs): Failed to create cursor freeglut ERROR: Function glutSetCursor called \ without first calling 'glutInit'. Hey Alex, this has been a 'common' issue that has bit a lot of people. There appears to be a problem with freeglut 2.4. The solution has been to downgrade to freeglut 2.2 or run freeglut-cvs. You could also build with sdl (configure --enable-sdl) and that might side step the issue altogether. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Pending v0.9.9 release
Martin Spott wrote: RANTWe know exactly this phenomenon for several years now and to my observation very little changed in the meantime. The biggest success was to install a consensus that the pre-release phase should last at least two weeks. To my opinon two _months_ would be appropriate for such a complex piece of software that runs on so many different platforms and is maintained by such a small developer base. Unfortunately I didn't manage to crowd a significant number of supporters for this idea./RANT Actually there were times when I got on everyones nerves by continuously pointing at bugs or inconsistencies that I was unable to fix myself. Finally I realized that only reporting or documenting bugs (whereas the latter is a _really_ time-consuming task !!) without providing a fix was not that much welcome and I decided to engage with my own sub-projects that I am capable of running without external help. Martin, I'm not disagreeing with you, but would like to point out that there exists a perfect world with infinite time and infinite energy. But then there exists my world. When I get a window of opportunity I need to take it or we may not get a release for another year ... Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Pending v0.9.9 release
Buchanan, Stuart wrote: Curt, One follow-up question. Are we still following the convention of odd-numbered releases being dev and even being stable. I ask as the Getting Start Guide still thinks so, and I'll correct it if it is wrong. We tried that. 'Officially' 0.8.0 is the current stable release and 0.9.8 (0.9.9 pending) is the newest dev release. However, v0.8.0 was almost entirely ignored by almost everyone. We might have had a couple people running it for a short time. So I think you could remove that reference from the user guide. Oh, and in reference to your previous email. I believe there will be a windows binary made available for v0.9.9 (as well as for as many other platforms as possible.) I just haven't pushed it for the v0.9.9-prereleases. Thanks, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bus error SimGear XML Parser - 0.9.9-pre2
Arthur Wiebe wrote: Yeah the file is in CVS but it's not included in the 0.9.9-pre2 release base package. I guess I'll just use CVS base then. Yes, you should be able to use the file from cvs. I see I missed it when I created the v0.9.9-pre base package. It will be in the next release for sure. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] runfgfs
Buchanan, Stuart wrote: Hi All, I'm updating the getting started guide. It refers to runfgfs as the method to start FG. However, my cygwin build didn't install it, and I can't find it in my WinXP 0.9.8 install (though this is quite heavily modified). Is it deprecated, or are my installs wrong and it'll be included in the 0.9.9 releases and so should be documented as the way to run FG on Linux? Yes, the runfgfs batch file is now depricated. It has been replaced with a *much* nicer gui front end called fgrun. This gets installed automatically with the windows binary distribution. But people building FG from source will need to build it themselves. http://www.sf.net/projects/fgrun/ Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announcement: First TerraGear landcover database
Martin Spott wrote: Martin Spott wrote: We proudly present the first export from the TerraGear landcover database or however you prefer to name it. [...] You'll find some further information on this page refinement in process: http://web44.netzwerteserver2.de/212.0.html Martin. I should also point out that the next scenery build (which is happening concurrent to the v0.9.9 release and causing my head to spin 3x faster than normal (not factoring in beer)) will be based on this data export. The editing details are not fully worked out, but the ultimate goal is that end users will be able to refine specific areas (things like city outlines, river routes, roads, etc.) and submit them for inclusion in the next scenery build. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/c182 c182-set.xml, 1.6,
Martin Spott wrote: I can't resist the suspicion that there's something wrong with the 3D model. At least I get the glider to see and I yet didn't find yout why. Several XML files and the AC file do have DOS line endings but this doesn't cause the trouble I've already removed all of them, Anyone still having problems with this, even after the most recent round of instrument commits? Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FlightGear v0.0.9-pre3
Just a quick announcement that I rolled up v0.9.9-pre3 tonight. I had screwed up and missed a file in the base package, and then some other changes got snuck into simgear/flightgear so I figured I might as well roll out another try. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Pending v0.9.9 release
As some of you may have noticed, I completed a prerelease of FlightGear-0.9.9(pre1) and SimGear-0.3.9(pre1). I haven't heard any complaints about the prerelease, so I am planning to do a pre2 release this week. If all goes well and we have no major show stoppers, I would like to start working on the official v0.9.9 release next week and have it out by the end of next week (optimistically.) I'm trying to fit this into my own 'spare' time schedule so I may not be able to accomidate everyone's needs and wishes. But, there is always the next release if we miss something this time around. We haven't officially decided, but right now we are talking about doing a v1.0 release after the dust has settled on 0.9.9. That would likely happen sometime early 2006 after the holidays. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] wp altitudes
[EMAIL PROTECTED] wrote: I'm messing around with waypoints, ie race track loop around airports, etc... but found the [EMAIL PROTECTED] command doesn't seem to work with multiple waypoints altitudes... The plane eventually has it's own mind with regard to what altitude it wants to fly. I also tried the flightplan, but have the same isue. The altitude in the gui autopilot works very stable. So... is there a way to implement a series of waypoints at different altitudes? My next attack was going to cut into the route manger code in try to implement a file read to the autopilot data points, any input would be appreciated... Thanks for your help... Craig E. This used to work back when it was first implimented. You may want to check that the route manager is setting the same property name for target elevation that the autopilot is using. Downside of using properties for these things rather than C++ variables if you change one side and not the other, the compiler won't catch it for you, but the upside is a tremendous amount of increased flexibility and power so we live with it ... Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Which aircraft to include in v0.9.9?
I reserve the right to make the final determination (and all non-included aircraft will still always be available for separate download from the web site ...) Given that new aircraft have arrived on the scene since the last release, do we want to make any changes to the list of default aircraft included in the base package? The rule generally is that if we add one, we have to remove an existing one so the total number of included aircraft remains about the same... The current list is: data/Aircraft/737 \ data/Aircraft/A-10 \ data/Aircraft/bo105 \ data/Aircraft/c172 \ data/Aircraft/c172p \ data/Aircraft/c310 \ data/Aircraft/c310u3a \ data/Aircraft/Citation \ data/Aircraft/f16 \ data/Aircraft/j3cub \ data/Aircraft/Hunter \ data/Aircraft/p51d \ data/Aircraft/pa28-161 \ data/Aircraft/ufo \ data/Aircraft/wrightFlyer1903 \ Just glancing through the list very quickly, potential candidates for inclusion might be the b1900d, Citation Bravo, Concorde, dhc2, F-8E, Hurricane, Marchetti, MiG-15, seahawk, Spitfire, tu154 ... (?) Any opinions? Note that if you propose adding an airplane, you also have to say which one we remove from the existing list ... Thanks, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FlightGear v0.9.9-pre2
FlightGear v0.9.9-pre2 (second prerelease for v0.9.9) is now available for downloading and testing from the FlightGear web site (http://www.flightgear.org) It would be great if as many people as possible could download the tarballs for this release and build and test it on as many platforms as possible. Also note you will need the corresponding SimGear-0.3.9-pre2 (from http://www.simgear.org) The more build errors and platform bugs we can catch now, the smoother the v0.9.9 release will be for your favorite platform! I am currently targeting the official v0.9.9 release for late next week (time permitting.) Thanks! Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Please upgrade to version: 0.9.8
Georg Vollnhals wrote: Just as a feedback: it seems that the file management system (CVS/compiler) got confused as a I had the system clock set to 2006 for some time and are now back in 2005. Some older files might be considered to be the newest one due to the date of 2006 :-) There was no other way for me than to delete all CVS stuff (FlighGear, SimGear) and make a complete new download and build. Worked then without problems. Thank you once again, Curt and Vassilii man touch ? Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Please upgrade to version: 0.9.8
Georg Vollnhals wrote: Hi, after compiling the latest CVS and running the new build this message occurs ***Base package check failed ... Found version 0.9.9-pre1 at: /fg-cvs/data*** I know that Curt did some changes regarding the new version in the CVS and there must be a very simple trick a don't know to get it running right, kann you please help me :-) Thank you in advance It sounds like you aren't current with your flightgear source or executable? Could you still be running an older build of flightgear (or not fully up to date with your source code?) Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Jon Stockill wrote: Currently the smallest area it's broken down to is one of the 10x10 degree scenery tiles. The biggest of these files is only 500k (the whole planet fits in a 4MB tarball), so I didn't see a need to break it down any further. If you're interested in just a specific area then drop me an email and I'll see about exporting just the area you're interested in (if you're just interested in seeing what objects are in a particular area you may find that entering partial lat/lon info into a search on: http://fgfsdb.stockill.org/objects.php Jon, I see a distribution issue which I'd like to discuss. The object database lives in it's own separate tree. Right now to use your object database a person needs to add a set of models to their base package. Then they need to install the object tree. However, from my perspective, if I want to roll up a 10x10 chunk of terrain + objects I have a big problem. I need to either roll these two trees together in one big tree (which makes it hard to change or upgrade the objects.) Or I need distribute 2 tgz files (and the end user needs to download and correctly install 2 tgz files) for each 10x10 chunk. Would it make sense to make your object database (for the entire world) part of the official base package and put it all in cvs? If we want to leave these objects as user-add-on-after-the-fact entities, then it's ok how we are doing it now, but they add a *lot* to the flightgear experience so I would really like to make them part of the default some how without imposing an overwhelming burden on the end user to do extra complex downloads and installs by hand. I'm not sure I'm explaining the issues very well, but hopefully someone understands what I mean and can offer suggestions. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Jon Stockill wrote: Curtis L. Olson wrote: Jon Stockill wrote: Currently the smallest area it's broken down to is one of the 10x10 degree scenery tiles. The biggest of these files is only 500k (the whole planet fits in a 4MB tarball), so I didn't see a need to break it down any further. If you're interested in just a specific area then drop me an email and I'll see about exporting just the area you're interested in (if you're just interested in seeing what objects are in a particular area you may find that entering partial lat/lon info into a search on: http://fgfsdb.stockill.org/objects.php Jon, I see a distribution issue which I'd like to discuss. The object database lives in it's own separate tree. Right now to use your object database a person needs to add a set of models to their base package. Then they need to install the object tree. However, from my perspective, if I want to roll up a 10x10 chunk of terrain + objects I have a big problem. I need to either roll these two trees together in one big tree (which makes it hard to change or upgrade the objects.) Or I need distribute 2 tgz files (and the end user needs to download and correctly install 2 tgz files) for each 10x10 chunk. Would it make sense to make your object database (for the entire world) part of the official base package and put it all in cvs? If we want to leave these objects as user-add-on-after-the-fact entities, then it's ok how we are doing it now, but they add a *lot* to the flightgear experience so I would really like to make them part of the default some how without imposing an overwhelming burden on the end user to do extra complex downloads and installs by hand. I'm not sure I'm explaining the issues very well, but hopefully someone understands what I mean and can offer suggestions. It would be easy enough for you to include the latest version of the database when you built the scenery - the Terrain and Objects split works really well to make this relatively easy, and simple for someone to add the latest version of the objects before the next scenery update. If your scenery package were to have the following (example) structure in the tarballs: Objects/w010n50/ Objects/w010n50/w002n53 Objects/w010n50/w002n53/29.stg -- entries just for objects (Static scenery models would be included here) Terrain/w010n50/ Terrain/w010n50/w002n53 Terrain/w010n50/w002n53/29.stg -- entries for airports (Airport and terrain tiles appear here) roll the whole lot up in a tarball for w010n50 and it can be installed as a single package under your scenery directory. If anyone wants to update the models at a later date then they can just replace the Objects/ tree with the latest version. That might be what we have to do, but that implies a change in where scenery files are extracted relative to the scenery tree which would could cause a fair amount of confusion ... not that the current process is completely unconfusing ... Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Jon Stockill wrote: Yes, it'd need to install the contents of the tarballs to ...Scenery/ rather than ...Scenery/Terrain I guess I'm just being picky ... it would also have to look in two places when removing scenery ... nothing insurmountable, just kind of messy in places. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Feature/change/update/fix list since v0.9.8
Melchior FRANZ wrote: * Curtis L. Olson -- Sunday 06 November 2005 02:46: For upcoming v0.9.9 ... What I think should be added: - enhanced weather modeling (lightning, rain) - OpenAL: positional sound Doppler effect - help dialogs (global keys, aircraft specific keys, procedures, and performance data) - GUI theming (fgfs comes with optional dark theme) I'm aware that GUI changes are already listed, such as the changeability of colors, but this doesn't seem to affect the users directly. Theming via XML file *does* affect users. And eye-candy is always what the masses are after. Also, OpenAL is mentioned, but that's only interesting for the non-developer if (s)he knows what this brings us: Doppler, positional sound, Surround sound(?). Ok, thanks, Ill add all that (although this isn't the first release with openal.) Some new screenshots that show new visual features should be on the homepage before the release is announced. (Just tell, and we'll send you loads. :-) We'll definitely want to post new screen shots, but I'm not quite ready to get flooded with that right now, and I'll reserve the right to run them through the curt-acceptance-filter. :-) Thanks, Curt. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Feature/change/update/fix list since v0.9.8
I was scanning through the cvs logs trying to refresh my memory on what has been changed, added, and fixed since the release of v0.9.8 (last January). Here's what I came up with, although after staring at cvs logs for 2 hours I started having minor hallucinations. So I'm posting this here in hopes that people can add to it, or correct my mistakes. If you contributed something that is missing, or poorly described here, please send me something better. Thanks! Curt. For upcoming v0.9.9 ... * New well integrated volumetric clouds by Harald Johnsen * Removed 'old' 3D clouds code. * Fixed the jitter problem with 3d cockpits. * Volumetric shadows are now supported so that aircraft can cast shadows upon themselves as well as the ground. * Better support for redoing livery textures on an individual aircraft. * Support for seasonal terrain textures. (Updates to summer textures plus new winter textures added.) * Add status updates to the initial splash/startup screen. * Allow switching the tower view location at any time. * Add support for configuring views with asymmetric view frustums. * Many updates to gui/dialog box infrastructure. Ability to alter border thickness, change fonts, dialog boxes are draggable across the screen, you can enable automatic line wrapping, select colors, allow key presses to be bound to widgets, . * Updates and enhancements to many of the dialog boxes to fix problems, expose new features, enhance usability, etc. * Updated JSBSim version since the last release. (More updates pending after this release.) * YASim: expose spool-time of a jet engine as a config parameter, add an oil temp model, support gear compression along any arbitrary axis, reworked MP calculations for super/turbochargers. * Allow setting individual sample/update rates for any of the PID autopilot stages. * Support TACAN instruments. And an IVSI instrument. * Depricated old (somewhat less the spectacularly conceived) electrical system model in favor of a much more flexible script based system that can be tailored to any individual aircraft. * Include an external utility that can feed saved nmea tracks back into FlightGear. If you take a gps on a real flight with you and capture the output, you can replay your flight in FlightGear. * Many updates and fixes to the joystick configuration files, many new joysticks directly supported. * Removed all lingering dependencies on plib's SL sound library. * Add support for OpenAL 1.1 and alut. * Better cross platform compatibility with our standard network structures. * More cpu friendly frame rate throttling code that can leave more cpu available for other apps. * Various Nasal (scripting) bug fixes and language improvements. * Various bug fixes, various platform/compiler compatibility fixes, several memory leaks fixed. * New aircraft available (in various stages of developement): A380, Boeing 314 (seaplane), Citation Bravo (glass cockpit), F-8E Crusader, Hurricane IIb, MiG-15bis, TU-114, B29, C150, and SR20. * Aircraft that have had updates since the last release: 737, A-10, AN-225, B-52F, BAC-TSR2, Citation-II (550), Comper Swift, Concorde, Hunter, OV10, Spitfire, T37, B1900d, bo105, C172 et. al., DHC2F (Beaver), F16, Fokker DR1 Triplane, Fokker 50 (turboprop), Fokker 100 (jet), J3 Cub, P51, Santa, Seahawk, and 1903 Wright Flyer. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings?????
Melchior FRANZ wrote: * Buchanan, Stuart -- Friday 04 November 2005 13:36: Presumably the current tile is also somewhere within the properties tree, so one could look there as well. No. I don't recall the context of this thread, so the 'no' might be in response to something else, but I believe the current tile id is in fact in the property tree someplace. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Ima Sudonim wrote: Oh, DC scenery, one of the many things i'd like to do if I ever get around to it (health permitting) 8-) I even got a gps to plot buildings' locations... just was never able to do anything. For what ever it's worth, Google maps seems to do a surprisingly good job of giving up lat/lon coordinates of objects. You have to be a little careful of the way urls get cached and delayed in a web environment, but if you get a link to the current image, you can easily read the lat/lon coordinates out of the link. Just click on the object to make sure it is centered. With a hand held gps, you aren't going to ever get to stand at the center of the roof (well maybe rarely) so google has a lot of advantages and might even be more accurate than doing the surveying yourself manually. (The wording of that last phrase didn't come out very well on my first attempt, but I think the final edit is slightly less ambiguous.) :-) Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Citation Bravo
Syd recently sent me a Citation Bravo jet (similar to the Citation II we already have but which a much more modern cockpit.) I have just committed it to CVS. It's worth checking out (so to speak.) :-) Syd does really great work on the 3d cockpits. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Citation Bravo
Shelton D'Cruz wrote: Hi Curt The work that Syd has done on the cockpits is *truely magnificant* - you can easily see the love of his work in it. I am extremely grateful and appreciative. Just to add to this, I just did a quick dusk flight from SFO to SJC in the new Bravo. I think it might have a problem with not enough drag because it doesn't like to slow down, but other than that it's a real joy to fly. With the terrain, the lights on the ground, the sliver of a moon tonight, some puffy clouds, the lingering dusk light in the sky ... and the Bravo looks, sounds, and feels very realistic. It's kind of funny, because FlightGear time and date is tied to your computer clock, in the summer with the long days I almost never fly at night. Now that we have switched to day light savings time here and the days have grown short, I almost never fly during the day. I had forgotten about some of the nice lighting effects we do. Fred's rotating beacon is really cool, the dusk sky coloring, runway and approach lights, stars, moon with the correct phase, all very nice. Oh here's a sort of funny story. I'm helping my university with a small UAV projects. One thing we are doing is feeding the UAV location and attitude directly to FG in real time to produce a real time synthetic view from the perspective of the UAV (or any other perspective we want.) Because it is flightgear we can overlay instruments on top of the synthetic view. We were out flying last week and when we were getting things setup, the professor in charge commented that the directional gyro wasn't working on our mini-panel. I thought about it for a second and had to point out that the aircraft was on the ground with the engine off ... no engine means no rpm. No rpm means no vacuum system. No vacuum means no gyro. No gyro means no DG! He was rolling his eyes and commenting that it would be nice if the DG just worked all the time. :-) But what fun would that be? Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Mac OS system requirements
Can someone post the system requirements for running FlightGear? Mac OS 10.? Minimum 3d hardware? Minimum ram? Thanks, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CPU usage issue
Lee Elliott wrote: Hmm... the puzzling thing is that you don't seem to be getting 100% utilisation when running FG. As Andy R explained, you should expect to see 100% utilisation. If you had been running on a multi-processor/core system then it might have made more snese. If you have vsync enabled or some other throttling mechanism turned on, you may very likely see 100% cpu utilization. Otherwise, the remaining time might be getting assigned to the system depending on out the drivers are laid out. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FlightGear as a real time synthetic view
There is a neat flightgear connection here which I've probably mentioned before, but would like to mention again (with pictures.) http://www.flightgear.org/~curt/Models/Special/Rascal110_2/ This is a manually flown UAV (also pictured on the same page.) It has an onboard camera angled 45 degrees down. It also has a gps/imu sending data to the ground via a radio modem, so we can feed that into flightgear and show a live synthetic view from the aircraft perspective. We can angle the flightgear view 45 degrees down and it matches pretty darn close with the real camera view. We had a guy create a small chunk of photo real scenery for the area so it's really neat to see the synthetic and video views match tree for tree, road for road, building for building. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear as a real time synthetic view
Dave Martin wrote: That is extremely nifty. Yes, I'm not sure what if anything it's good for, but it's definitely nifty. :-) I'm suprised you can get that sort of 'resolution' in the GPS/IMU downlink. The orientation probably comes out to within a degree or two, the GPS has a moderately low resolution (i.e. you can really see it step near the ground) but up in the air at flying speeds it does quite well and a few feet of positional error doesn't show up nearly as much. Glad you got back in the air so soon too :) Yes, that is what backup airplanes are for. :-) Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear as a real time synthetic view
Kitts wrote: This looks brilliant! The synthetic view kinda looked brighter than the real thing in the picture ;-) Are you flying the craft through the computer's joystick or using a standard R/C? or even better, an autopilot system? Just curious! :-) We are currently flying 100% manually with a standard R/C transmitter. We have a $2000 autopilot purchased for this project, but it's a lot of do-it-yourself work and we just got it, so we don't have it flying yet. I cant wait to get my model up in the air! (Have I mentioned here that i am working on a similar thing as my hobby?) This stuff can be a lot of fun, and does a great job at keeping you poor. :-) I have my own hobby uav project that isn't very far along. I haven't tinkered with it too much now that I am more involved in this project through my university. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Santa's r[ae]i?ndeer
Dave Martin wrote: On Thursday 27 October 2005 14:19, Vivian Meazza wrote: What happened to the poor reindeers' antlers? V. I take it you're not aware of Reindeer Service Bulletin 63-11-05 SE 15? The antlers were removed to improve 'engine out' characteristics after the infamous 'Rudolph food-poisoning' incident. Speaking of engine out, I assume everyone has seen this one: http://www.funnyhumor.com/jokes/1158.php Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] jpeg-factory in simgear and flightgear
Oliver Schroeder wrote: Hi list. I just stumbled over the jpeg-factory again. Simgear defaults to build with jpeg factory enabled, while flightgear defaults to build without it. So one either has to supply --without-jpeg-factory to simgears configure or --with-jpeg-factory to flightgears. This should be harmonised. I experienced it under Linux and didn't look into it. Maybe the defaults are correctly set under other environments. I believe the defaults are correctly set to both build without, but once you build and install simgear with it, the header file is installed so flightgear autodetects it. If you later build simgear without, that header file will still be installed and flightgear gets confused. You just need to remove the installed simgear header file for jpeg factory and you should be good from that point on. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Depth buffer issues with instruments and reindeer
Harald JOHNSEN wrote:
Jim Wilson wrote:
http://www.spiderbark.com/fgfs/citation_instruments.png
It turns out these are in fact contained in a single 3D model for the
entire aircraft, so it has nothing to do with 2D. Apparently the
problem is in the models. ...
FWIW I'd like to suggest that it is a good idea for 3D modelers to
test their work at 16 bit depth buffer settings since a lot of folks
are still running modern laptop, consumer grade and Intel embedded
chips at 16 bit for performance reasons. Even though it involves
moving layers further appart, adjusting 3D instrument models to
support 16 bit generally does no harm to the appearance of the model
at the normal viewing distance.
I disagree on changing the models or instruments. Looking at the code
the problem is obvious.
We ask for a depth buffer precision that is impossible to achieve.
From FG/Model/acmodel.cxx :
FGAircraftModel::FGAircraftModel ()
: _aircraft(0),
_selector(new ssgSelector),
_scene(new ssgRoot),
_nearplane(0.01f),
_farplane(1000.0f)
{
}
Jim, if you can compile FG, can you try with a near plane of 0.03
and/or a far plane of 250.0 ?
For what it's worth, changing the far plane has little affect on the
depth buffer precision. The near buffer value is what dominates the
amount of depth buffer precision.
Curt.
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
Dave Martin wrote: Just wondering if anyone (pos historically) has driven physical instruments using FlightGear on Linux. I'm thinking the analog variety (ASI AI ALT etc) from the likes of SimKits. Obviously the SimKits stuff couldn't work directly because their proprietary software to drive the CCU is for Windows and MSFS only. So are there, or have there been any examples of someone succesfully driving analog instruments using FlightGear on Linux? For the FAA Level 3 FTD certified sims I work with, we draw the instruments on an LCD screen, then place a panel cutout with bezels on top of that. Fools a *lot* of people into thinking they are real, even though they aren't. The simkits stuff are driven by standard servos, right? So you could get a little PIC board to run your servos and take position commands in from the serial port ... then you just need to send the data out the serial port from FG (with perhaps a small amount of interface coding.) It might be a little time consuming to get all the pieces in place and working, but once you figure out how to generate the PWM servo signal, there's nothing technically difficult there. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
Dave Martin wrote: Just another quick thought on this idea. (I'd like to try it) If I've got my facts right, a standard gauge is about 3 1/8inch (approx 80mm) diameter mount. So does that suggest a 19inch or 20inch LCD screen for the c172-610x panel? I don't recall the exact dimensions but I'm sure it's somewhere in that neighborhood. I've also had a couple of bright ideas for providing gauge adjustment controls infront of the LCD, do you have a trick to do this or do you set them separately (via a normal key/mouse interface)? There are adjustments in the proper place on the panel. I'm just a software guy, so I don't know all the hardware tricks that are being done. But I do know the end result has a nice solid feel and is very convincing. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
Buchanan, Stuart wrote: How are you driving the panel? From the same box as the cockpit view (multiple FG instances?)or by using multiple machines? I'm quite interested in the possibilities of multi-display setups, but it feels a bit excessive to have a box just dedicated to displaying a panel. We are using multiple machines, one for each display. My feeling is that if it is a bit excessive, it is only a small bit excessive and I can put up with it. :-) You are welcome to try running a multiheaded machine (with support for opengl on all your displays.) I'd be interested in hearing your results. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
Dave Martin wrote: Well, I think I could get the adjusters in place (experimentation time) My next question would have to be (bear with me) Does FreeGLUT support multiple mice yet? Alternatively, does FreeGLUT rely on X11 for it's mouse definitions. I think I may have found a method in X.org which will allow multiple USB mice to behave as a single 'logical' mouse - albeit with loads of scroll-wheels etc. ;) The idea being that a mouse is possibly the cheapest off-the-shelf 'encoder' on the market (not strictly an encoder but good for the purpose). Not sure about x.org's limitations but the USB interface will support 127 devices per channel; more than enough for a light-aircraft cockpit interface. John Wojnarowski is developing some interesting switch, button, light interfacing hardware that plugs into your computer via usb. I don't know if it has any A2D or D2A capabilities. It sounds really promising though. Hopefully he will jump in here with details as his time permits. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Speed problems under Solaris
Andy Ross wrote: Martin Spott wrote: I suspect the network stuff is coupled to the same loop as is the screen display. Just a guess, though It is. Everything except for terrain tile I/O is driven out of the main loop. Probably something that should be fixed... Note that we're going to have to start thinking about threading designs soon anyway, if we want to take advantage of all the fancy multi-core/multi-thread CPUs coming down the pipe. Rendering obviously has to stay within a single thread, but how much non-rendering work can we push out to worker threads? Ideally, everything would be handed to the renderer thread each frame, with all the matrices pre-cooked and ready for OpenGL calls. I would like to make a case for non-threading from the standpoint of simplicity. We have had (and probably still have) some extremely subtle and extremely difficult to track bugs in our threaded tile loader. We've been forced to use threading for our tile loader simply because of performance reasons. We can't afford a big stutter in our animation when ever we need to load new tiles. When a single person is writing a smaller threaded app, things can work out quite well because one person (who understands all the underlying issues) can think through the code very carefully and ensure that all possible timing, locking, and communication related events are handled robustly. But now project that onto a project like FlightGear. Even if one highly skilled person set us up with lots of threading that worked perfectly, given all the contributions from a variety of sources (many of which I know have no clue about threading issues) how long do you think it will be before everything is hopelessly fouled up? Some simple naive change to fix some bug or add a new feature could inadvertantly introduce a subtle threading bug that only happens very rarely, but is still unacceptable. Personally, I think that the idea of threading in the context of FlightGear is a *very* scary idea, especially from the standpoint of long term maintanence and keeping our code robust. I'd perhaps favor splitting our code out into separate applications that use networking or shared memory or pipes to communicate. You lose some of the context switching efficiency of threads, but I think the code becomes more robust and maintanable because changes have less of a chance to propagate elsewhere to unintended areas ... Just my 2 cents ... :-) Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Speed problems under Solaris
Martin Rosenau wrote: Hello. I found out that for each simulation step an usleep(93 ms) is done. The screen is updated only every 64 simulation steps. 93 ms X 64 = ~7 seconds I have no idea why the display is only updated ONLY every 64th simulation step. Textures are not the problem; I can use --disable-textures to get single-color triangles if textures are the problem. But I think that textures are no problem because - as far as I know - the texture stuff is done in the X server process which needs only few processor time. This *sounds* like you do not have opengl hardware acceleration on your machine. Even with textures off, FlightGear still uses opengl funtionality for it's depth buffer (hidden surface removal), fog, lighting, and transforming vertices from world coordinates to screen coordinates. All of this is really slow in software on a general purpose cpu which is why dedicated 3d hardware exists. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A question regarding accurate taxiways
Erik Hofman wrote: Norman Vine wrote: Erik Hofman writes: This can be done by requesting a new designator number as an alternative taxiway entry. That way it would be possible to have both the old and new format available in the file. Doesn't that just create another problem ? Now the tools will need to check for duplicates a notoriously tricky thing todo with GeoSpatial data. As I see it all the taxiways will be available in the new format when the new designator number is found. So it's not that hard after all. An alternative would be to create a conversion utility that converts all taxiways from the old to the new format. But that requires X-Plane to immediately support the new format. I haven't had a lot of time over the past weeks to contribute here and I'm going out of town later this week, but we've discussed much of this before. In the mean time Dave Luff is taking FlightGear airport updates and maintaining them as local mods to the Robin's x-plane format and giving me the result. We submit FG entries to robin so hopefully all our local mods eventually wind up in the upstream version. Robin has granted us some code number space in the x-plane format so we can add our own entries (and maintain them separately) as we go ... whether that be polygonal airport outlines, polygon taxiways, or other objects. This isn't a perfect solution, but there are huge advantages to staying with the x-plane format as much as possible because they have a large user base of people contributing updated airports. It makes sense to stick with their format as much as possible because we tried an alternate format at the beginning of this project and it just because too difficult to manage, so we never got any updates. Robin is a dedicated data manager and is committed over the long haul. Any proposal we might make to deviate from that would involve a volunteer who can dedicate serious time over the long haul to maintain our version. Historically, those type of volunteers are very difficult to find ... we have a few, but they aren't jumping at taking on new tasks, and when you try to pawn off new tasks on people they usually don't get picked up ... even something as simple as a FAQ maintainer anyone??? Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A question regarding accurate taxiways
Harald JOHNSEN wrote: The best way I found to counter the z-buffer fighting is simply to disable z-buffer testing. Remember, we are painting the ground, why would we want any z tests (you can find situation where this add artifacts of course). Exactly, if you disable the z-buffer, you lose hidden surface removal. You can play tricks with drawing order, but this gets really complicated, really quickly, and you end up with things like runway lights from other airports showing through terrain and wierd stuff like that ... Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Oliver Schroeder wrote: Am Thursday 13 October 2005 15:29 schrieb Erik Hofman: Vassilii Khachaturov wrote: People like me with a lousy single-dsp on-board sound chips would be able to pause the simulation sound while debugging some flight things, and releasing the sound for other uses. So, you're really more interested in getting real sound disabling code rather than sound muting as it is now. Which reminds me of another thing. Is it possible to use /dev/dsp in a non-blocking mode? I want to start a second application which uses /dev/dsp while flightgear is running. I was investigating several applications which can serve as a radio for multiplayermode and noticed that it is not possible. My general opinion is I'm not sure I would like to see us overly complicate the flightgear code to work around older hardware limitations. I know it's a minor inconvenience if you are on a long flightgear flight and would like to fire up your mp3 player in the background (and find that you can't) but this is going to be a problem for any application that uses sound and I don't really like the idea of overly complicating the flightgear audio code just for this. This isn't a problem on most newer audio hardware which happily knows how to share/mix between multiple audio applications. Personally I think that this problem is outside of the scope of FlightGear and we shouldn't worry about it. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Martin Spott wrote: I herewith repeat my offer to run a server that replicates audio channels using Voice-over-IP protocols using Asterisk with a conference setup. This would allow for one conference channel per 'frequency' in use. On the other end this would require someone to wire a useful VoIP client library into FlightGear - like IAXClient, which is my favourite: http://iaxclient.sourceforge.net/ This could be setup as a completely separate application. If FlightGear was running with the telnet interface enabled, the remote audio communication application could easily fetch the currently tuned com frequencies from FlightGear. A separate application would keep the core of Flightgear simpler and wouldn't add additional prerequisites to building/installing FG. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Martin Spott wrote: Oh, no - please ! :-)) It's not just about comm _frequencies_, it's not only about automated ATC messages. I'm talking about the ability to transport sim pilot's blather over the net. I heavily object against running this as a separate application after I've seen M$FS pilots running into heavy trouble while connecting multiple add-on applications to their sim. Over the time we'll run into version imcompatibilities and sort of that stuff. This is why I'd prefer to have such an interface built into FlightGear. IAXClient focuses on portability and I've already managed to build it on AIX, IRIX, Solaris8, FreeBSD and Linux - with neglectible programming skills ;-) The counter argument though is: 1. I'm adverse to adding another somewhat large dependency to FlightGear. 2. FlightGear and MSFS have entirely different interfacing mechanisms. People may have trouble with FlightGear, but I don't think that you can say that trouble with MSFS's external interface mechanism implies similar trouble with FlightGear's ... different trouble, maybe, but not similar trouble. 3. Using the property system minimizes version incompatibility problems since property names don't change all that often. Perhaps I could propose that we start by developing this as a separate application and then if it works really well and there is a strong consensus, we could merge it in with the FlightGear code directly. It's very small and think it is worth being incorporated into FlightGear: quickstep: 18:00:28 ~/CVS/Asterisk/iaxclient du -ks * 28 COPYING.LIB 16 CVS 12 README 3180lib 1548simpleclient Only 4.5 Mb ... in terms of source code, I don't think I would could call that small. I don't know what this would come out as when it's compressed, but it could easily double the size of the FlightGear source tarball. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
John Wojnaroski wrote: Having a voice capability for flightgear is a good idea, however irrespective of the actual mechanisms to implement the technology, we should consider the intent and purpose To set up an ATC system requires a lot of work and a cadre of dedicated individuals. In the absence of such a system or standards to adhere to proper ATC phraseology and protocols, it will degenerate into a chat room. If people want to blather it might be best to use some other method or separate medium. I don't think FG needs to be in the business of building another VoIP phone system. Here's my take on that. I would think that people would voluntarily setup ATC voip servers on their own hardware. At the moment I don't think there would be resources to setup a dedicated FG ATC voip server, but if we get a system that works well and it made sense to centralize it, we could discuss that. So in terms of people setting up servers, I would suspect that some servers would be managed more professionally than others. If a particluar server degenerates into a voip 'chat' room and the server maintainer doesn't care, then so be it. But I would assume that at least a few voip servers would be held to pretty rigorous standards and people abusing the airwaves or not taking the 'game' seriously could be booted off and sent to a less serious server. I think this could be controlled pretty well with social/cultural pressure, especially if there was some ultimate enforcement mechanism (which might be as simple as adding an entry to a /etc/hosts.deny file on the server if someone persists in breaking the rules ...) or perhaps we need a virtual airforce with guns and missles to keep the airwaves pristine ... :-) Back to serioiusness, I think since most FlightGear participants are not active licensed pilots, there would be some need for flexibility and education on the proper procedures ... just like in real life, but obviously without real lives directly at stake so we can afford to allow more mistakes and more active learning. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Martin Spott wrote: Ampere K. Hardraade wrote: Is it a priority to have a voice comm at the moment? A voice comm would serve no purpose if there is no one being the ATC. The other way 'round nobody would think of playing ATC for FlightGear users as long as the software simply lacks the required features. I know, this could lead into an endless discussion but I think you at least have to admit that there's more than a single valid view on the topic. There's no harm in someone working on this, especially if it's done as an external app initially. We all have our individual priorities ... Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] nasal electrical system
syd wrote: Hi Steve ...I found the file in Aircraft/c172/c172-electrical.nas It works the way I wanted 0 volts at the outputs when the switch is off. This should also model battery discharge and charge ... I'm not sure if we have a battery voltage or ammeter gauge in the default c172, but those should be live if they exist (or once they get created.) The underlying structure is there for the master switch, battery switch, avionics master, etc. It just needs someone to create the corresponding panel objects. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 30, Issue 27
Steve Knoblock wrote: Subject: [Flightgear-devel] nasal electrical system To: flightgear-devel@flightgear.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Hi Steve ...I found the file in Aircraft/c172/c172-electrical.nas It works the way I wanted 0 volts at the outputs when the switch is off. Hmm...I have downloaded the Windows binary release for 0.9.8, which I am running. I do not see the nas file there. I downloaded the source code and source code base for 0.9.8 and do not see it. I have downloaded the bleeding edge CVS but do not see it. I have downloaded all the C172s from the GF download page but do not see it. Okay, I found it, I had not looked on the CVS page from the FG website. It is in the CVS browser at [FlightGear-0.9] / data / Aircraft / c172 quite a hunt. It is new since the last release which is why you only found it in cvs ... sorry for any confusion. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: (electrical) Flightgear-devel Digest, Vol 30, Issue 24
Steve Knoblock wrote: Can you point this dummy to where the nasal electical system or documents are? Sorry I have to make this quick, but the nasal electrical system is simply a nasal script that impliments the electrical system. There should be an example in the c172 folder ... look for something like c172-electrical.nas (or something similar.) The aircraft-set.xml file can reference aircraft specific nasal scripts so that's what you need to do to activate the electrical system. The nasal script is specific code to impliment a specific aircraft's electrical system, but the overall structure could be copied and adapted to new aircraft. But each aircraft will need it's own aircraft specific script. Other than that, the script just runs every frame and reads and sets property values appropriately. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: (electrical) Flightgear-devel Digest, Vol 30, Issue 19
Syd and Steve,
Check out the newer nasal based electrical system for the C172. I just
had too much trouble getting the old xml based system to really work the
way I was hoping it might. The nasal based approach seemed to work out
so much better for me. The logic ends up being pretty much the same,
but I found it to be a lot easier to model some of the more subtle
electrical system behavior with nasal ... probably because it's easier
to cheat and fudge things when needed. :-)
But there's no reason you can't make every switch and circuit breaker
and light work just like the real aircraft ...
Curt.
Steve Knoblock wrote:
I noticed recently that electrical outputs still show a voltage (frozen)
when a switch is shut off.Is there a reason for this ... or is it a work
in progress?
The reason I ask is that I want to animate lights by the voltage rather
than switch position ... (dimming lights as the battery voltage drops ,
etc...).I just want to know if this is the way it is going to operate ,
and I can change my animations (I'm currently working on the
overhead light switch panel in the B1900D).Thanks in advance, I know how
busy everyone is .Cheers
I am still learning the electrical system model. I like to see all the
electrical devices and switches work as in real life. If the master
avionics switch is off or the battery is dead, the autopilot should
not be displaying anything or operating.
For the autopilot, I set a power-good property (like mainboards have)
and use NASAL to check for sufficient output on the autopilot bus. For
example:
ap_pwr = getprop(/systems/electrical/outputs/autopilot[0]);
if( ap_pwr = 0.3) {
print(Digitrak: Power Good);
setprop(Internal, power-good, on);
} else {
print(Digitrak (Warning): Insufficient power.);
setprop(Internal, power-good, off);
}
This seems to work well. The Digitrak requires 0.3 amp.
On the other hand, I am still confused about some aspects of the
electrical system.
/systems/electrical/volts
/systems/electrical/amps
both seem to be read only properties. I suppose this makes sense, if
these are just monitoring the flow (but at what point?) and the system
is modeled as suppliers and outputs of electricity. Any adjustments
would be made at the supply side.
I can change
/systems/electrical/serviceable
but it appears to do nothing.
However,
/systems/electrical/suppliers/alternator
/systems/electrical/suppliers/battery
/systems/electrical/suppliers/external
are also read only. It appears all the outputs are ready only
/systems/electrical/outputs/*
I am left looking for where the actual source of electrical power is
specified. Looking at the electrical.xml the properties are defined
here.
I can change the initial value of the battery in amps from here (shows
up /systems/electrical/suppliers/battery), but lowering it to 5 amps
did not seem to affect the a/c.
Okay, if I set both battery and alternator to 0.1 amps in the config,
my autopilot fails power good. It appears the turn coordinator also
fails. Flaps still work (this is the Cessna). Radios work. ADF works.
Clock works. Fuel, Temp, Flow gauges all work, the AMPs show zero.
This suggests many instruments do not check the electrical properties.
The a/c engine turns over and works fine without a battery or
alternator (magneto?).
I am unsure how the output properties are affected by switches or if
they can be.
Steve
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AGL and HUD
rhett3 wrote: I have had this problem with an older version of FG, around 8.0, when using a separate computer for the scenery. For reasons unexplained the altitude was set initially in /Network/native_fdm.cxx as an addon to the runway height, then the AGL changed, and with it the altitude. I fixed it for our purposes by locking the AGL to the takeoff runway altitude, but the current version does it the other way, getting AGL from the altitude and subtracting the current ground elevation to get the AGL. I don't know if this helps in your case. This looks suspicious: CVS log for source/src/Cockpit/cockpit.cxx Mathias Fröhlich has his name attached to the change from rev 1.13 to rev 1.14. This changes the AGL strip to read hight above some runway, not current terrain. This isn't intended to be a real instrument I guess, but perhaps work similar to a radio altimeter which does show you the height above current terrain. The CVS logs don't mention any intent to change this behavior, and I don't recall any discussion, so I'd like to change the default behavior back to reporting height above the current location. Hmmm, it seems like the original get_cur_elev() has been removed from the api. Did someone just bandaid in a quick call to runway altitude (which is probably not updated as you fly from place to place?) Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Weekly Snapshot (was RFC: FlightGear 0.9.9)
Ampere K. Hardraade wrote: I have been wondering this for quite a while: will it be a good idea to provide weekly CVS snapshots? Do you mean replace the instant cvs snapshots with snapshots only taken at weekly intervals? :-) http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/source/source.tar.gz?tarball=1cvsroot=FlightGear-0.9 http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/data/data.tar.gz?tarball=1cvsroot=FlightGear-0.9 Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Weekly Snapshot (was RFC: FlightGear 0.9.9)
Ampere K. Hardraade wrote: On October 5, 2005 07:58 am, Curtis L. Olson wrote: Do you mean replace the instant cvs snapshots with snapshots only taken at weekly intervals? :-) By cvs snapshots, I mean binary-snapshots packed into .deb, .rpm, etc. If someone wants to do this, and promises to keep up on it, I can put a link on the FG web site ... Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
For what it's worth, I don't like this patch. It shouldn't make much
difference on 24/32 bit cards, which is probably most everyone now
anyway, but I think there is a different problem brewing somewhere.
I haven't had time to look into it, but the AGL reading on the HUD no
longer reads correctly. Somewhere along the lines we have introduced
some sort of height above ground bugs. I don't know if that is in the
ground cache code or elsewhere, but the HUD above ground display isn't
working right anymore.
If we get that problem fixed so the system knows the correct AGL, then
we wouldn't need to make this particular huge hack 5 times worse.
Somehow the gear still knows where the ground is, but I recall specific
patches to the individual FDM's. I've lost track of what is going on
with this section of code, but it's important and it really should get
fixed before we get too much further!
I'm going out of town on thursday and rushing to get a bunch of other
stuff done in the mean time, so I really can't look at this in the near
term, but someone really needs to volunteer to step up and track down
what is going on here.
Regards,
Curt.
Melchior Franz wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main
In directory baron:/tmp/cvs-serv754
Modified Files:
renderer.cxx
Log Message:
prevent view through big hole in carrier deck
Index: renderer.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/renderer.cxx,v
retrieving revision 1.27
retrieving revision 1.28
diff -C2 -r1.27 -r1.28
*** renderer.cxx1 Oct 2005 09:56:53 - 1.27
--- renderer.cxx4 Oct 2005 18:01:45 - 1.28
***
*** 499,503
- cur_fdm_state-get_Runway_altitude_m();
! if ( agl 10.0 ) {
scene_nearplane = 10.0f;
scene_farplane = 12.0f;
--- 499,503
- cur_fdm_state-get_Runway_altitude_m();
! if ( agl 50.0 ) {
scene_nearplane = 10.0f;
scene_farplane = 12.0f;
___
Flightgear-cvslogs mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-cvslogs
2f585eeea02e2c79d7b1d8c4963bae2d
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
Melchior FRANZ wrote: * Curtis L. Olson -- Tuesday 04 October 2005 20:52: For what it's worth, I don't like this patch. I find the hole more annoying. Unfortunately, I can't fix what you think is the real problem. Shall I revert for now? I'm not saying the hole isn't annoying, I'm just saying that there is a bug because for some reason, the sim thinks you are 10 meters AGL when you are sitting on the carrier deck. There is some ground intersection problem going on there. If the ground interesection was computed correctly, the system would think you are 10 meters AGL and everything would work the way it is intended. I'd really like for this to get fixed the right way. When we slap on bandaids without fixing the underlying problems, we end up with a system that has a lot of bandaids on top of a rotting infrastructure. Similarly whenever we see a stray crash or segfault we should pursue it with our utmost agression and stamp those out right away. Anytime we leave these sorts of crashes and problems for later, we end up with a system full of unexpected, unexplained, impossible to debug crashes. That kind of software is an incredible pain to operate. In the past I had more time to defend against these things, right now I don't. You've been granted CVS commit access so use your best judgement. I'd just hate to have this slip through the cracks, and when someone tries to land on an object that is 50.01 meters tall or more, they are going to get a hole again. We could just remove that check and leave the near clip plane in close all the time, but then our terrain rendering will really stink for anyone with a 16bit depth buffer ... It's not an easy problem, but slapping a bandaid ontop will probably mask it long enough so that the person who introduced the orignal problem will be long gone before we get bit again and no one will know how to fix it ... Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
Melchior FRANZ wrote: * Curtis L. Olson -- Tuesday 04 October 2005 22:02: You've been granted CVS commit access so use your best judgement. Yes. I don't usually touch such things, because I don't understand much of this. I did it anyway, because: - this change was already in cvs since a great while, and only had been reverted recently - the commit log of the reverting patch didn't explain why this was reverted; it was part of a completely different change and looked like an accident - I mentioned it in this message and got no reactions: http://mail.flightgear.org/pipermail/flightgear-devel/2005-October/039285.html not that this is necessarily an agreement, but together with the other two reasons I though it would be OK, and better than the whole, which I consider a show-stopper. I'd just hate to have this slip through the cracks, and when someone tries to land on an object that is 50.01 meters tall or more, they are going to get a hole again. We could just remove that check and leave the near clip plane in close all the time, but then our terrain rendering will really stink for anyone with a 16bit depth buffer ... Andy (via IRC) has also looked at the code and suggested that the whole 'if' case is probably not needed any more. I just tested it, and indeed, with only scene_nearplane = groundlevel_nearplane-getDoubleValue(); scene_farplane = 12.0f; the hole doesn't occur any more. I'll be doing some more tests. But I won't touch that code again without explicit OK from an expert. :-) Just know that with the near plane set close in, there isn't enough depth buffer resolution on 16 bit cards to properly draw the terrain. If you look at mountains in the distance, you get lots of odd z-buffer fighting. This is on 16 bit cards. If we don't care about 16 bit cards any more (that used to be our only option in the old voodoo-1/2/3 days) then we could remove that whole if statement. For what it's worth, my laptop can only run FlightGear acceptably in 16 bit mode so I'm slightly worried about the ramifications of this change. Ultimately we *really* need to fix the above ground level calculations. Somewhere since the last release, that got broke and it must get fixed. If that was fixed you wouldn't be seeing a hole in the carrier deck. (And the AGL computations in the rest of the sim would start working correctly again.) Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Crash carnage
Eric Sorton wrote: Hi Curt, FMA Direct FS8 Receiver has serial output which can be used with their Windows software to view the current position of the control outputs. If they provide the protocol (or if it can be reverse engineered), you could simply read the output of the receiver on-board the aircraft and control the actual stick inputs. I'm hoping to acquire one soon for testing. In addition, the receiver also records the amount of interference that is encountered. Could be useful as you try to determine the amount of interference produced by the other antennas on the aircraft. Hi Eric, That's an interesting lead, I'll have to look into that. I'm better at decoding serial port data than programming PIC chips. :-) I have a similar setup at work and we have had interference problems as well as a crash or two :-) Two questions on your crash ... 1) Did you do the stall test on the Rascal with or without the equipment? We haven't flown it hard with equipment on board, but we have flown quite a bit. We are planning some test flights tomorrow so if we have some extra time I might try to mimic the crash flight (at altitude) and see if I can reproduce what happen. That may or may not tell us something. 2) Did you possibly point the R/C transmitter antenna at the aircraft? Well, to complicate matters, we were trying a buddy box system for the first time. I was on the student side and the safety pilot was on the instructor side. We were setup this way because we were planning to have me try to fly off video for the first time. Our safety pilot is pretty sharp and said he was conciously trying to maintain optimal antenna alignment the whole time. We have observed that our range is reduced when our other stuff is powered on, but we still range check within Futaba tolerences (50') and we have flown a dozen flights or so with the equipment so we figured we were good. I was wondering though if perhaps we managed to get into some sort of bad alignment for our receiver antenna, combined with being close to the ground, and hit a little dead zone? We were frustrated to find out our GPS didn't have a lock at the start of the flight so we didn't get any position or velocity data. We did get orientation data and that seemed to match my recollections and support that the aircraft was doing what I intended it to do ... at least up until the data stopped which was a second or two before the airplane stopped. In that last second or two I tried to roll out of my turn and bring the nose up (I had let it drop on it's own and stayed off the elevator.) But no dice, I felt like it had zero response to my inputs and continued a steep dive right into the ground. It's hard for me to believe that that particular plane at that speed could be in any kind of a stall, but I'll have to play around and see if I can make it do something similar. I guess we were expecting this though which is why we had a backup plane ready to go, and which is why I should be working on getting Rascal #3 assembled here in the upcoming weeks. :-) Pointing the antenna at the aircraft is easy to do when things are going bad and the aircraft is low to the ground. The thing that surprised me was that my recollection of the flight was that the airplane came around in it's turn pretty liesurely and just failed to respond when I tried to roll out and bring the nose up, but when looking at the orientation data, it all happened very quickly. Oh well, I think we can rebuild Rascal #1, and I keep having to pinch myself to make sure I'm not dreaming when I'm out at the field getting paid to do this stuff. Unfortunately it's only a small percentage of my week, but as the weather gets colder here in MN I'll be saying *fortunately* it's only a small percentage of my week. :-) Once the snow flies we are going to have to figure out if we are going to switch to skis (which I have had poor luck with in the past) or find some big floats (which people say work well.) Or find some sort of plowed area to fly from ... probably depends alot on what the weather does or doesn't do for us here. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] PID Controller Bug?
I seem to recall Erik commited a change to the autopilot code in the
last week or so. Does that fix something? Did that introduce a new
problem? This is pretty subtle, complex code so people shouldn't be
messing with it too much unless they are really sure they know what's
going on with it.
Curt.
Hans-Georg Wunder wrote:
Hello Jeff,
I found the same bug some days ago and I reported it here on the
lists. Your solution was also my first approach, but it did not work
for the Integrator-part. The value ep_n is wrong for the next cycle.
But after a looot of testing I found this solution:
// Integrator anti-windup logic:
if ( delta_u_n (u_max - u_n_1) ) {
// We have to add the maxium, which is posibble and then
// to reduce the input value for the next cylcle accordingly
ep_n = (ep_n * u_max )/(delta_u_n+ u_n_1 );
if ( Td 0.0 ) edf_n = (edf_n * u_max ) / ( delta_u_n +
u_n_1 );
delta_u_n =u_max - u_n_1 ;
// delta_u_n = u_max - u_n_1;
// ep_n = delta_u_n / Kp;
//ep_n =- u_max/Kp;
if ( debug ) cout Max saturationNew delta_u_n
= delta_u_n New ep_n = ep_n ew edf_n = edf_n
endl;
} else if ( delta_u_n (u_min - u_n_1) ) {
// We have to add the maxium, which is posibble and then
// to reduce the input value for the next cylcle accordingly
ep_n = (ep_n * u_min )/( delta_u_n + u_n_1 );
if ( Td 0.0 ) edf_n = (edf_n * u_min ) /(delta_u_n +
u_n_1 ) ;
delta_u_n =u_min - u_n_1 ;
// delta_u_n = u_min - u_n_1;
// ep_n = delta_u_n / Kp;
//ep_n =- u_min/Kp;
if ( debug ) cout Min saturationNew delta_u_n
= delta_u_n New ep_n = ep_n New edf_n = edf_n
endl;
}
I tested it for a P and a PI-controller. I haven't tested yet the
D-part, but I hope, it will work too
It would be nice, if you also could test this solution.
Feed back is welcome
Kind regards
Hans-Georg
Jeff McBride wrote:
I have been playing around with the autopilot this evening, and
noticed something that seems to me to be broken.
I ran into a problem where I would see a really large change in output
(delta_u_n) but the output would not change (yes, this probably also
means my gains need some adjusting), e.g.:
- From debug output ---
Updating Yaw Stabilization
input = 119.876 ref = 0.000610361
ep_n = -119.875 ep_n_1 = -118.088 e_n = -119.875 ed_n = -119.876
delta_u_n =
-2.96522
P:-0.268029 I:-2.69719 D:0
min saturation
output = 0.982904
---
So I checked the code in xmlauto.cxx and found that yes, these lines
were responsible for zeroing delta_u_n:
- From xmlauto.cxx
// Integrator anti-windup logic:
if ( delta_u_n (u_max - u_n_1) ) {
delta_u_n = 0;
if ( debug ) cout max saturation endl;
} else if ( delta_u_n (u_min - u_n_1) ) {
delta_u_n = 0;
if ( debug ) cout min saturation endl;
}
-
Perhaps I am not understanding this correctly (this PID controller is
not like any I have seen before), but it seems to me that it should
read:
// Integrator anti-windup logic:
if ( delta_u_n (u_max - u_n_1) ) {
delta_u_n = u_max - u_n_1; // --- CHANGED
if ( debug ) cout max saturation endl;
} else if ( delta_u_n (u_min - u_n_1) ) {
delta_u_n = u_min - u_n_1 // -- CHANGED
if ( debug ) cout min saturation endl;
}
-Jeff
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Crash carnage
Arnt Karlsen wrote: ..ahem, the big guys use opening shock damper rings to keep chute loads safe throughout the speed range, these rings use the chute opening loads to slow the chute opening. ;o) Except that I heard a story recently about a guy that got himself into a bad high speed situation, deployed the chute and had is airplane shreaded to pieces. They probably have systems in place (as you suggest) to minimize potential problems, but a chute obviously can't handle every situation. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: Simgear and SGFile usage in FGFS
Alex Perry wrote: Unless I'm missing something, someone has committed bad code to CVS. The ch variable on line 377 is of class SGIOChannel, which doesn't support the eof() method, and not of class SGFILE, which does. ~/fs/source/utils/GPSsmooth$ make if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../../src -I/usr/X11R6/include -I/usr/local//include -g -O2 -D_REENTRANT -MT MIDG-II.o -MD -MP -MF .deps/MIDG-II.Tpo -c -o MIDG-II.o MIDG-II.cxx; \ then mv -f .deps/MIDG-II.Tpo .deps/MIDG-II.Po; else rm -f .deps/MIDG-II.Tpo; exit 1; fi MIDG-II.cxx: In member function `int MIDGTrack::next_message(SGIOChannel*, MIDGpos*, MIDGatt*)': MIDG-II.cxx:377: error: `eof' undeclared (first use this function) MIDG-II.cxx:377: error: (Each undeclared identifier is reported only once for each function it appears in.) make: *** [MIDG-II.o] Error 1 Yup, missed a commit. Should be in cvs now. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Crash carnage
This is somewhat off topic, but in the spirit of open source I'd like to share the tragedies as well as the triumphs ... http://www.flightgear.org/~curt/Models/Special/Rascal110_1/ This is part of a university project I'm helping out with. We have a backup plane and our expensive instrumentation survived intact, so this shouldn't be a severe setback to us. Very high on my todo list is to build some glue code that can take live IMU/INS/GPS data from the airplane (sent over radio modem) to the ground station and display a live synthetic view of the airplane using FlightGear. If I'm successful with building the link, then the next obvious thing to try is to fly the airplane looking only at the real time FlightGear view, not looking at the real airplane. Beyond just being a fun thing to try, you could imagine putting some representation of restricted airspace in the synthetic view, or other objects that are important to your mission ... whether that be monitoring traffic, wild fires, surveying damage after a storm, etc. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Crash carnage
Dave Martin wrote: Just done some more reading of your page and incident analysis; I was just thinking that a useful tool would be a couple of camcorders. (and a friend to operate one of them). If you set one up on a tripod looking at the transmitter, you could at least see what control positions you were *trying* to get at any given time. The second camera could be kept on the aircraft itself. Both cameras would need to be synced to keep the correct time (for comparison with your UAV data). We do have a camera on board looking forward and down, but our helpful video capture application decided that there was so much snow and bad signal in the video stream (primarily after the crash) that it helpfully deleted that entire segment of video for us. Ya gotta love windows! One thing we'd like to do that wouldn't be too technically difficult would be to get a 2nd receiver on the same channel as the aircraft but keep it on the ground. Pipe the servo outputs from the ground based receiver into a little PIC board and decode the PWM signals coming in on each channel and send them out the serial port to the ground station. This would be a way to record pilot inputs without needing extra equipment in the air. It doesn't tell you about loss of signal or interference issues with the airborn system, but it does tell you what the pilot is trying to do. I think we'll get there ... you learn as you go with this stuff and it takes time to assemble equipment and develop software and interfaces. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] missing libraries for MIDGsmooth
Martin Spott wrote: Hello, I'm happy to realize that almost everything in the Sim-/FlightGear source tree compiles cleanly on IRIX (thanks Erik !!). There's just a small utility left that doesn't build: make[2]: Entering directory `/usr/local/src/FlightGear/utils/GPSsmooth' CC [...] -c99 -I/opt/FlightGear/include/simgear/compatibility -D_REENTRANT -exceptions -L/opt/lib32 -L/usr/freeware/lib32 -Wl,-rpath -Wl,/usr/freeware/lib32 -s -L/opt/FlightGear/lib -L/usr/local//lib -o MIDGsmooth MIDG-II.o MIDG_main.o -lsgio -lsgtiming -lsgmath -lsgmisc -lsgdebug -lsgbucket -lplibnet -lplibul -lm -lz ld32: ERROR 33 : Unresolved text symbol SGPath::SGPath(const std::basic_stringchar,std::char_traitschar,std::allocatorchar ) -- 1st referenced by /opt/FlightGear/lib/libsgbucket.a(newbucket.o). ld32: ERROR 33 : Unresolved text symbol SGPath::~SGPath(void) -- 1st referenced by /opt/FlightGear/lib/libsgbucket.a(newbucket.o). In a first step I added -lsgbucket to the linker command in order to resolve another missing symbol but I can't tell which library this call from libsgbucket depends on, Martin. Try adding -lsgmisc (I think that is where SGPath resides.) If that works we can add it for everyone. Most systems don't care about library dependencies for calls that aren't used, but irix seems to need to resolve all the dependencies in a library, even for functions that are never called or used. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] missing libraries for MIDGsmooth
Martin Spott wrote: Curtis L. Olson wrote: Try adding -lsgmisc (I think that is where SGPath resides.) It does. Thank you, Martin. I notice that -lsgmisc is already there. Did you have to move it to a differerent relative place in the link command? Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 2 Questions: Terrain data? Flight Sim 200x aircraft?
Mike Kopack wrote: Hey gang, I'm needing to integrate with a 3rd party planning system that does terrain avoidance routing. I do not know yet what format their system needs the terrain data in, but I was hoping somebody could point me to the original terrain data location that was used to create the terrain models for Flight Gear. Hopefully there will be an easy way to convert between the two so the terrain in my FG demonstration will match up with where their planner things hills and water and such are. FlightGear uses SRTM data: ftp://e0mss21u.ecs.nasa.gov/srtm/ As far as I know, this is the best most complete terrain data set that is freely available. Second, while investigating some stuff for another project, I ran across a reference where somebody used a MS Flight Sim aircraft model for a Predator UAV and used it on Flight Gear. Unfortunately, it didn't explain how they did it. How would I go about doing this (since my project is to control a UAV, it would be a lot more credible to show the customer a Predator on the screen than a Piper Cub!) We have quite a few skilled 3d modelers here. If you can't find an existing model to adapt, perhaps someone here would be willing to build you one for a nominal fee? Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Digitrak and three axis gyro
I don't know how detailed you want to get with the digitrak modeling, but as a first pass, you could just assume that what ever the digitrak is doing, it's keeping a pretty good estimate of reality. If you make that assumption, then you could just use the raw pitch, roll, yaw values from FG and move on to the higher level modeling. As Paul suggests, if you want to really model all the internal sensors, you really have to know exactly what they are, how they are calibrated to some absolute reference, what math is going on behind the scenes, etc. etc. Curt. Paul Kahler wrote: On Wed, 2005-09-14 at 20:35 -0400, Steve Knoblock wrote: The Digitrak is described as employing gyroscopic rate sensors are installed so as to sense motion about each of the major axes (roll, yaw and pitch). I assume they mean there is a spinning gryo around which three sensors are arranged, to sense motion in each axis, pitch, roll and yaw. The sensors report how much the aircraft has moved around the gyro for each axis. Gyroscopic rate sensors measure rotation rate around a single axis with respect to whatever they're mounted on. To measure 3 axis motion requires a minimum of 3 sensors. There are no gimbals or spinning objects (vibrating parts yes). Tracking orientation with them requires integrating the signals in a rotating reference frame. You also need an absolute reference because the integrated signals will drift. Here's something google turned up: http://www.smalltimes.com/document_display.cfm?section_id=76document_id=7451 From what I can see of the various default instruments in FlightGear, the only source of roll angle from an instrument is the attitude indicator or indirectly, the turn coordinator, which the Digitrak does not use. I conclude that to model the Digitrak fully, I would need to create C code to represent this three axis gyro using the gyro.*** code that the attitude indicator depends on. I have a little experience with C, but not much. I nearly understand how the attitude indicator works with the gyro model, but I still have to many questions to comprehend all it is doing. I also assume that using /orientation/roll-angle is the best substitute currently available. I would appreciate any help with this and please correct me if I am wrong in any of this. The only way to really know what the Digitrak is doing is to know what it's really doing ;-) I think the Digitrak would make an interesting contribution to FlightGear. It would, but you may be limited to just a visual representation and some other autopilot code. It would be really hard to know exactly what their software is doing without access to source code. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug in moving-average filter?
Done ... Roy Vegard Ovesen wrote: Lee Elliot: Hello List, I think there's a small bug in the moving-average filter in xmlauto.cxx I noticed that the output from it was always out a bit and checking with a calculator showed that it seemed to be dividing by the number of samples + 1 instead of just the number of samples. subtracting 1 from 'samples' in line 702 seems to fix the problem and as 'samples' doesn't seem to be used elsewhere I think it's safe. Possibly implies that the number of samples may be one less than specified but I'm not familiar enough with c++ to spot it. You are right. I would suggest resizing input[] to (samples + 1) instead. Change lines 654 and 661 to: input.resize(samples + 1, 0.0); That way we average over the number of samples as configured. Can anyone commit this?! -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Question: Online forums?
I have a question I'd like to toss out to the group for discussion/comment. What would people think of abandoning our mailing lists and converting over to online/web-based forums? - People would only have to subscribe once and they could access all the *Gear forums. - I'm getting really sick of spam. I think we do a pretty good job of protecting the list members themselves, but the list admins get continually pummeled with spam rates measured in messages per hour and sometimes messages per minute ... If we would like to move towards using forums instead of mailing lists: - Should we manage the forums ourselves on our own FG servers? - Should we use some other forum hosting service? - Should we piggy-back off of a place like avsim.com (which already has one general FG forum.) - I generally favor the idea of local admin control so we can set up the various sub forums exactly how we like, but that means additional setup and maintenance efforts on this end. - If we run our own forum software, does anyone have any recommendations. (Bearing in mind that right now, mysql is hopelessly hosed on our FG servers and a complete purge and reinstall has not fixed it.) Are there any mainstream, quality forum packages that don't require mysql? Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Question: Online forums?
Melchior FRANZ wrote: Or simpler: don't allow anyone who isn't subscribed to post to the lists. There's still the AVSim forum and the IRC channel for notorious non-subscribers. I'd prefer an official forum on flightgear.org for that, though. AVSim does in no way feel official. (Is it 'official' at all?) Postings to the forum could be forwarded to the users list, and replies to such messages there could get copied back to the forum. Unfortunately, I've not the slightest idea which forum software to choose. :-( Right, but someone has to answer the listname-admin mail and sort out if it's spam or perhaps a legitimate user having a problem posting or subscribing. And unfortunately there is a *ton* of that type of spam to wade through. My spam filters do weed out most of it, however, spam consumes a substantial amount of net traffic and server resources. Converting the FG email lists to web based forums would eliminate 98% of the spam hitting our server ... we could at least bounce back no such address, rather than having to accept the mail, scan it for viruses, scan it to compute a spam rating, and then deliver it to the list admin who then has to further filter it, either manually or with automated tools or both. I think the one thing we would lose with a forum system would be the ability to sort individual messages that are important to the recipient (such as a todo item, or an item requiring further investigation) into our own mail box system. There's more opposition to this idea than I expected, so perhaps this issue should go on the back burner for now and we can revisit it in a few months or a year (or not at all.) Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Question: Online forums?
Christian Mayer wrote: I hate forums. At a mailinglist I've got nothing to do - they come to me. At a forum I must think of querying it once in a while - I have to come to them. It's like the difference between polling and interrupts... - I'm getting really sick of spam. That's a valid point. But I think that can be handeld automatically. THe admins get 2 kind of mails: 1) valid mail that bounced 2) SPAM 3) valid user requests that aren't bounces, but legitimate requests for help. If you'll just have an autoresponder that tells all reasons why a mail bounced (like: your email address isn't registerd and/or your mail is bigger than 40kb) valid users know how to get their next mail through - and the SPAM doesn't affect *you* anymore. If you really want to switch to a forum I'd only use it for the fgfs-users mailinglist. There I can think that the advantages outweight the disadvantages - but we still need some people that poll that forum. An average developer probably hasn't got the time... Hmmm, forums for the average user base might be a worth while idea. The one thing I do like about forums is that you can split up, categorize, and organize the discussion areas. That's a lot harder to do with mailing lists because of the individual overhead of subscribing to each group, and a hierarchy of mailing lists doesn't make a lot of sense. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Question: Online forums?
Sylvain Mazet wrote: Hi, I am also just playing with FG, lurking on the lists searching for info. I prefer mailing lists, but it would be really nice if the archives at flightgear were searchable. They are searchable last I checked. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Question: Online forums?
Erik Hofman wrote: I'm for dumping every mail not from a list member instead. We already do that. The problem is with all the [EMAIL PROTECTED] and [EMAIL PROTECTED] mail. These addresses can't be avoided and are a huge spam attracter for the two flightgear co-list admins. But just to be clear, I'm not trying to solve a spam problem by nuking our mailing lists. Spam avoidence (for the list admins) was only one of the possible motivations for moving to forum based communication. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Question: Online forums?
Paul Kahler wrote: This may be too late now unless the address changes. Get the email address off the web pages. Just where do you think the spammers are getting the address from? My ISP has some form of spam blocking, but I receive about 1 spam every month or two. I think the reason for this is that my email address isn't posted in plain text anywhere on the net. It is there of course (on my contact page), just not in machine readable form. This may not be practical for FG. I dunno, just a thought. I believe the addresses, especially the ones getting spam are not posted anywhere ... except there are places that archive the flightgear mailing lists and at least in the past have kept all the email addresses intact in clear text. :-( New stuff is generally ok, but stuff in the historical archives out there is mostly what's getting us. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announcement: First TerraGear landcover database export
Paul Surgeon wrote: I noticed that a lot of airports in the X-Plane DB are quite far out. Even some major airports like Sion were out by ~ 3 km. What I do find interesting is that the quality of the data seems to change for every country. South Eastern France's data was horrid, so was Switzerland's however Italy's data was almost spot on more than 90% of the time. Maybe someone corrected the data for Italy already or maybe it came from a different source. Also it appears that a lot of the data was pure guess work in a lot of cases. I saw plenty of runways that were more than 20 degrees out, runways that were more than 50% too short, wrong runway id's, wrong surface types, etc. Ever seen a military airport with a single 500m long grass runway that they use for F18's, Mirages, etc? :) My understanding is that for the USA, the X-Plane data for runways comes primarily from DAFIF. Taxiways are all hand drawn and placed. Outside the USA the runway data is manually generated by anyone who wants to submit new airports, so quality and accuracy is all over the map. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] DHC-6 (100) Twin Otter 3D model
[EMAIL PROTECTED] wrote: I had the urge to fly DHC-6 Twin Otter in flightgear... ac-3d-file: http://thorben-mit-th.de/files/dhc6.ac Screenshots: - http://thorben-mit-th.de/files/dhc6-alpha001.jpg Looking good ... If somone has information about how Syd Adams made this simply wonderful panel of his b1900d, I would love to hear that also. Hopefully Syd can reply with some of his tricks! If somone happens to have a working FDM lying around, I would be delighted to use it. I would think that you wouldn't be too bad off just starting with a copy of the B1900 FDM configuration and making changes from there. I suspect those two aircraft have (roughly) similar performance. Often if you hunt around the net you can find basic dimensions, weights, fuel capacities, engine power, and cruise/stall speeds. Armed with those you can go in and start tweaking values (changing one number at a time and testing to make sure the solver still solves ...) and it doesn't take too long before your model is starting to get in the vicinity of where you'd like it to be. YAsim (which is what the B1900 model uses) is kind of fun and addicting once you start playing around with it. Of course there are several JSBsim approaches you can use if you want to move that direction with your flight dynamics. There is a jsbsim mailing list where they can help you with specific modeling questions (but be warned that JSBsim is a bit more complicated compared to YAsim ... JSBsim gives you the possibility of creating a more accurate model, but you *really* have to know what you are doing to make adjustments and changes. What I plan next (in this order): - controll surface animation - FDM - gear animation - adding more details such as antennas - texturing - cockpit - perhaps some Nasal scripting Sounds great. If you want to make your model available via the CVS repository just let me know. You can submit incremental changes as you progress and others can track your progress (or even help) if they want to. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] What's up with alut?
I was just trying to build simgear on a fresh Fedora Core 4 machine and pulled the latest OpenAL cvs snapshot. The most recent openal-cvs no longer includes alut for linux? Does anyone know what's going on there? Simgear uses alut so this is a problem (assuming I'm not doing something stupid.) Anyone know what's going on over in the openal camp? Is there an officially different/better way to do stuff now? Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Custom Scenery for Lake Constance
Martin Spott wrote: Ralf Gerlich wrote: [...] This is quite a good field for improvement in FlightGear if you're unable to help with the coding. Let's see what comes around with Martin Spott's PostGIS server. I'm currently on my way populating the database. Curt, does the script 'TerraGear/src/Prep/TGVPF/process.sh' in CVS represent the current state of what you would use for a scenery build ? I think it's pretty close. It takes too long to run the entire script for the whole world so I probably copy/pasted lines out of it and ran smaller sections by hand, but otherwise it should be pretty close. There is room for preferencial adjustments as well. Once you start digging into a scenery build, you might come up with some of your own ideas and preferences for how things should be done. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Custom Scenery for Lake Constance
Martin Spott wrote: Hello Curt, Curtis L. Olson wrote: There is room for preferencial adjustments as well. Once you start digging into a scenery build, you might come up with some of your own ideas and preferences for how things should be done. I'm unable to dig into scenery building myself I have because I didn't manage to compile the necessary libraries/programs. Now in order to avoid blind guessing I simply ask because I want to ensure that the landcover data I put into my database upon initial loading serves to build the same scenery as you would build from stock VMAP0 data. This basis should serve as a foundation for future improvements. Was my response a satisfactory answer for you then? I'm not sure I can parse your message here? You aren't building scenery yourself, but you are building a scenery building server??? I'm confused. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] MIDG-II
I had a chance this week to fly a MIDG-II in my university's Sig Rascal 110. The MIDG-II is a combination gps/ins/imu type deal that outputs both position (gps) as well as gyro/acclerometer based attitude (roll, pitch, yaw.) It can also output magnetometer readings as well as velocities and raw accelerations. It's a neat toy for doing UAV type stuff: http://www.microboticsinc.com/midg.html We connected the serial output of the MIDG via a radio modem link to a laptop on the ground which let us monitor the flight in real time and captured the binary data stream. Today I whipped up a little program to load and parse the binary data and feed it into FlightGear The MIDG dumps out position at 5 hz, and attitude at 50hz. This is more than enough to capture a lot of the subtle nuances of the real flight ... dutch rolls, aileron rolls, loops, slips, jittery thumbs, wind gusts, etc. can all be seen in the resulting replay. I might be the only one here who's had a chance to play around with one of these, but if anyone else has one or has something similar, it's kind of neat to pump the data into flightgear and watch the flight from inside a virtual cockpit, or from a chase view. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: very long startup time
Erik Hofman wrote: Alex Romosan wrote: code but it's a hopeless mess. in the meantime i've lost my temperature and visibility etc. (they are all set to zero). it must be some change i made but a cvs diff doesn't show any relevant changes. strange, very strange. I noticed this too. You will need to set the weather scenario to a different value than none. Perhaps none is not the best default value to come up with? Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom Scenery for Lake Constance
Ralf Gerlich wrote: Hi, Alex Perry schrieb: Try watching your virtual memory usage and see whether you're hitting the 2GB (or 3GB) limit within that process. If you are, it is worth patching TerraGear until it runs cleanly on all 64 bit architectures. If it isn't a memory problem, we can stick with the 32 bit for now. I already had thought about that. I have Pentium-M with 512MB of RAM and a 1GB swap-partition. Interestingly fgfs-construct does not even get the 512MB filled up - with lots of daemons and stuff using up memory in the background. Even more interestingly, when I run an strace on the fgfs-construct process, I see that the process is eventually SIGKILLed. I suspected that this is some kind of resource control on the side of the Linux kernel, which may KILL your process if it's using up too much memory of CPU time. However, a SIGKILL for CPU time excess is always preceeded by a SIGXCPU, which I cannot see in the strace-log. In addition, 'ulimit' reports that the CPU usage limit is 'unlimited'. An out-of-memory-kill should - according to the kernel source - be accompanied with a message to the console or the kernel logs, and I can't see any such message. I have even stopped all background processes I could, effectively putting my machine to single-user-mode, in order to rule out any other processes being so rude as to kill my scenery construction process. Unfortunately, that didn't help: The kill did still occur. I tried to find out whether there was some specific point at which the process is killed - perhaps there is some correlation with a previous action - using nested intervals and as few as possible test printouts in order not to modify the time-related behaviour of the code too much. However the actual point in the code where the kill occurred jumped as soon as I moved a printout marker from one place to another and the places I observed did not seem to be related to the kill in any way. I'll try running the construction on a different computer. It's been a while, but scan the fgfs-construct code for some sort of ulimit checking built into the code. I seem to recall there was some code there that would cause the process to self destruct if it sensed it was taking too long or consuming too much memory? This is useful in the parallel build framework so that an infinite loop (our delauney triangulator and polygon clipping routines can go degenerate at times) doesn't derail the whole build. The thresholds may need to be tweaked or even eliminated. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [Fwd: Simgear-cvslogs post from [EMAIL PROTECTED] requires approval]
see attached msg ... -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ---BeginMessage--- As list administrator, your authorization is requested for the following mailing list posting: List:[EMAIL PROTECTED] From:[EMAIL PROTECTED] Subject: In the need for the last source Reason: Post to moderated list At your convenience, visit: http://mail.flightgear.org/mailman/admindb/simgear-cvslogs to approve or deny the request. ---BeginMessage--- Hello to everyone. Would Any One please send me the last ready-to-build (tar.gz) version of SimGear? Seems that my network administrator, block the ftp port or something in the firewall, so i cant ihave the last version right from the ftp server. Well the fact is that i was able to access the CVS version of SimGear, but apparently I dont know how to build it in the right way, because when Im compiling Flight Gear, there seems to be missing a lot of the SimGear headers (for example the headers to use 3D clouds, etc). So please anyone? Thank you SO MUCH! Julian __ Renovamos el Correo Yahoo! Nuevos servicios, más seguridad http://correo.yahoo.es ---End Message--- ---BeginMessage--- If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply.---End Message--- ---End Message--- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: Mojave, CA
Martin Spott wrote: Curtis L. Olson wrote: [...] However, it has only very basic out the window graphics. I'm doing a (hopefully quick little) project to build an interface from their software to FlightGear in order to use FlightGear as the visuals. Indeed this sounds interesting. Does it mean that FG will get a modern, full-featured and stable interface for external FDM's ? Sounds like you probably have something more specific in mind than can be expressed in a single sentence. The particular adjectives you've chosen could be loaded with additional meaning (or not.) :-) I'm not aware of any industry standards that coule be targeted, even if we wanted to target something. From what I've seen, this stuff is very project (and aircraft) specific. As with any feature request, you are welcome to code something up yourself if the collective group isn't moving fast enough for you. :-) Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: Mojave, CA
Martin Spott wrote: Well, I prefer you to understand it as well-meant lobbying, driven by the strong feeling that FG needs this - not for me but for others who could do much more by connecting an external FDM to FG than I ever could. Just have a look at the CIGI Interface Control Document, they do care very much about defining the low-level protocol. Although CIGI isn't adequate for being used as FDM interface for FlightGear I find it very interesting to see how they approach the goal to offer a reliable interface to the developer. When I became aware of FG I first started looking for something like a remote FDM interface definition, but I was put off by the simply copy the struct way that I would have had to go. As I was quite uneducated in mangling other people's C++ code I grounded my project after a while. As you know I'm not the only one who felt offended by the mentioned 'interface'. Other people who actually _did_ interface to FG decided not to follow the ongoing changes and stick to old FG versions as long as there is no 'official' interface definition that they can expect to be stable and platform independent. Now as you aim to interface to a quite unrelated FDM I had the hope an interface definition that matches the forementioned attributes might evolve as a side effect. Well there is always a struggle between designing the perfect module or interface and getting things done. Too much designing and you can design something that can't be built in a finite/human time frame. With no design effort or advance thought, you end up with a big mess. So there needs to be a balance between the two ... obviously we want to get things done, but obviously we want to avoid big messes. There is a proposal on the table for a flexible binary structure similar to the generic protocol, but binary. But as far as I know, no one has started any coding. But, an FDM interface needs to do more than shove a datastructure back and forth. There needs to be some higher level communication to tell the remote FDM when it should reset it self or when it should trim for in air or on the ground, and what trim conditions are requested (i.e. start in air at 4500' MSL, 98 kts, 10 degree flaps, gear up, in a 20 degree right banking turn.) There are also very important and difficult timing issues to consider with a remote FDM. How those are handled can have a *huge* impact on the latency and smoothness of flightgear rendering. The other issue to consider is we could create the worlds most super whiz bang remote FDM interface, but you must remember that 99% of the time, people are trying to interface to remote FDM code that already exists. These people typically aren't going to want to spend months implimenting the other end of our super feature rich protocol, and the more complicated we get, the less they'll want to write the other end of it. As you suggest, passing a C struct over the net has some disadvantages, but it is simple, it is easy to code, it is efficient, and can be made to work very well. Most people doing this stuff are doing it on the same machine, or between similar machines. If endianness does pose a problem, these people are usually smart enough to quickly discover that and the fix is pretty easy (maybe a bit tedious but easy.) There are always a lot of factors that influence people's design decisions, and don't be too quick to rule out simple, easy, robust, quick to code As I'm sure you know there is room for many different interfaces within the FlightGear umbrella, so if anyone wants to do something better (or maybe I should say something with a different feature set and different strengths and weaknesses) we all would welcome it. In open-source, good ideas tend to succeed and grow, bad ideas tend to die on the vine ... but no one wants to stand in the way of anyone trying out a new idea ... that is one of FlightGear's core values. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: Mojave, CA
Jim Wilson wrote: BTW great pictures Curt. Sharp looking crew as well :-) And a very exciting flight story. The scariest jet airline flight I've been on was one that landed on Corfu and it was 100% routine. I have serious doubts that this jet could have stopped on the runway if an engine was out and beyond one end of the runway is water and buildings (houses, etc) on the other end. No room for overruns. When the aircraft finally braked to a stop, I actually thought we were a little off the end of the runway from the poor viewing angle I had in the cabin. The takeoff later was equally interesting, although by then I had convinced myself that they did this every day and we would make it, which we did. I had a flight out of Cuzco, Peru (we were up to see Macchu Pichu) that was interesting. The Cuzco airport is up about 11,500' MSL and we were flying out of there in an old beater Boeing 727. I had a stop watch so I started it when we began our take off roll. We got airborn and everything was normal, but because of the geography of the area, 5 full minutes into flight we were still seeing terrain straight out our window and still very close. That's not something I'm used to seeing around here in Minnesota. Anyway after all the exciting stories, is there anything more you are able to say about the simulator project mentioned top of the page? Let's see. The NTPS has some simulator software that is their own proprietary product. The strength of their software is that it is really well suited and tuned towards developing and evaluating the performance of a modern fly-by-wire aircraft (and is well proven in action.) However, it has only very basic out the window graphics. I'm doing a (hopefully quick little) project to build an interface from their software to FlightGear in order to use FlightGear as the visuals. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: Mojave, CA
Lee Elliott wrote: Liked the 3 engine 747 :) The Draken is an interesting a/c - I saw the one at Duxford, here in the UK, and was surprised at how close to the ground the wing trailing edge was. When looked at from the back I rather thought it looked like a huge moth. I don't know how much more work I'll do with the National Test Pilot School (pending the results of the current small project) :-) but if things go well, there may be some modeling work that needs to get done at some point. Any interest in that sort of thing, or do you keep busy enough with your day job and hobbies? The Draken is a really impressive bird, especially considering the era in which it was designed. The US is pretty cocky about stuff invented over here, but the Draken had some really impressive specs for it's day. To be honest, I stared and squinted at the real scene for the longest time trying to figure out if my eyes were playing tricks on me or what. It wasn't until I got to see the full digital picture that I figured out the 747 hump was behind the DC-10/MD-11. :-) Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] OT: Mojave, CA
In case anyone is interested in looking at airplane pictures, I just returned from a trip to Mojave, CA (KMHV) where I got to see a bunch of neat aviation stuff. I took some pictures and posted them here: http://www.flightgear.org/~curt/Photos/KMHV/ Mojave is home to a lot of wind mills on the ridge overlooking town, home to Scaled Composites (Burt Rutan/Space Ship One), Orbital Dynamics, the Rotary Rocket (tm), an aircraft boneyard, and the National Test Pilot School ... lots of neat toys, aircraft restoration, research, development, and other projects going on out there. There's also a lot of heat, desert, tumbleweeds, and a whole lot of nothing once you get off the airport property. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Free simulator of the Frecce
Martin Spott wrote: I heavily object because this lets FlightGear definitely cross the line between serious simulation and war games, I think what we have to come to grips with is that just about any tool ... software or hardware can be used to benefit humanity (or our enviroment or whatever else might be higher on your priority list) or harm it ... and if not directly, it certainly can be used indirectly. Go watch The God's Must Be Crazy and see what kind of craziness ensues from a simple coke bottle. (Curt gives the movie 5 out of 5 thumbs up.) As we move forward, there is going to be pressure to be able to drop items or fire items from a moving airplane ... forest fire water bombers will want to drop retardant/water, we may want to simulate a rocket launch from 35,000' to deploy a civilian communication satellite, maybe we want to drop the X-15 from a B-52, maybe we want to drop a dozen realistic parachuters and the practice landing without flying into any of them, maybe someone would want to air drop humanitarian items to needy people. And it makes sense to add these to a simulation so you don't accidently drop a ton of rice on the people you are trying to feed, or drop it on their one remaining goat. But by adding these features, we open the door to all the logical extensions that might move us towards more direct shoot 'em up style games. I honestly don't think it's possible to prevent that, and I'm not sure it's worth shooting ourselves in the foot (so to speak) just trying to lock out the FPS gamer crowd. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
-- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ---BeginMessage--- [I was rejected to post to the mailing list, resending to you] Hello Flightgear crew, we at SUSE recently stumbled upon this problem: some of the code contained in FlightGear contains a non-commercial lincese which forbids us from further distributing it. The consequence is that FlightGear wouldn't be part of the upcoming SUSE Linux release. The affected files are: src/Time/moonpos.cxx src/Time/moonpos.hxx src/Time/sunpos.hxx Their license doesn't allow further redistribution of the code for commercial purposes... One solution is to remove or rewrite the aforementioned code, or to replace it with other freely available solutions (like libastronomy - http://home.cs.tum.edu/~roalter/libAstronomy/). I hope we will come to a conclusion that will satisfy both sides; P.S. CC me, I'm not subscribed Regards, -- Lukáš Tinkl SuSE KDE developer --- SuSE CR, s.r.o.  e-mail: [EMAIL PROTECTED], [EMAIL PROTECTED] Drahobejlova 27  tel: +420 2 9654 2373 190 00 Praha 9  fax: +420 2 9654 2374 Czech Republic  http://www.suse.cz/ ---End Message--- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cirrus SR20 Model?
Jim Wilson wrote: You might want to talk to her/him about offering a bounty. What is really intended with the owned model? Selling it? Folks should beware of giving up their copyright for smallish fees, you may regret it later when you want to reuse some of your own work. It's not nearly that evil. This person has a software product they plan to bring to market soon. They want to interface their product to a stock version of FlightGear to add an optional 3d visualization component. It's not required but increases the coolness factor. The software product relates to the Cirrus SR20. So it would be nice from their perspective (bot not necessary) to have the Cirrus SR20 modeled. They don't plan to sell the model. Their main focus is to sell their own software. A nice add on feature is it's ability to interface to FlightGear. And even nicer (for them) would be if FlightGear had an SR20 model. An SR20 model would be a nice addition to flightgear, so if we can find a volunteer to do this, that would be great. As Jim says, there is a lot of info available, and this person who is interested has an SR20 so he could provide all kinds of pictures and details that might be hard to dredge up from the net. If it helps motivate someone, he might be able to come up with a small amount of $$$ to do the job, but in this case, if he's spending his own money, he wants to own the result. My local airport has a certified Cirrus service center and a buddy of mine knows the main guy there so that's another potential source of information. Is anyone interested in taking a crack at this? Best regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Tile manager customization
BONNEVILLE David wrote: Hi people, I wonder if today, there is a way to customize the tile manager in preferences. Is it possible to set the number of tiles to load around view position ? The covered area to load ? Could somebody explain me the tile loading/queuing policy ? Thanks in advance. Hi David, The system is based off the visibility distance. The tile manager can compute the size (width x height) of a tile at the current location. Then it computes how many tiles vertically and horizontally it needs to load to cover the specified visibility distance completely. Then it sends a series of tile load requests to the tile loader thread. It starts out by requesting the current center tile, then it requests the first concentric square ring of tiles (3x3 minus the center tile). Then it requests the second concentric square ring (5x5 minus the 3x3 minus the center) and proceeds until all needed tiles have been requested. The loader thread checks the tile cache to see if a tile is already loaded or not. If not already loaded, it dumps an old tile out of the cache and starts loading the new one. The system is quite complex because we wanted to impliment the tile loading as much as possible in a seperate thread. But there are many unfortunate constraints with opengl and plib so we ended up with a hybrid that does some work in the tile loader thread and some work in the main thread. And as is usually the case with real world threads, there are a lot of really subtle and difficult interactions that must be considered. So if you poke around in that section of the code, please tread very carefully because any seemingly innocuous change, could blow up the whole thread interaction scheme (or introduce bugs that occur rarely and are very difficult to track down.) Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cirrus SR20 Model?
Arnt Karlsen wrote: On Wed, 20 Jul 2005 20:38:39 -0500, Curtis wrote in message This could go two possible directions. If someone wants to volunteer to do this, it could be contributed to FlightGear for everyone to enjoy. The person requesting this might also be able to pay some smallish amount (yet to be determined) to have this done, but if he pays for it, he wants to own the result for his own use, and it couldn't be contributed to flightgear.. ..he who pays can _both_ own his paid-for SR20 and have us distribute it for him under the GPL. sigh I'm not sure if it's worth the bother to reply here /sigh But he who pays for something to be developed can do whatever he wants with it. In this case if he pays for the model's development, he doesn't want to give it away to everyone for free. That's his right and his choice to make. If someone is developing something on their own, they can dual, triple, quadruple license it however they want, but if they want to do an open-source + commercial license, they are going to have to find someone to buy it commercially, and if it's already available as open-source, why should someone pay for it? And there may be answers to that retorical question, but in this specific case, if there's already an SR20 model in FlightGear, why would this guy want to pay for it? Feel free to contact me off-line if you like. If more than one persons responds, I guess I need to reserve the right to make some hard decisions. :-) ..one of them could be spend more time explaining copyright law enforcement and the GPL to him, he either misses RMS' copyright law enforcement scheme behind the GPL, or he pretends to, like the SCO Group in Lindon, Utah. None of this last paragraph seems to make any sense in the context of this discussion. I'm not sure how useful it is to launch into a GPL/RMS/Groklaw/SCO rant every time the word commercial passes across your computer screen, especially when your comments don't seem to make any logical sense or have any connection to the topic at hand. Sorry if that sounded harsh, but I could be having a stressful day here or something like that. :-) Apparently no one is interested in doing a Cirrus model for FlightGear at this time, which is fine, I was just asking, and just presenting a couple different options for getting it done. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] OT: aviation movie link
I imagine there are a few people on this list that like to watch airplanes. There is some beautiful photography here (Requires quicktime plugin ...) http://www.onesixright.com/video/aerials.html Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS
Neville van Deventer wrote: Hi List, Could anyone perhaps tell me how to connect to the cvs at cvs.flightgear.org without getting the following error Error validating location: I/O exception occurred: Connection refused: I HATE YOU I followed the Instructions on the web-site, and I get the same thing for simgear as well. Any suggestions on how I can connect to the CVS ?? Hmmm, that's not a very nice error message, I'm sure it wasn't meant literally. :-( If you tell me the exact time you tried to connect and what machine you connected from (name/ip) I could look in the server logs to see if there are any clues there. I haven't ever seen this message before so it's hard to say if it's coming from our server, or being generated locally by your cvs client. What platform are you running on? CVS involves the network, so I don't know if there could be some firewall in the middle that is blocking traffic. Do you get long time outs before the error message, or is it returned immediately? Do you have write access to your local cvs tree and enough disk space? That's all I can think of off the top of my head. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Cirrus SR20 Model?
Is there anyone out there in FlightGear developer land that would be interested in doing a Cirrus SR20 model for FlightGear? Highest priority would be the 3d model and as much of a 3d cockpit as we can do (realizing we aren't real strong on the glass cockpit stuff yet.) This could go two possible directions. If someone wants to volunteer to do this, it could be contributed to FlightGear for everyone to enjoy. The person requesting this might also be able to pay some smallish amount (yet to be determined) to have this done, but if he pays for it, he wants to own the result for his own use, and it couldn't be contributed to flightgear.. Either way, the nice thing is we have direct access to a real SR20 and a real SR20 pilot so we should be able to get as much information and as many pictures as we want. Is there anyone who'd be up for something like this? Feel free to contact me off-line if you like. If more than one persons responds, I guess I need to reserve the right to make some hard decisions. :-) Thanks, Curt. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] asymetric frustum
BONNEVILLE David wrote: Hi Curt, I am one week late but here are the pics that I hope will help you to help me ;-) http://paxettepaxou.free.fr/fg/horizontal_fov.JPG [17 Ko] http://paxettepaxou.free.fr/fg/vertical_fov.JPG [19 Ko] http://paxettepaxou.free.fr/fg/horizontal_fov_front.JPG [17 Ko] http://paxettepaxou.free.fr/fg/vertical_view_front.JPG [14 Ko] http://paxettepaxou.free.fr/fg/horizontal_fov_side.JPG [19 Ko] http://paxettepaxou.free.fr/fg/vertical_fov_side.JPG [15 Ko] As I told you in my last mail, I have a cylindrical projection and the point of view is not centered in the cylinder. I have three asymetric frustums (vertically and horizontally asymetric). I really hope it will help you to help me. Hi David, I'm not sure I can give you the easy answer you are hoping for. Right now the FG code really isn't setup to do the arbitrary assymetric view frustums that you need. I think it would be doable with a few days work, but I would need to also come to a better understanding of the glFrustum parameters (which are still a bit of a mystery to me.) I'm really swamped with projects right now and don't have a lot of extra volunteer time to give. But if you are doing this as part of an Oktal project, perhaps we could discuss my consulting rates off line. :-) Here's one more thing to keep in mind. If you are projecting onto a cylindrical surface, FlightGear cannot prewarp the display to compensate for the curved surface. If you are doing edge blending you will have a big problem because your overlapping regions won't match. You will find that without (correctly) prewarping the displays everything will be distorted on the screen. Even if you can get the edges to match up, things will still be distorted. For instance, your horizon line will most likly droop in the center of the display and be higher at the joints ... kind of like a wire suspended by several pole's. I suspect you probably know all these things and have projectors that can do proper warping and edge blending, but if not, be aware that this will cause you huge problems if you don't account for the warping introduced by projecting onto a curved screen. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are situational awareness APIs available?
Skunk Worx wrote: Am new to flightgear. Are there any APIs, demos, documentation related to using flightgear as a Situational Awareness display? Something like a central server serving real-time object type/position info (F15, F22, MIG29, AIM9), sent out to a cluster of displays, each info packet having the related object info (Roll,Pitch,Yaw,Heading,GPS coordinates, etc)? Then a person seated at one of the displays (Windows,MAC,Linux,etc) controls the view via commands like (click identifier in menu, goto view as chase, boresight, cockpit, etc.) I see a number of comments in the archives about networking and XML...does the team already have goals along these lines in process? It sounds like you may have a specific project in mind. Most likely FG can't directly do exactly everything you want, but we have many of the pieces in place. We can setup a single copy of FlightGear as a master machine and slave any number of machines from the master (for multiple out-the-window view channels, or for remotely monitoring a flight, or whatever you want to use it for.) I think we could still stand a little development in the area of drawing DCS objects from an external information source ... we have some of the pieces in place, but not everything. In these sorts of situations we hope that we have enough pieces in place to attract your attention and get you to use FlightGear for your project, and then when you add the additional features you need, contribute them back to the project and everyone benefits. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] 3dconvert.exe
Does anyone have a copy of 3dconvert.exe built for dos/windows that they can send me [offline]? Thanks, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] asymetric frustum
BONNEVILLE David wrote: Hi again, I saw few months ago some posts about asymetric frustum for a screen wall. I got a similar installation so I will have three displays, each of them with asymetric frustum (the point of view is not centered on the screens). I will have these parameters : LeftScreen_Left_FOV LeftScreen_Right_FOV LeftScreen_Top_FOV LeftScreen_Bottom_FOV CenterScreen_Left_FOV CenterScreen_Right_FOV CenterScreen_Top_FOV CenterScreen_Bottom_FOV RightScreen_Left_FOV RightScreen_Right_FOV RightScreen_Top_FOV RightScreen_Bottom_FOV Is there anybody who have ideas about this particular case ? How could I do it in FG ? I think I will have to modify SGFrustum in plib. Help welcome ;-) Hi David, If you could send me some more details about your exact screen configuration (a simple top down sketch might help) I believe I can help you come up with the right configuration values. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] asymetric frustum
Manuel Massing wrote: Hello David, I saw few months ago some posts about asymetric frustum for a screen wall. I got a similar installation so I will have three displays, each of them with asymetric frustum (the point of view is not centered on the screens). I will have these parameters : LeftScreen_Left_FOV [...] RightScreen_Bottom_FOV Well, as Curt stated already, that depends on how these displays should be aligned. Assuming you want to simply combine three coplanar, untilted views (e.g. for a multi-projector configuration on a single projection screen), and if these parameters are angles relative to the viewing direction, it should work as follows: -create a symmetric frustum with FOV of hor_fov = 2*max(-LeftScreen_Left_FOV, RightScreen_Right_FOV) vert_fov = 2*max(-CenterScreen_Top_FOV, Center_Screen_Bottom_FOV) -calculate the viewport coefficients [in range 0..1] by LS_l_coeff = 0.5 + 0.5*tan(LS_Left_FOV)/tan(hor_fov) LS_r_coeff = 0.5 + 0.5*tan(LS_Right_FOV)/tan(hor_fov) LS_t_coeff = 0.5 + 0.5*tan(LS_Top_FOV)/tan(vert_fov) LS_b_coeff = 0.5 + 0.5*tan(LS_Bottom_FOV)/tan(vert_fov) etc. These can then be set via the property system, i believe. Curt will surely be able to enlighten you on this. That's the basic idea. You specify a larger virtual screen that has a symmetric frustum and then each display get's assigned a portion of the larger display. I realize this is probably not an industry standard way to do it, and this approach probably can't cover every possible screen configuration, but I needed something quick a few months ago, and this approach meshed pretty well with the existing code. I shold point out that there is some subtle wierdness depending on the size of your display so for example, let's say you have 5 forward displays. The center 3 are all parallel so they need to act as a single larger fov display. If you want to assign 30 degrees field of view to each of them, you would naturally pick a 90 degree field of view for the center 3 and give each display 1/3 of that. However, you can't just give the 2 edge displays an symmetric 30 degrees and have them match up. There is some subtle aspect ratio stuff going on there that causes problems. So what you'd need to do is setup the side channels as a 90 degree fov virtual display and give them 1/3rd of that, then they should match up with the center channels. At some point it would probably make sense to clean up the view pipeline to handle this better, but time and priorities are always the big problem. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Terragear-devel]
Martin Spott wrote: Roberto Inzerillo wrote: So I guess, using more photoreal scenery into FGFS would give a more realistic result with less human effort then using default terrain textures, vector roads/lakes/rivers/railroads... I believe the most promising effort of this sort is 'osgPlanet' where you apparently can plug almost every sort of geodata. I wonder why Norman Vine didn't tell us about it ;-) He's mentioned it here and there ... but there's way too many good ideas and not nearly enough time. And as good as osgPlanet is, that particular approach has some of it's own limitations, but one of these years I'd like to sit down and play around with some of those things. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
