[Flightgear-devel] former project policies
I've now written together some rules for aircraft developers that I used to consider official project policies. After recent difficulties to persuade developers to consider them, I will no longer care about them and will only fix buggy aircraft in my local checkout. That's why I put this only on my personal wiki page: http://wiki.flightgear.org/flightgear_wiki/index.php?title=User:Melchior_FRANZ m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] former project policies
* gerard robin -- Wednesday 21 November 2007: I only wonder about = SGI textures (*.rgb) shall be aggressively since i remember getting trouble with that format Thought i have not tested it recently, [...] There was a problem with compressed splash textures, but that was a bug in fgfs that is meanwhile fixed. If there turn out to be other problems, just report that, and we'll fix the broken code. GIMP doesn't tell the whole truth. It wants to make us believe that this compression is aggressive and doesn't work on SGI machines. Both is nonsense. This is the *regular* compression as defined in SGI's own image specification. If anything, then it's GIMP's packer which is broken. If so, then just use a different one. KDE has a better packer, anyway. :-} Global settings , may open a question = i use the brake-parking ON which is to me necessary with with some models, for instance: That's a grey area. For me it *is* a property directly related to the aircraft simulation, therefore I don't see anything wrong with setting it in an aircraft file. Actually, I prefer to have the parking brake applied, and have that in my local setup (which is why I wouldn't even notice :-). Generally, I agree with the suggestion that it should be configurable, whether an aircraft should at startup be parked with engines off and all, *or* ready for takeoff on the runway/helipad/seaport. But this needs some work. The new apt.dat.gz (which Martin has committed recently) does actually contain possible startup locations. I was about to make that available, but the information is a bit hard to digest, as different types aren't encoded with a number, but with apparently non-standardized free text. (Also, all aircraft should support startup in air, and I must admit that this doesn't even work for the bo105.) m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] former project policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 About global settings: this would affect the generic HUD too right? Quite a few aircrafts prevents you from turing on the generic HUD (I agree that it may not be realistic for the aircraft, but it is very useful when you try an aircraft for the first time to learn to use it...) Regards, AnMaster Melchior FRANZ wrote: I've now written together some rules for aircraft developers that I used to consider official project policies. After recent difficulties to persuade developers to consider them, I will no longer care about them and will only fix buggy aircraft in my local checkout. That's why I put this only on my personal wiki page: http://wiki.flightgear.org/flightgear_wiki/index.php?title=User:Melchior_FRANZ m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHRCvRWmK6ng/aMNkRClY2AKC+ayu2+g2JW0cBMaKbFxS2Mnv4xwCfUIR9 EtWDN2ST2Xm9BRXtMHvBmz0= =qDwM -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] former project policies
* gerard robin -- Wednesday 21 November 2007: AND, the recommendation to use English is less easy when we are not English speaking , this will be an add on of work for the developer. I didn't say that filenames/comments/function-names shall be in perfect English, nor in English better than you are able to speak. But they should *be* in English. I could start to write everything in German, with German comments, function names etc. Maybe some Austrian dialect. You'd quickly be lost! CVS isn't a dumping ground for secrets. Everything there should be open. And being open also means to be understandable by as big an audience as possible. I'm just not able to learn Greek, Chinese, Swahili, ... We all hate English, but it's the lowest common denominator. ;-) But again: these are *my* policies. It's not in the official policies document (because no such exists, and nobody would enforce it, and even if, some would ignore it). To translate them, in order to have it acceptable with FG 0.9.11 will take more time than to build fully it again (was the case with Catalina). My policies do also not mean that there couldn't be exceptions. If there's a plausible reason why some condition *can't* be met (with reasonable effort), then I can certainly live with that. But people making a new aircraft should know what they are expected to consider. m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] former project policies
Melchior FRANZ wrote: CVS isn't a dumping ground for secrets. Everything there should be open. And being open also means to be understandable by as big an audience as possible. I'm just not able to learn Greek, Chinese, Swahili, ... We all hate English, but it's the lowest common denominator. ;-) Oi! The's now't wrong wi english, even if nob'dy ahtside yorkshire can talk reet. ;-) Jon - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] former project policies
I was interested in finding out if my model followed the rules, and came up with a question: If I want to use a generic instrument, but need to modify the xml file slightly, would it be best to place that new instrument.xml file under the generic directory, or copy the entire instrument package to my model instruments directory? I am currently following the second option, as the rgb and ac files must be in the same directory to work. For another instrument, the Clock, I changed the rgb file so that the background was transparent instead of solid white. Perhaps I could submit it to replace the generic clock in CVS? Instruments-3d/clock/clock.rgb Thanks, Stewart -- Melchior FRANZ wrote: I've now written together some rules for aircraft developers that I used to consider official project policies. http://wiki.flightgear.org/flightgear_wiki/index.php?title=User:Melchior_FRANZ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] former project policies
On Wed, 21 Nov 2007, Stewart Andreason wrote: I am currently following the second option, as the rgb and ac files must be in the same directory to work. If you don't need to change the .ac or the textures you only need to copy the XML file. You'll need to add some '../'s to the path and a texture-path element, though. See e.g. AI/Aircraft/Lightning/Models/lightning-model.xml which use this method. Cheers, Anders -- --- Anders Gidenstam mail: anders(at)gidenstam.org WWW: http://www.gidenstam.org/FlightGear/JSBSim-LTA/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] former project policies
Hi, Melchior FRANZ schrieb am 21.11.2007 13:33: (Also, all aircraft should support startup in air, and I must admit that this doesn't even work for the bo105.) This is my fault, not yours. It's on my open point list (since a long time :-( ) Maik - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel