Hi Syd, For downloadable add-on aircraft, 3D instruments should be stored inside each downloadable aircraft package even these can be duplicated. I also think that each downloadable aircraft should be independent from both base package and other aircraft even these share the same panel, sound, etc. The reasons are as follows:
1. To make FlightGear user friendly Independent downloadable package has less problem in downloading a new aircraft since users don't have to download some other aircraft that the downloaded one relies on. Plus, aircraft itself can be work on several different version of FlightGear. we, at this moment, have three different versions, 0.9.10, 0.9.11-pre, and CVS/head. So having 3D instruments inside a package provides with users more chance to use a new aircraft. Of course this redundancy might give developers a bit annoying situation since they need to maintain duplicated parts for every aircraft that shares the same ones. As you know, I made some nas files and instruments shared with three different japanese warbirds, but I didn't put any of these to the shared folder in a base package, this is because I want to make these packages independent from the base package of a certain version so users can use these on both 0.9.10 and CVS version. even though I have to maintain these shared parts considering the differences among active fgfs versions, I use local repository and some helper scripts to save my time. Having a nice downloading GUI program can solve such problem if it can automatically downloads the parts that an aircraft depends on. It may check the dependencies and conflicts semi-automatically to avoid messing around other aircraft. 2. To make base package travel light To put many shared parts into the base package can make a fat base package. This may lead long downloading time for possibly unwanted shared objects. Lightweight base package is always a good answer unless these shared ones are needed by the base package itself. 3. To avoid unexpected impact on changing an shared instrument Especially in an early development phase of a certain aircraft, the developers want to change its instruments, sound, etc often. In this case changes can affect some other (older?) aircraft and users might experience unexpected changes on other aircraft. In this case users need to update every aircraft that shares the changed instrument, otherwise the older ones might not work properly. That what we should avoid, I believe. I think such thing can be always a troublesome issue since we need to take care of many perspectives. But it is always a good to think about such things for maintaining entire FlightGear package wholesome for both developers and users side. Talking about wholesome, I'm changing some nas files in japanese warbirds due to Melchior's advise about "var." I love his thought since he always want to maintain FlightGear wholesome and consistent. I'll give you these files when completed. Best, Tat On Dec 9, 2007, at 5:31 PM, Durk Talsma wrote: > On Sunday 09 December 2007 07:22, Syd&Sandy wrote: >> Hi everyone , >> I ran into another issue , just wondering what everyone else's >> opinion is >> on the matter. I,ve been updating the Bravo , and the Primus 1000 >> instruments and controllers are in the Aircraft/Instruments-3d >> folder. I >> assumed that this is the place all 3d instruments should go ... >> preventing >> unneccesary duplication , but if the aircraft is a separate >> download , this >> could be a problem . Unless of course , those instruments are added >> to the >> download package . I guess my question is , should the 3d >> instruments stay >> in each Aircraft folder , or the Instruments_3d folder. I have done >> it both >> ways , but I think if we get enough accurate 3d instruments in the >> Instruments_3d folder , assembling a 3d panel should become easier >> as time >> goes by ... Cheers > > As it stands right now, the Instruments-3D directory will be part of > the base > package, so downloaded aircraft should still work. > > cheers, > Durk > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
