Re: Wheel skid sounds - Was: [Flightgear-devel] Re: Release of v0.9.9 source code

2005-11-23 Thread Erik Hofman
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

Re: [Flightgear-devel] Re: Release of v0.9.9 source code

2005-11-22 Thread Erik Hofman
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

Re: Wheel skid sounds - Was: [Flightgear-devel] Re: Release of v0.9.9 source code

2005-11-22 Thread Josh Babcock
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

Re: Wheel skid sounds - Was: [Flightgear-devel] Re: Release of v0.9.9 source code

2005-11-22 Thread Erik Hofman
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).

Re: Wheel skid sounds - Was: [Flightgear-devel] Re: Release of v0.9.9 source code

2005-11-22 Thread Josh Babcock
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

[Flightgear-devel] Re: Release of v0.9.9 source code

2005-11-20 Thread Melchior FRANZ
* 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

[Flightgear-devel] Re: Release of v0.9.9 source code

2005-11-19 Thread Melchior FRANZ
* 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

RE: [Flightgear-devel] Re: Release of v0.9.9 source code

2005-11-19 Thread Jon Berndt
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

[Flightgear-devel] Re: Release of v0.9.9 source code

2005-11-19 Thread Melchior FRANZ
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.

Re: [Flightgear-devel] Re: Release of v0.9.9 source code

2005-11-19 Thread Stefan Seifert
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.

Re: [Flightgear-devel] Re: Release of v0.9.9 source code

2005-11-19 Thread Erik Hofman
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

Re: [Flightgear-devel] Re: Release of v0.9.9 source code

2005-11-19 Thread Erik Hofman
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

Re: [Flightgear-devel] Re: Release of v0.9.9 source code

2005-11-19 Thread Oliver C.
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

RE: [Flightgear-devel] Re: Release of v0.9.9 source code

2005-11-19 Thread Jon Berndt
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

Re: [Flightgear-devel] Re: Release of v0.9.9 source code

2005-11-19 Thread Oliver C.
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

Re: [Flightgear-devel] Re: Release of v0.9.9 source code

2005-11-19 Thread Curtis L. Olson
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