On Friday 22 August 2003 20:00, Erik Hofman wrote:
> Norman Vine wrote:
> > Arnt Karlsen writes:
> > 
> >>Matevz Jekovec
> >>
> >>>Is there any way to checkout certain directories in CVS repository and
> >>>not the whole module? If not, IMHO Aircraft and Textures.high should
> >>>be in seperated CVS then. Default base package should only include
> >>>Cessna 172 and lowres textures.
> > 
> > 
> > Not currently, unless you want to issue a separate CVS command for
> > every file and directory in the Top Directory
> 
> You know, I use CVS without any -d parameter these days. It seems to 
> look for a CVS directory in the current directory anyway and decide to 
> use what it found.
> 
> Quite handy I must say.
> 
> >>..I'm with you all the way to lowres textures, I like to 
> >>still see all aircraft with their lowres textures.  IMHO,
> >>much of the point with FG, is the 3-4-5-6-whatever fdm's 
> >>for each plane.
> 
> This doesn't actually add that much data since most of it is shared (at 
> least the larger parts like 3d model and textures anyway).
> 
> > 
> > I agree having many FDM's and many Aircraft is one of FGFS's
> > cooler points, but...., IMO there is no reason these all need be in 
> > the 'core' package, esp when just staying current with the core 
> > package gets in the way of code development.
> 
> 
> I agree. There has been some changes in the recent past where Lee 
> Elliot's models added all the instruments ant texture which are also in 
> the shared directory. This is fine with me but only when not in the 
> default base package.
> 
> For package management I really think we should use a default ".tar.gz" 
> (or .tgz) archive because these are easy to create for everybody.
> 
> Erik

Yeah - I've started to put all of the instruments and related textures used by 
an aircraft in the aircraft's individual aircraft dir.  In the short term 
this has resulted in some duplication but I've done this to try to prepare 
them so that the a/c and it's instruments can be removed from the fgfsbase 
package and installed separately:)

(I've no intention of removing the a/c from FG or placing any sort of 
restrictions on them - I'm just trying to anticipate their removal from the 
fgfsbase package to get it's size down.  Being on 56k dial-up, it's size is 
an issue for me too)

Personally, I'm not much interested in doing panels and instruments so I'd be 
happy to use the generic instruments from fgfsbase, where they exist, but 
there needs to be a clearly defined list of what those instruments will be 
once all the a/c, apart from the default C-172, are removed from fgfsbase.

Once there is a definitive list of the generic instruments that will be in the 
fgfsbase package I'll remove the duplicates from the a/c dirs and reference 
the generic instruments instead.

While it's certainly possible to save space by referencing instruments from 
another a/c to save space - for example, I could put a complete set of 
instruments in the yf23 dir and then reference them from the b52, Sea Hawk 
etc, it's an inherently fragile solution.  As soon as a user removes the 
yf23, or someone does a proper panel and instruments for it and removes the 
current ones you end up with the b52, Sea Hawk etc being broken.  For this 
reason a degree of duplication will be inevitable untill every a/c has 
specific panels and instruments.

I'll also openly admit that I'm responsible for some cruft in the instruments 
dir and I'm slowly working my way through trying to get it removed but the 
safest quick way of doing this, while ensuring that nothing gets broken is to 
duplicate them in the a/c dir.

I think an important part of splitting the a/c out of fgfsbase will be a FG 
a/c installer that can also handle updates and roll-backs and be used by 
people who aren't into the 'computer' side of it all.  Ideally, everything to 
do with a specific a/c should be compartmentised so it can sit in it's own 
dir - this would make the installation, update, removal and roll-back of a/c 
even easier.  If however, we keep the current scheme where the 'set' file 
_has_ to exist in Aircraft and the YASim fdm _has_ to exist in 
Aircraft-yasim, an installer would ensure that stuff goes in the right place.

LeeE


_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Reply via email to