Re: Wheel skid sounds - Was: [Flightgear-devel] Re: Release of v0.9.9 source code
Josh Babcock wrote: No, I was responding based entirely on the e-mails. I did just take a peek, and it seems like a neat way of making the touchdown squeal if I am reading it right. What is the dt_stop section about though? dt_stop is the time in seconds after the sound has stopped, this is to prevent the skidsound to play again while the wheel is still spinning. If you can make squeals for over braking (locking the wheels) and ground loops without any modifications to the code, I will be interested in seeing it, and will definitely use it. This might be a good bit to include in the generic sound.xml file. First things first, there are a lot of things to do before I get to do this. Not to mention non FlightGear activities. Out of curiosity, do blowouts produce a squealing sound? I would think not, but I have never experienced one in a plane :) I don't think you really hear that much. I once saw a blowout during an airshow where the plane suddenly made a right turn into the grass after a blowout. I don't remember hearing anything at that time. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Release of v0.9.9 source code
Josh Babcock wrote: Won't the FDM have to tell the sound system when the wheels are skidding? You can figure out touchdown pretty easily, but not say, skidding from braking. The FDM already reveals when the brakes are applied in the property tree. One thing that still is missing (and I have a solution for the next JSBSim release) is a ground-speed property. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Wheel skid sounds - Was: [Flightgear-devel] Re: Release of v0.9.9 source code
Erik Hofman wrote: The FDM already reveals when the brakes are applied in the property tree. One thing that still is missing (and I have a solution for the next JSBSim release) is a ground-speed property. Yeah, but just putting them on doesn't make them skid (I hope). Hearing screeching wheels when you tap your brakes during a slow speed taxi would be a bit silly. You would need to know at least the force from the wheels and the coefficient of friction for the current conditions. The latter I suppose you could make a good educated guess at based on the weather. Ground speed is a very useful thing to have, especially on a by-wheel basis. It allows for very good looking wheel rolling animations during taxi turns. Andy put this into YASim a while back, and it makes the B29 wheels look just plain hot. (my only small complaint is that they don't spin down after takeoff, so if you forget to tap your brakes after takeoff, the wheels will still be spinning when you lower you gear for landing!) If the ground speed where to reflect the wheels locking up that would be even cooler, but it still won't tell you when the wheels are skidding sideways enough to cause a screech. This is something that you probably want if you are ever planning on doing a ground loop, and I tend to do a lot of those in FG ;) Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Wheel skid sounds - Was: [Flightgear-devel] Re: Release of v0.9.9 source code
Josh Babcock wrote: Erik Hofman wrote: The FDM already reveals when the brakes are applied in the property tree. One thing that still is missing (and I have a solution for the next JSBSim release) is a ground-speed property. Yeah, but just putting them on doesn't make them skid (I hope). Hearing screeching wheels when you tap your brakes during a slow speed taxi would be a bit silly. You would need to know at least the force from the wheels and the coefficient of friction for the current conditions. The latter I suppose you could make a good educated guess at based on the weather. So far I've done pretty well for touchdown skis sounds, I don't think ground loop squeels would be much more difficult. Did you take a look at the c172p-sound.xml configuration file already? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Wheel skid sounds - Was: [Flightgear-devel] Re: Release of v0.9.9 source code
Erik Hofman wrote: So far I've done pretty well for touchdown skis sounds, I don't think ground loop squeels would be much more difficult. Did you take a look at the c172p-sound.xml configuration file already? Erik Erik, No, I was responding based entirely on the e-mails. I did just take a peek, and it seems like a neat way of making the touchdown squeal if I am reading it right. What is the dt_stop section about though? If you can make squeals for over braking (locking the wheels) and ground loops without any modifications to the code, I will be interested in seeing it, and will definitely use it. This might be a good bit to include in the generic sound.xml file. Out of curiosity, do blowouts produce a squealing sound? I would think not, but I have never experienced one in a plane :) Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Release of v0.9.9 source code
* Melchior FRANZ -- Saturday 19 November 2005 14:11: One new feature *must* go in. Otherwise the 1.0.0 release number is IMHO not justified: * landing lights ... to make fgfs actually usable at night * aircraft switchable at runtime And here's another one: * save gui configuration: sound, shadows, etc. should all be saved into a configuration file that is loaded at each startup; Telling users to find(!) and edit XML stuff is very pre-1.0. (Could be done in gui.nas for now, where it's unlikely to cause stability problems.) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Release of v0.9.9 source code
* Erik Hofman -- Friday 18 November 2005 18:36: After this release we'll only accept bug-fixes to the code, except for the new JSBSim version. Any major code changes that are not intended to fix one or more bugs will have to wait. One new feature *must* go in. Otherwise the 1.0.0 release number is IMHO not justified: * landing lights Otherwise we'd have to admit that FlightGear 1.0.0 is a daylight-only simulator. A patch for landing lights is floating around on IRC. (Haven't tested it yet.) One new feature that I always thought should be possible in 1.0.0: * aircraft switchable at runtime This isn't something that we need, but something that every other simulator is capable of, and users expect it. Also it would be a good sign for clean subsystem design. And finally, this is my TODO list: * try to get rid of a few more hardcoded dialogs, or at least make them accept gui colors And if none of this is possible, then I'm afraid I don't have a TODO list and this will be the most boring release cycle ever. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: Release of v0.9.9 source code
And if none of this is possible, then I'm afraid I don't have a TODO list and this will be the most boring release cycle ever. m. Heh. Maybe. Maybe not. I hope that from your point of view it turns out to be a boring release cycle. In one respect, it should not be very noticeable to users what has happened, apart from the fact that none of the existing JSBSim aircraft, engines, or thrusters will work in their current form. They will have to be converted to the new JSBSim config file format. A conversion helper tool is available. For over a year myself and others have discussed refining the JSBSim config file format to a more well-formed design. I have also tried to consider what was done by the guys working on the AIAA standard for aircraft simulation model exchange, to be called AEROML (formerly known as DAVEML, see daveml.nasa.gov). As part of the config file format change, new capabilities were added. The version of JSBSim to be added to FlightGear developer CVS in the coming weeks will be a major change. I'll describe the new features in the JSBSim developer list soon. I'm also fixing up the comments in the code to reflect the new changes, and will be publishing a document on the new config file format, as well. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Release of v0.9.9 source code
I also hoped that a few Nasal improvements could be committed, such as file I/O. That's hardly dangerous for overall fgfs stability, and would allow to implement some nice features in Nasal scripts. (Not that this had to be in 1.0.0, but I wouldn't like to wait some months for it. :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Release of v0.9.9 source code
Melchior FRANZ wrote: * Erik Hofman -- Friday 18 November 2005 18:36: After this release we'll only accept bug-fixes to the code, except for the new JSBSim version. Any major code changes that are not intended to fix one or more bugs will have to wait. One new feature *must* go in. Otherwise the 1.0.0 release number is IMHO not justified: Another thing that's really missing (and was mentioned in the linux-user.de review) is handling of any cases other than normal flight. Redout and Blackout are a good start, but everything from structural failures to things like skid sounds if you turn too quick on ground is missing and makes FlightGear just feel unrealistic. You can just do what you want and the plane survives. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Release of v0.9.9 source code
Melchior FRANZ wrote: And finally, this is my TODO list: * try to get rid of a few more hardcoded dialogs, or at least make them accept gui colors Not that I explicitly stated no major updates to the *source* *code*. Removing code would be no problem (and neither would be putting an equivalent in the base package). Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Release of v0.9.9 source code
Stefan Seifert wrote: Another thing that's really missing (and was mentioned in the linux-user.de review) is handling of any cases other than normal flight. Redout and Blackout are a good start, but everything from structural failures to things like skid sounds if you turn too quick on ground is missing and makes FlightGear just feel unrealistic. You can just do what you want and the plane survives. Skid sounds it just a sound configuration file update. Patches are welcome. I disagree with the rest, that would require updates in many places in the code which isn't desirable at this point. It might be a good addition for 1.1 or 1.2 though. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Release of v0.9.9 source code
On Saturday 19 November 2005 15:30, Erik Hofman wrote: Melchior FRANZ wrote: And finally, this is my TODO list: * try to get rid of a few more hardcoded dialogs, or at least make them accept gui colors Not that I explicitly stated no major updates to the *source* *code*. Removing code would be no problem (and neither would be putting an equivalent in the base package). Erik I agree with Franz Melchior. And my question is, why it is so essential to call the next version release 1.0? What's wrong with version numbers like 0.9.10, 0.9.11, 0.9.12 etc. until the above issues are fixed? I mean this is an Open Source Project, there's no need to meet a deadline and it's very unlikely that flightgear developers will loose there job when version 1.0 is not released in 1. quarter 2006. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: Release of v0.9.9 source code
I agree with Franz Melchior. And my question is, why it is so essential to call the next version release 1.0? What's wrong with version numbers like 0.9.10, 0.9.11, 0.9.12 etc. until the above issues are fixed? That's what's been getting done for years. The question now is, why not? Curt's been working on FlightGear for ... what ... about ten years, now? To turn the argument around, there's nothing to fear from calling it 1.0, either. The next release would be a fitting v1.0, IMHO. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Release of v0.9.9 source code
On Saturday 19 November 2005 16:35, Jon Berndt wrote: To turn the argument around, there's nothing to fear from calling it 1.0, either. I don't think so, in my opinion the status of version 1.0 will decide how many new contributers and public interest this project will get. In other words, my estimation is (when i look into my crystal ball :) ), that we will get more people that start contributing to FlighGear with things like creating 3d models and aircrafts when it's possible to switch aircrafts during runtime. When this isn't the case, people might think/say: OK, this looks nice, but i will wait with contribution until this issue is fixed,. or: Hm, i think i will give the project a next try when version 2.0 is out. On the other side we will get more attention even in none computer specific newspapers when the issues are fixed and people start to say: Wow, this is so perfect, this looks so great, what a wonderfull simulator... That's why we should be carefull about which version we call 1.0 In my opinion version 1.0 is an important release, it's not just a number. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Release of v0.9.9 source code
Oliver C. wrote: I don't think so, in my opinion the status of version 1.0 will decide how many new contributers and public interest this project will get. In other words, my estimation is (when i look into my crystal ball :) ), that we will get more people that start contributing to FlighGear with things like creating 3d models and aircrafts when it's possible to switch aircrafts during runtime. When this isn't the case, people might think/say: OK, this looks nice, but i will wait with contribution until this issue is fixed,. or: Hm, i think i will give the project a next try when version 2.0 is out. On the other side we will get more attention even in none computer specific newspapers when the issues are fixed and people start to say: Wow, this is so perfect, this looks so great, what a wonderfull simulator... That's why we should be carefull about which version we call 1.0 In my opinion version 1.0 is an important release, it's not just a number. I am *very* adverse to 'marketing' via version numbers because it is all so meaningless, so I'm not even sure why I'm participating in this thread, but the flip side of this is if we stay at 0.9.x too long, all these same people are going to look at FG and say ... ohh, they've been diddling around with 0.9.x versions for ever, they must not be doing anything serious over there. I think the issue can be argued both ways, but time (and version numbers) marches 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
