Re: [Flightgear-devel] Which aircraft to include in v0.9.9?
Innis Cunningham wrote: Hi Stefan Stefan Seifert writes Before 0.9.9 is released I think one problem should be resolved: on some planes (like the 737, f16, Concorde, fokker100) the engine sounds are missing. Specifically Sounds/jet.wav is not audible. I discussed this problem some weeks ago on the IRC channel and tried to find out what's causing it. It's no local problem and happens to all planes that use the /engines/engine[0]/thrust_lb[0] property for volume calculation. I had to stop investigating due to some real life stealing my time, but I'm sure this should be fixed before a release. I do a lot of my model testing on a 9.4 copy of FG and the engine sound is working just fine there.I will check out the 737 in 9.8 today and see if I can get to the bottom of it Sorry, should have given some more information (has been a little late yesterday): the problem started somewhere in the first three weeks of October. I do not have a more specific date, since I was on vacation on that time. It still persists in the current CVS version. The aircraft datafiles did not change, so it has to be somewhere in FlightGear or maybe SimGear code, but I have still too little experience to say more. Maybe I'll get to some more testing on the weekend. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Which aircraft to include in v0.9.9?
--- Erik Hofman [EMAIL PROTECTED] wrote: data/Aircraft/c172p \ data/Aircraft/c310 \ data/Aircraft/c310u3a \ I would switch the c310 for the Citation or B1900d I agree - the c310u3A is much nicer. data/Aircraft/wrightFlyer1903 \ I'd be tempted to ditch this one - new users are unlikely to (be able to) fly it. BTW Curt, could you publish the final list once you've decided? If there is enough time, I'd like to include a paragraph or two on each of the planes in the Getting Started Guide. -Stuart ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Which aircraft to include in v0.9.9?
3). J3 - The J3-Cub is complete (not much to cubs anyway) and easy to fly for someone just starting out. A real life Cub has a ball slip/skid indicator (just like in a turn coordinator), and a wire sticking out of the fuel cap in front, showing the fuel level. Other than that, it's pretty complete indeed. (Well, except that maybe real life Cubs are so much harder to start up...) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Which aircraft to include in v0.9.9?
On Wednesday 09 November 2005 19:31, Curtis L. Olson wrote: 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 ... (?) b1900d is my favourite plane, as it flies very well, has decent sound and a really good cockpit. And even the propeller blade pitch is animated i would ditch either the wright flyer, c310, ufo, c172 or Hunter in favor of b1900d. but i don't expect you to agree with me in all respects. thorben ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Which aircraft to include in v0.9.9?
Erik Hofman wrote: Curtis L. Olson wrote: 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 \ This is a nice selection [...] I support Erik's proposal as-is, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] [BUG] tmp-ly disable buggy mag compass jamming code
Thanks for applying the patch to the current code. I wonder what the jamming logic should be instead. Maybe check whether the angle between the cockpit Y axis and the resultant force presently acting on the plane is within some limit? I have no problem checking the angle above (based on the 3 /accelerations/pilot/[xyz]-accel-fps_sec properties); the question is, how do I get a realistic threshold value for jamming? (I don't remember any jamming from my real life flights anyway). Also, in a Cessna one can swivel the compass around the lateral axis; does it happen on other planes where it is installed? Do we want to model that? (that is just smth for future development) V. ___ 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
Vivian Meazza wrote: I only mention this because it indicates that the quality of our testing might not be quite as good as it should be as we move rapidly towards 1.0 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. Regards, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Which aircraft to include in v0.9.9?
On Thu, 2005-11-10 at 10:34 +, Thorben wrote: On Wednesday 09 November 2005 19:31, Curtis L. Olson wrote: 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 ... (?) b1900d is my favourite plane, as it flies very well, has decent sound and a really good cockpit. And even the propeller blade pitch is animated i would ditch either the wright flyer, c310, ufo, c172 or Hunter in favor of b1900d. but i don't expect you to agree with me in all respects. thorben I second adding the b1900d for the above reasons. Drop the ufo as fun as it is for testing purposes it has no cockpit, and can't be verified as to the realism of the flight model. Just my opinion. The Wright Flyer could also be dropped as it's not really flyable (IMO). George Patterson ___ 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 Guess why the next release is 0.9.9 and not 1.0 and why 1.0 is released early next year? 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. Well, pointing to bugs might be useful when there are enough developers to fix them. It is just recently that we have enough developers who are willing to fix bugs. Erik ___ 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
Erik Hofman wrote: Martin Spott wrote: RANTWe know exactly this phenomenon for several years now and to my [...] supporters for this idea./RANT Guess why the next release is 0.9.9 and not 1.0 and why 1.0 is released early next year? Yep, but sipmly _delaying_ the next release doesn't cure anything. This only makes sense if the developers agree on a feature freeze and announce a bugfix-only phase. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Which aircraft to include in v0.9.9?
Melchior FRANZ wrote: It's not the UFO that's superfluous, but the discussion about its removal. I wouldn't even list it as an aircraft that's up for discussion. Sheesh. Good point. I would drop it from the aircraft list, but not from distribution. It's no real aircraft and doesn't use real space, so no point in blocking another aircraft for it. Generally I'd say the most developed aircrafts should be included. It's all about first impression here, as everyone can download additional aircrafts without much hassle. The first impression should just be as good as possible, so the included collection should show as much of FlightGear as possible. There's no use in being technically perfekt and having thousands of features if the users won't see it. My two cents... Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] uneven brakes mystery resolved
On Wed, 9 Nov 2005, Andy Ross wrote: Something odd is going on -- apparently some other stick's binding for the right brake only is being picked up by your configuration. Have you modified the name properties of any of you joysticks files? Can you verify that your base package is unmodified? It wasn't unmodified of course -- have/had to explicitly specify which joystick I'm using, since FG is not/wasn't identifying it automatically for me -- maybe had something to do with my USB setup, but I've used that file modified like that for a long time. Perhaps the automatic identification works too, if my USB setup is correct nowadays. I found the cause in my joystick.xml: I had both the default generic joystick as well as the saitek numbered as js[0]. %-/ (only one physical js attached) Works like charm now! But I still think that buttons which use intepolate() shouldn't be marked as repeating, and the time in the interpolate call then should be larger than 75 milliseconds. (One second or half a second maybe. Should depend on the aircraft in question, I think. But I don't know how real pilots use the brakes when landing heavy aircrafts or jetfighters.) When the button is marked as repeating, the first cycle is an interpolation from 0 to 1 in 75 ms, but before the 75ms is ended, another call to interpolate() is made from whatever the value has reached, to 1.0, and then another interpolate() etc. This yields a sort of asymptotic curve. Doesn't make sense to me. Code from Saitek has been copied to other joystick files, so it's the same for several other joysticks. I'm not even sure if the joystick config files is the right place to define how brakes are used, i.e. how fast the pilot apply full or fully release the brakes. It could at least be moved to a wrapper function in Nasal/control.nas so we don't have to repeat the same code and constants in numerous js config files. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] fgfs --version
On Thu, 10 Nov 2005, George Patterson wrote: To find out which copy is being loaded when you type fgfs, open up a terminal and type which fgfs and you should get something like /usr/local/bin/fgfs. I meant version as in version number. Perhaps a command line parameter could be added to display the version of the binary and the version of the fg_root data. It has become a standard for GNU applications to have a --version command line option by which the application only prints version number, compile options etc to stdout and exits; useful information to include in bug reports... ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Which aircraft to include in v0.9.9?
Oh, and before the first points me to --fdm=ufo: I know that, of course. --fdm=ufo and --fdm=magic can be used with any aircraft. This is actually very useful for getting acquainted with how nav/ils instruments work. But this is only settable from the command line, but not from fgrun, where you *need* to choose an aircraft. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Which aircraft to include in v0.9.9?
On 9 Nov 2005, at 19:31, Curtis L. Olson wrote: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... De-lurking for a moment,I recall the original intention was to include at least one aircraft from each common category (single, light twin, heavy twin, bizjet, etc). The new criteria seems to be features / polish / completion - I'm not arguing which criteria makes more sense for a 0.9.9 or 1.0 release, but that's why the c310 is in, as I understand it - in the absence of a Baron or Diamond TwinStar, it's the only light twin that really exists with a model and cockpit. It's had very little love, and the default skin has been the military variant, which a few people have objected too in the past.If the argument about 'covering the categories' still holds, then replacing the c310 with b1900d is moot - for sure the b1900 should go in, because it's polished and slick, but it's a totally different class of aircraft (replacing the DC-3 with the b1900d would be more equivalent, but there are other reasons the DC3 is nice)Anyway, I guess all I'm really saying is, it sounds as if the criteria for inclusion have shifted changed, and that's fine, but it might put the existing aircraft selection from 0.9.8 in a new perspective.JamesPS - any time someone wants to do the TwinStar, I am prepared to offer all kinds of bribery! Cash, beer, you name it! -- Morbo finds all humans pathetic ___ 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] 737 nosewheel animations
Stefan Seifert wrote: Hi, attached are two small patches for giving the 737 nosewheel some animations. Namely it rotates when steering and compresses on breaking. For the latter I attached a one line patch that let's JSBsim expose compression-norm to the property tree just like YaSim. I don't know if this is in any way correct, but it gives some plausible movement visually. Now if there were some skid sounds you could get an impression how such a large plane feels like on the ground ;) It looks to be the right approach. I've committed this patch, along with new animations for bot main gear struts. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Which aircraft to include in v0.9.9?
Stefan Seifert writes Innis Cunningham wrote: I do a lot of my model testing on a 9.4 copy of FG and the engine sound is working just fine there.I will check out the 737 in 9.8 today and see if I can get to the bottom of it Sorry, should have given some more information (has been a little late yesterday): the problem started somewhere in the first three weeks of October. I do not have a more specific date, since I was on vacation on that time. It still persists in the current CVS version. The aircraft datafiles did not change, so it has to be somewhere in FlightGear or maybe SimGear code, but I have still too little experience to say more. Maybe I'll get to some more testing on the weekend. Have checked my sound on the release version of 9.8 on both Win 98 and Mandrake linux 10.0(duel boot box) and the sound seems to work fine on both systems. Nine Cheers Innis ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] 737 nosewheel animations
Hi, attached are two small patches for giving the 737 nosewheel some animations. Namely it rotates when steering and compresses on breaking. For the latter I attached a one line patch that let's JSBsim expose compression-norm to the property tree just like YaSim. I don't know if this is in any way correct, but it gives some plausible movement visually. Now if there were some skid sounds you could get an impression how such a large plane feels like on the ground ;) Nine I've got these slated to go into the new JSBSim code, as well. I hope to implement the changes today. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cessna 182 and 3D Instruments Update
Buchanan, Stuart wrote: Hi All, I've updated the Cessna 182 as follows. Great, we have a new c182 maintainer. - New Skylane textures to replace the old ones (which said Skyhawk on the side!) - Re-upholstered interior :) - Improved 3D cockpit with new - yokes - engine controls - throttle, propeller, mixture - flaps - seats - Updated help - KAP140 autopilot (though the altitude hold currently doesn't work) - Renamed files from c172 to c182 - Updated help with information from the readme It's committed. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Persistant Nasal big-endian bug
Andy Ross wrote: Erik Hofman wrote: Ok, I've test compiled the simgear/nasal library using gcc on IRIX and linked it with the MIPSpro build version of FlightGear and it's working like a charm. Now remains the question, is it an exploited gcc bug/feature or is it really a MIPSpro bug? I've personally built and tested it using the Sun Studio compiler on Sparc, and the windows builds are done using MSVC. That proves nothing, of course, but if code were a democracy MIPSpro would be losing 3:1. :) Yeah, the only reason (if it isn't a bug) would be because I know for certain that MIPSpro doesn't initialize pointers to NULL. I don't know about other compilers. Note that the naRef structure is a nested union, and the code makes heavy use of structure assignment of these things. That's not a common idiom (most other interpreters just use casts), so I wouldn't be shocked if it triggered a bug or two. There's one spot in there already (I forget who found it -- not me, anyway) with a workaround for a gcc 2.95 code generation bug. If you want to continue tracking this down, you could try starting with a gcc library, and replace each .o file in turn with a MIPSpro one to figure out where the faulty code generation is (it might be more than one location, of course), then start moving code out symbol-by-symbol until you zero in on the location. Then we can try to rewrite it so it compiles correctly. I plan on doing so, but not before the official 0.9.9 release. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: Which aircraft to include in v0.9.9?
Melchior FRANZ writes It is beyond me why nobody seems to understand the purpose of the UFO. It was never meant to be a serious aircraft. It is the scenery exploration tool. It doesn't need to have a cockpit or a realistic FDM. It uses up 76 kB uncompressed, and 10.8 kB compressed! Even the NEWS file is 23 kB big -- compressed! - it is fun to fly, maybe the only thing that (younger) children can really enjoy fgfs with (apart from santa, of course) - it is very helpful for exploring the scenery; this may even motivate people to populate the scenery with buildings, and to commit them and other things - it is useful for making scenery screenshots (unlike santa) - heck, it only uses 10.8 kB (ten point eight kilo-bytes!) It's not the UFO that's superfluous, but the discussion about its removal. I wouldn't even list it as an aircraft that's up for discussion. Sheesh. m. I agree with Melchior on this.I found it very usefull when I was playing around with the AI for Durk awhile back.But seeing I have about 15 copies of it it wouldn't bother me. Cheers Innis ___ 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 [EMAIL PROTECTED] wrote: I'm clever enough to realize that my idea of quality control is not necessary the best one for FG ;-)) I simply want to point out that the project is very well advised to have better quality control than it had for the past years. I have one or two ideas how this could be achieved, I'm convinced that others have other and probably better ideas and I'd like to see an open discussion on this. OK, here's my tuppence. I'd be much more likely to test a pre-release if it was available as a binary. While I (eventually) managed to get FG CVS to compile under cygwin, many new or non-dev users will be using the windows/Linux binaries directly, so it makes sense to test them and pick up the OS-specific issues, of which there are probably quite a few. Of course, creating a full windows install is presumably a lot of work and not practical for 0.9.9. For the big v1.0, which presumably is going to be quite high visibility as an OSS project going to a full release, I think it is something we should seriously look at doing. Having just finished a release cycle in my day job, you can imagine how enthusiastic I am about doing more testing ;), but I'll definitely try. -Stuart ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com ___ 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
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. -Stuart ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com ___ 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] Pending v0.9.9 release
Buchanan, Stuart wrote: 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. This clause should be removed - I remember it's in there, but currently I don't find it ah, there it is Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Bus error SimGear XML Parser - 0.9.9-pre2
Here's the output when I try to run fgfs 0.9.9-pre2 with SimGear 0.3.9-pre2 and 0.9.9-pre2 base package.Using Mac OS X hack for initializing C++ stdio...Error reading properties: Failed to open fileat .//data/cloudlayers.xml (reported by SimGear XML Parser)Bus errorAnd of course there's no cloudlayers.xml file.-- Arthur/ ___ 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: Here's the output when I try to run fgfs 0.9.9-pre2 with SimGear 0.3.9-pre2 and 0.9.9-pre2 base package. Using Mac OS X hack for initializing C++ stdio... Error reading properties: Failed to open file at .//data/cloudlayers.xml (reported by SimGear XML Parser) Bus error And of course there's no cloudlayers.xml file. It should be right there in the root of the base package. Did you upgrade the base package to the CVS version? Erik ___ 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
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.On 11/10/05, Erik Hofman [EMAIL PROTECTED] wrote:Arthur Wiebe wrote: Here's the output when I try to run fgfs 0.9.9-pre2 with SimGear 0.3.9-pre2 and 0.9.9-pre2 base package. Using Mac OS X hack for initializing C++ stdio... Error reading properties: Failed to open fileat .//data/cloudlayers.xml(reported by SimGear XML Parser) Bus error And of course there's no cloudlayers.xml file.It should be right there in the root of the base package. Did you upgrade the base package to the CVS version?Erik___Flightgear-devel mailing listFlightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel2f585eeea02e2c79d7b1d8c4963bae2d -- Arthur/- http://sourceforge.net/users/artooro/- http://artooro.blogspot.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/c182 c182-set.xml, 1.6,
Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/c182 In directory baron:/tmp/cvs-serv2788 Modified Files: c182-set.xml 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, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ 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
[Flightgear-devel] UFO - non-discussion
Melchior FRANZ writes It is beyond me why nobody seems to understand the purpose of the UFO. It was never meant to be a serious aircraft. It is the scenery exploration tool. It doesn't need to have a cockpit or a realistic FDM. It uses up 76 kB uncompressed, and 10.8 kB compressed! Even the NEWS file is 23 kB big -- compressed! I agree with all of that ... and it should continue in that role. Innis: I agree with Melchior on this.I found it very usefull when I was playing around with the AI for Durk awhile back. That too. Maybe a change of name (from UFO) may reduce confusion? Now, should someone try to create an interior looking like a classic UFO (with a funky control panel, LGM passengers, a radio panel that works but looks like it was built from alien lab equipment by alien scientists in order to communicate with human ATC services, etc etc) then I personally would love to see that included in the FGFS model. But ... maybe as an external download ... because it'll be fairly big. ___ 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: 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. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ 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 [EMAIL PROTECTED] 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, Have you synced Instruments-3d ? The new C182 model requires the new yoke, flaps and trimwheel that I submitted at the same time. I assume they were all checked in at the same time. -Stuart ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear v0.9.9-pre2
On Wed, 2005-11-09 at 19:46, Curtis L. Olson wrote: 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) Folks: I just built 0.9.9.pre2 as an RPM for Fedora Core on i386 class machines. I did this months ago with 0.9.8 too, and it worked fine. However, I'm getting a core dump off fgfs almost immediately at start-up. It won't even get as far as fgfs --help. The latter few lines of strace fgfs look like this: open(/usr/share/FlightGear/data/preferences.xml, O_RDONLY) = 3 open(/usr/share/FlightGear/data/Translations/locale.xml, O_RDONLY) = 4close(4)= 0 open(/usr/share/FlightGear/data/gui/menubar.xml, O_RDONLY) = 4 close(4)= 0 open(/usr/share/FlightGear/data/gui/styles/default.xml, O_RDONLY) = 4 close(4)= 0 open(/usr/share/FlightGear/data/gui/styles/anthrax.xml, O_RDONLY) = 4 close(4)= 0 open(/usr/share/FlightGear/data/cloudlayers.xml, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/share/FlightGear/data/keyboard.xml, O_RDONLY) = 4 close(4)= 0 open(/usr/share/FlightGear/data/mice.xml, O_RDONLY) = 4 close(4)= 0 close(3)= 0 munmap(0xb0913000, 4096)= 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ ( I indented it by hand to make it a bit more obvious what 'close' belongs with which 'open' ) Seems like the program closes /usr/share/FlightGear/data/preferences.xml and immediately crashes. I've not got any scenery loaded apart from the default couple of tiles around KSFO. I removed my 0.9.8 .rc files and anything else I could find that looked like hangovers from 0.9.8 just in case. No effect. This was compiled on Fedora Core 2 with the gcc 3.3.3-7 standard compiler. All worked fine for 0.9.8 as I said. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear v0.9.9-pre2
On Thursday 10 November 2005 17:02, Steve Hosgood wrote: The latter few lines of strace fgfs look like this: open(/usr/share/FlightGear/data/cloudlayers.xml, O_RDONLY) = -1 ENOENT (No such file or directory) I'm sure I saw an hour or so ago on this list that this file was mistakenly omitted from the release? If it's not there, grabbing it from CVS and trying to run fgfs again would be my first step. AJ ___ 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,
Buchanan, Stuart wrote: Have you synced Instruments-3d ? The new C182 model requires the new yoke, flaps and trimwheel that I submitted at the same time. I assume they were all checked in at the same time. Oops, they hadn't. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Strange colors in spash screen
http://artooro.spymac.com/pub/fg_spash_screen.pngThis is a screenshot of some very interesting colors I get in the splash screen when launching FlightGear 0.9.9-pre2.Any idea what could be wrong? It all works fine once everything has been initiated. -- Arthur/- http://sourceforge.net/users/artooro/- http://artooro.blogspot.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Freeglut on SuSE 10.0
On Thu, 10 Nov 2005 02:20:42 -0600, you wrote: You are using a buggy freeglut version (2.4). Upgrade to a current CVS version, or downgrade to 2.2, they work fine. Where and how do I install 2.2 on SuSE? I tried adding a local folder to Yast as a source of RPM packages. It said okay, click here to add as RPM source. But only 2.4 shows up in package list. I tried a suggestion on the SuSE forums to issue an yast -i package.rpm command, but nothing seemed to happen. No error, nothing was added to my Yast config as far as I can tell. I am uncomfortable (prefer to let Yast handle it) issuing an rpm command, but perhaps I should try that? Thanks, Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Freeglut on SuSE 10.0
Steve Knoblock wrote: I tried a suggestion on the SuSE forums to issue an yast -i package.rpm command, but nothing seemed to happen. No error, nothing was added to my Yast config as far as I can tell. I am uncomfortable (prefer to let Yast handle it) issuing an rpm command, but perhaps I should try that? You should definitely try it. Just issue rpm -Uvh --oldpackage freeglut-2.2.0-83.i586.rpm The options mean: -U upgrade an existing package -v verbose -h print a nice progress bar while installing --oldpackage install even if it is an older package Using yast will not work, because you are actually downgrading, which is something normally only users do, that are already comfortable with the system and know what they are doing. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear v0.9.9-pre2
Aside from the already mentioned glitch about the missing cloudlayers.xml file, I was able to build 0.9.9-pre2 without any problems on my linux box. I am getting some extraneous console output, which perhaps needs to be cleaned up. (This is using the default log level, running the T-38 from command line script). [EMAIL PROTECTED] bin]$ t38 Dent: .Dent: ..Dent: EHAMopening file: /home/dave/FlightGear-0.9.9-pre2/data/Navaids/carrier_nav.dat /home/dave/FlightGear-0.9.9-pre2/data/Navaids/TACAN_freq.dat WARNING: ssgLoadAC: Failed to open '/home/dave/FlightGear-0.9.9-pre2/data/Aircraft/c172r/Models/c172-dpm.ac' for reading Reading xml electrical system model from /home/dave/FlightGear-0.9.9-pre2/data/Aircraft/Generic/generic-electrical.xml Initialising callsign using 'Aircraft/T38/Models/T38-model.xml' Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Freeglut on SuSE 10.0
Or just rpm -e --nodeps freeglut rpm -ihv /path/freeglut-2.2-xxx.rpm Ladislav. 2005/11/10, Stefan Seifert [EMAIL PROTECTED]: Steve Knoblock wrote: I tried a suggestion on the SuSE forums to issue an yast -i package.rpm command, but nothing seemed to happen. No error, nothing was added to my Yast config as far as I can tell. I am uncomfortable (prefer to let Yast handle it) issuing an rpm command, but perhaps I should try that? You should definitely try it. Just issue rpm -Uvh --oldpackage freeglut-2.2.0-83.i586.rpm The options mean: -U upgrade an existing package -v verbose -h print a nice progress bar while installing --oldpackage install even if it is an older package Using yast will not work, because you are actually downgrading, which is something normally only users do, that are already comfortable with the system and know what they are doing. Nine ___ 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
[Flightgear-devel] runfgfs
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? -Stuart ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com ___ 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] Citation pitch down divergence. Fixed?
After some prodding from Curt, I finally spent a few hours yesterday tracking down the pitch down discontinuity in the Citation. Well, I didn't find a discontinuity. I can now graph the lift curve from a Surface (a real one, part of the real aircraft, not an isolated test instance) and verify that it's valid and correct looking through the entire AoA regime. But I think I *did* find the problem: it seems that I, er, misdocumented the incidence and twist parameters in the YASim configuration. The README.yasim file states that these numbers are positive for positive AoA (i.e. a positive incidence on a wing generates extra lift, and a negative twist causes the wing tips to stall after the root). But the code was interpreting the number as a rotation about the YASim Y axis, which points out the left wing and therefore is positive *down*. Oops. The reason the citation exhibited this especially is just luck: the file lists an incidence of 3.0 (which is relatively high, and the inversion bug therefore puts the wing 3 degrees closer to a negative stall) the solver happens to generate a nose-down cruise configuration of about 1.5 degrees, and the elevator authority is actually quite high (which causes higher pitch rates under autopilot control). So the bottom line is that Curt was right: it *was* the negative AoA stall (probably the tail's, not the wing's) happening too soon. :) I'm a little leery of changing this in code this close to a release -- the risk of breaking working aircraft is too high. For the short term, this can be fixed in the Citation-II.xml file by simply negating the incidence and twist values on the wing. I did this and tried the autopilot in a maximum speed cruise at low level (which should produce the highest nose-down AoA) without any odd behavior. Curt, can you try that and see if it appears to fix the handling issues? Likewise, anyone with a YASim aircraft that makes use of incidence or twist values is encouraged to try the same modification and report any problems. We can go back after the release and fix the code and all the aircraft files. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Re: [Flightgear-devel] Which aircraft to include in v0.9.9?
On Wed, 09 Nov 2005 14:55:35 -0600, you wrote: I think, especially in view of the spate of posts a short while ago, it would be wise to only include (by default) aircraft which are quite complete - i.e. with populated cockpits etc. People who know what they want and what they're doing can easily download the others. It would be very helpful, and good public relations for aircraft included by default to be complete and flyable. My first impression of FlightGear on Windows was soured by the first aircraft I choose. It was the Cessna with full IFR panel. The panel was upside down and very strange. It didn't make a good first impression and left me confused. If I had not been persistent I might have gave up on it right there. Moreover, I could not figure out why there were so many Cessna's and what the differences were. An aircraft should be operational, not in a state of development if it is to be included in the official distribution. Aircraft in development can be downloaded individually. Aircraft should not be incomplete, missing panels, incomplete instruments, etc. I realize this is not easy given the open source and experimental nature of Flight Gear development. I agree with the idea of removing the UFO in favor of a more useful and complete aircraft. There are several aircraft in the collection I would prefer being in the default set over the UFO craft. However, there should be some note to developers that this is useful to download for use in scenery development. I may have overlooked it, but as far as I can tell, there is no slew mode available in FG, which makes it difficult to position a normal aircraft so you can check scenery when developing buildings, airports, etc. If the UFO is the only way to emulate slewing, then perhaps it should be retained. I would like to retain the Wright Flyer to represent aviation history. I think everyone new to flight sim wonders what it would be like to fly the Wright Flyer. However, I found it unflyable, so in the end I think it should be replaced by a more flyable aircraft. Aircraft without a 3D model should be avoided in the default distribution (No FDM only). The J3 Cub is attractively modeled and shows off what can be done with Flight Gear aircraft. It is also an easy to fly, good introductory aircraft. I decided I should ask myself, is there an aircraft now in the collection that I would prefer over one in the default? Here's my list. 737 (Boeing 737) --- Keep. A-10 (Fairchild A-10) --- Replace with Spitfire (hate to do it, but makes sense). bo105 (Helicopter) --- Keep. c172 (Cessna) --- Replace with updated Cessna 182. c172p (Cessna) --- Keep. c310 (Cessna 310) --- Replace with B1900D. c310u3a (Cessna 310) --- Keep. Citation (Citation II) --- Keep. f16 (F-16) --- Keep j3cub (J3 Cub) --- Keep. hunter (Hawker Hunter) --- Keep p51d (Mustang P-51D) --- Keep. pa38-161 (Piper Warrior) --- Keep. ufo (developer) --- Replace with PC-7. wright flyer (Wright Flyer) --- Replace with DH Beaver. It is difficult to decide when trying to fill out the categories when the best aircraft do not fall evenly into those categories. Aircraft in one category may be more complete and polished than aircraft in others. One could argue there is a place for at least one glider and one bi-plane in the default collection. If there are no glider specific areas with thermals, then I suggest leaving the glider out until more glider support is available. The only bi-plane is the Sopwith, so perhaps that can wait. Arguably, there should be a representative jet fighter aircraft, one American and one European, but if it takes away room for a general aviation, etc. perhaps only one jet fighter should be represented. And the same might be said for second world war aircraft. The P-51D and Spitfire as easy choices, since they are good models. The F16 is probably the best choice for an American jet fighter. The Hunter seems easy to fly. The same policy could be for commercial airliners. With the Boeing 737 and the Airbus A320 each being represented. At least one helicopter should be available, but if it is unflyable, I'd say replace it with something else. I think it's important to keep the most widely used general aviation craft, like Cessna and Piper and one or two major historic aircraft, such as the Cub, DC3. The Comper Swift is in the same vein as the J3, but in beta status. At least one aircraft from the early era of general aviation should be in the default package. Most users will want a light single engine general aviation aircraft they are familiar with. The Cessna fills this niche and is the most popular. I suggest one classic and one modern Cessna single. The Beaver is one of my favorite aircraft. It is both from the era I find interesting and capable of bush flying. It is slow and fairly easy to fly and can operate on water or land. A good model, if not the most refined, but lacking in hot spots on 3d cockpit controls. The Piper Warrior fills the need for a fast
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Curtis L. Olson wrote: 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? Works perfectly now - as far as I can tell from a short test, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announcement: First TerraGear
Curt, Curtis L. Olson wrote: 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. Thank you very much for this commitment. I think we should develop new analytical methods for exploring human brain efficiency basing on your current head-spin experience ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] nimitz despeckle
can somebody with cvs access please run ac3d-despeckle on nimitz.ac and commit the fixed version? i have one of those older nvidia cards and the flicker is annoying. i can confirm that running ac3d-despeckle fixes the flickering. thanks. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear v0.9.9-pre2
Steve Hosgood schrieb: Seems like the program closes /usr/share/FlightGear/data/preferences.xml and immediately crashes. Hi Steve, I had the same problem today after compiling new SimGear/FlightGear CVS. Although I had downloaded FlightGear CVS data with cvs update -d -P I got the message that preferences.xml could not be read by SimGear XML Browser line 1 column 1 and the program terminated. Same after I deleted Line 1, another XML brower error message came up. This was not really professional but easy (in my job I am trained to follow the KISS principle keep it simple, stupid) - I renamend the data folder and made a complete new download of all FlightGear data - and it worked afterwards. After my opinion it has something to do with an old preferences.xml file (I changed the AI entries to have the carrier and other ai) which could not be read anymore with the new CVS code. But please - I am a FlightGear newbie, this is just my 2 c to try to help you as the problem seems to be similar. Regards Georg ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Which aircraft to include in v0.9.9?
Steve Knoblock schrieb: My first impression of FlightGear on Windows was soured by the first aircraft I choose. It was the Cessna with full IFR panel. The panel was upside down and very strange. It didn't make a good first impression and left me confused. If I had not been persistent I might have gave up on it right there. I remember this very clear, I was the same when I tried V0.9.8! Moreover, I could not figure out why there were so many Cessna's and what the differences were. An aircraft should be operational, not in a state of development if it is to be included in the official distribution. Aircraft in development can be downloaded individually. Aircraft should not be incomplete, missing panels, incomplete instruments, etc. I realize this is not easy given the open source and experimental nature of Flight Gear development. There was a review/test of FlightGear in linux user, November 2005, a very popular German linux magazin. Although they gave FlightGear 4 full pages, scenery on their cover CD and a lot of very usable hints aimed to flightsim beginners they complained about missing panels, missing instruments, missing Transponder (and a lot of other things like bad flightmodel ((due to missing stall characteristics)), missing structural damage, missing red and white-blackout, missing higher-level ATC, missing colleason detection ((they might have proved it with the ... objects)). Their last recommendation was not what we would like to see and we could say simply ignore it but a *lot* of linux user are reading this magazin and potentially flightsim interested people get the wrong impression by this review. :-( This means for me - an official release is always some PR for the FlightGear project and the chance to get some people interested, might be even starting some user development (small projects) or to loose them before they have had the chance to see what FlightGear can offer today! And after my opinion there is a need for people who do some work outside the core development - make some more nice generic models for FG that can be used for scenery design, improve airports, make repaints, even do 3D aircraft modelling. This was the typical work sharing what I experienced when I was active for another flightsim (FLY! II). And even core developers may like it to fly a nice little scenery a pure user was able to create. To be honest, also some *easy* tools are lacking now to enable pure users to do such work without too much knowledge about the internal FlightGear stuff. Just a dream for the future :-) I agree with the idea of removing the UFO in favor of a more useful and complete aircraft. .. I think it's important to keep the most widely used general aviation craft, like Cessna and Piper .. Most users will want a light single engine general aviation aircraft they are familiar with. The Cessna fills this niche and is the most popular. I suggest one classic and one modern Cessna single. Of course the linux user magazine used the Cessna *172* to make the first testflights and (very clever!) they recommended the *ufo* to get familiar with the main functions of FlightGear when the reader had no knowledge of flightsims before taking off with the Cessna (what they described step for step in a really professional manner). So, after having said all this, my opinion is only to add very complete (3D, panel, flightmodel) aircraft to the new release. Interested people can download, it is very easy. Regards Georg ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] waypoints, waypoint loops, route manger
On Wednesday 09 Nov 2005 22:02, Craig E. Staples wrote: Hello all, I'm trying certain senarios via waypoints and varying altitudes by using flightplan/.fgfsrc file. I plan on implementing a data input change for route manger code to read a file with my data, but in the mean time I was wondering if there's a reason why [EMAIL PROTECTED] has issues maintaining the wanted altitude. I have alts at 15k, but the craft drifts to 20 k, etc... I also want to maintain a senario for a certain amount of time, so go to waypoint 1 and 2 looping for 10 mins, etc... then hit waypoints 3, 4 and 5... If anyone has a better way to approach this please give me ur ideas. Thanks a lot.. Regards, Craig E. I don't know the straight answer to this problem but there are a couple of factors that need to be considered in using flightplan data, like the [EMAIL PROTECTED] info in a flightplan file, or supplied on the console/termninal at start-up. The first is that if you want any altitude hold there will have to be a controller, or more likely a cascade of controllers set up in the autopilot to do it. The reference or target altitude that the autopilot altitude controller tries to achieve needs to be available in the property tree, so that it can read it. If the altitudes supplied in the flightplan aren't transferred to the right place in the property tree then the a/p controllers can't use them. The second factor is that just setting a target altitude will not mean that an a/c will fly properly to that altitude. Climbing to a new, higher altitude that's a lot different to the current altitude isn't a simple matter and must be done at the correct speed and may need to be done in steps. The fuel state and payload will also have a great influence on how the climb is achieved. I guess a simple list of [EMAIL PROTECTED] waypoints is inadequate because it lacks the climb info/requirements. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] wp altitudes
Yeah...It appears as if autopilot is not getting the altitude info from [EMAIL PROTECTED] The autopilot altitude value stays at it's default 5k and doesn't budge. The only way to set this alt is manually through the ap gui. Any quick fixes would be appreciated... Does the telnet or GPS system work as well? I see the --garmin=params option... I found the garmin protocol, but it appears as if the protocol needs to be in xml format, is this correct? Thanks for you input... Craig E. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curtis L. Olson Sent: Wednesday, November 09, 2005 2:12 PM To: FlightGear developers discussions Subject: 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 mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange colors in spash screen
On Thursday 10 Nov 2005 18:01, Arthur Wiebe wrote: http://artooro.spymac.com/pub/fg_spash_screen.png This is a screenshot of some very interesting colors I get in the splash screen when launching FlightGear 0.9.9-pre2. Any idea what could be wrong? It all works fine once everything has been initiated. -- Arthur/ - http://sourceforge.net/users/artooro/ - http://artooro.blogspot.com That looks like a corrupted splash screen image. Does it happen with all the aircraft you've tried? Some aircraft have their own splash image but those that don't get one of the default splash images. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] waypoints, waypoint loops, route manger
The flightplan works great with regard to waypoints, but I have to manually insert an altitude in gui ap. This works great and stable too... It just leads me to believe that the property tree is messed up somewhere. Is coding the only correction here or can something be done via xml file or even a nasal bind (new to nasal, but it seems like it has something useful to my plight) Thanks for your efforts... Craig E. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lee Elliott Sent: Thursday, November 10, 2005 7:53 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] waypoints, waypoint loops, route manger On Wednesday 09 Nov 2005 22:02, Craig E. Staples wrote: Hello all, I'm trying certain senarios via waypoints and varying altitudes by using flightplan/.fgfsrc file. I plan on implementing a data input change for route manger code to read a file with my data, but in the mean time I was wondering if there's a reason why [EMAIL PROTECTED] has issues maintaining the wanted altitude. I have alts at 15k, but the craft drifts to 20 k, etc... I also want to maintain a senario for a certain amount of time, so go to waypoint 1 and 2 looping for 10 mins, etc... then hit waypoints 3, 4 and 5... If anyone has a better way to approach this please give me ur ideas. Thanks a lot.. Regards, Craig E. I don't know the straight answer to this problem but there are a couple of factors that need to be considered in using flightplan data, like the [EMAIL PROTECTED] info in a flightplan file, or supplied on the console/termninal at start-up. The first is that if you want any altitude hold there will have to be a controller, or more likely a cascade of controllers set up in the autopilot to do it. The reference or target altitude that the autopilot altitude controller tries to achieve needs to be available in the property tree, so that it can read it. If the altitudes supplied in the flightplan aren't transferred to the right place in the property tree then the a/p controllers can't use them. The second factor is that just setting a target altitude will not mean that an a/c will fly properly to that altitude. Climbing to a new, higher altitude that's a lot different to the current altitude isn't a simple matter and must be done at the correct speed and may need to be done in steps. The fuel state and payload will also have a great influence on how the climb is achieved. I guess a simple list of [EMAIL PROTECTED] waypoints is inadequate because it lacks the climb info/requirements. LeeE ___ 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
RE: [Flightgear-devel] waypoints, waypoint loops, route manger
The flightplan works great with regard to waypoints, but I have to manually insert an altitude in gui ap. This works great and stable too... It just leads me to believe that the property tree is messed up somewhere. Is coding the only correction here or can something be done via xml file or even a nasal bind (new to nasal, but it seems like it has something useful to my plight) Thanks for your efforts... Craig E. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lee Elliott Sent: Thursday, November 10, 2005 7:53 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] waypoints, waypoint loops, route manger On Wednesday 09 Nov 2005 22:02, Craig E. Staples wrote: Hello all, I'm trying certain senarios via waypoints and varying altitudes by using flightplan/.fgfsrc file. I plan on implementing a data input change for route manger code to read a file with my data, but in the mean time I was wondering if there's a reason why [EMAIL PROTECTED] has issues maintaining the wanted altitude. I have alts at 15k, but the craft drifts to 20 k, etc... I also want to maintain a senario for a certain amount of time, so go to waypoint 1 and 2 looping for 10 mins, etc... then hit waypoints 3, 4 and 5... If anyone has a better way to approach this please give me ur ideas. Thanks a lot.. Regards, Craig E. I don't know the straight answer to this problem but there are a couple of factors that need to be considered in using flightplan data, like the [EMAIL PROTECTED] info in a flightplan file, or supplied on the console/termninal at start-up. The first is that if you want any altitude hold there will have to be a controller, or more likely a cascade of controllers set up in the autopilot to do it. The reference or target altitude that the autopilot altitude controller tries to achieve needs to be available in the property tree, so that it can read it. If the altitudes supplied in the flightplan aren't transferred to the right place in the property tree then the a/p controllers can't use them. The second factor is that just setting a target altitude will not mean that an a/c will fly properly to that altitude. Climbing to a new, higher altitude that's a lot different to the current altitude isn't a simple matter and must be done at the correct speed and may need to be done in steps. The fuel state and payload will also have a great influence on how the climb is achieved. I guess a simple list of [EMAIL PROTECTED] waypoints is inadequate because it lacks the climb info/requirements. LeeE ___ 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
Re: [Flightgear-devel] Citation pitch down divergence. Fixed?
On Thursday 10 Nov 2005 20:20, Andy Ross wrote: After some prodding from Curt, I finally spent a few hours yesterday tracking down the pitch down discontinuity in the Citation. Well, I didn't find a discontinuity. I can now graph the lift curve from a Surface (a real one, part of the real aircraft, not an isolated test instance) and verify that it's valid and correct looking through the entire AoA regime. But I think I *did* find the problem: it seems that I, er, misdocumented the incidence and twist parameters in the YASim configuration. The README.yasim file states that these numbers are positive for positive AoA (i.e. a positive incidence on a wing generates extra lift, and a negative twist causes the wing tips to stall after the root). But the code was interpreting the number as a rotation about the YASim Y axis, which points out the left wing and therefore is positive *down*. Oops. The reason the citation exhibited this especially is just luck: the file lists an incidence of 3.0 (which is relatively high, and the inversion bug therefore puts the wing 3 degrees closer to a negative stall) the solver happens to generate a nose-down cruise configuration of about 1.5 degrees, and the elevator authority is actually quite high (which causes higher pitch rates under autopilot control). So the bottom line is that Curt was right: it *was* the negative AoA stall (probably the tail's, not the wing's) happening too soon. :) I'm a little leery of changing this in code this close to a release -- the risk of breaking working aircraft is too high. For the short term, this can be fixed in the Citation-II.xml file by simply negating the incidence and twist values on the wing. I did this and tried the autopilot in a maximum speed cruise at low level (which should produce the highest nose-down AoA) without any odd behavior. Curt, can you try that and see if it appears to fix the handling issues? Likewise, anyone with a YASim aircraft that makes use of incidence or twist values is encouraged to try the same modification and report any problems. We can go back after the release and fix the code and all the aircraft files. Andy I'll try to check the ones I've done over the weekend. The one that concerns me most is the B-52F. The wing incidence is set to 6 and the twist to -4 and I'm starting to wonder how it manages to fly at all. I got some good info on the B-52F from someone who flew around 3000 hrs in that model and around 6000 hrs total in all models, apart from the A/B, and it was flying to within around 10 kts or so of what it should have been doing and was climbing at about the right rate. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Citation pitch down divergence. Fixed?
Lee Elliott wrote: On Thursday 10 Nov 2005 20:20, Andy Ross wrote: After some prodding from Curt, I finally spent a few hours yesterday tracking down the pitch down discontinuity in the Citation. Well, I didn't find a discontinuity. I can now graph the lift curve from a Surface (a real one, part of the real aircraft, not an isolated test instance) and verify that it's valid and correct looking through the entire AoA regime. But I think I *did* find the problem: it seems that I, er, misdocumented the incidence and twist parameters in the YASim configuration. The README.yasim file states that these numbers are positive for positive AoA (i.e. a positive incidence on a wing generates extra lift, and a negative twist causes the wing tips to stall after the root). But the code was interpreting the number as a rotation about the YASim Y axis, which points out the left wing and therefore is positive *down*. Oops. The reason the citation exhibited this especially is just luck: the file lists an incidence of 3.0 (which is relatively high, and the inversion bug therefore puts the wing 3 degrees closer to a negative stall) the solver happens to generate a nose-down cruise configuration of about 1.5 degrees, and the elevator authority is actually quite high (which causes higher pitch rates under autopilot control). So the bottom line is that Curt was right: it *was* the negative AoA stall (probably the tail's, not the wing's) happening too soon. :) I'm a little leery of changing this in code this close to a release -- the risk of breaking working aircraft is too high. For the short term, this can be fixed in the Citation-II.xml file by simply negating the incidence and twist values on the wing. I did this and tried the autopilot in a maximum speed cruise at low level (which should produce the highest nose-down AoA) without any odd behavior. Curt, can you try that and see if it appears to fix the handling issues? Likewise, anyone with a YASim aircraft that makes use of incidence or twist values is encouraged to try the same modification and report any problems. We can go back after the release and fix the code and all the aircraft files. Andy I'll try to check the ones I've done over the weekend. The one that concerns me most is the B-52F. The wing incidence is set to 6 and the twist to -4 and I'm starting to wonder how it manages to fly at all. Nose down. The fuselage is about 5 deg down when in level flight. I got some good info on the B-52F from someone who flew around 3000 hrs in that model and around 6000 hrs total in all models, apart from the A/B, and it was flying to within around 10 kts or so of what it should have been doing and was climbing at about the right rate. LeeE ___ 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
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 31, Issue 42
On Thu, 10 Nov 2005 19:11:25 -0600, you wrote: Their last recommendation was not what we would like to see and we could say simply ignore it but a *lot* of linux user are reading this magazin and potentially flightsim interested people get the wrong impression by this review. :-( I remember what KDE was like a few years ago. I remember encountering incomplete help files with messages like sorry, have to spend more time with my girlfriend than help files. Understandable, but it is a hazard of Linux, even after all the development. SuSE is vastly improved from that time and I'm loving it, but there is always something. Steve ___ 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
