On Thursday 29 November 2001 4:10 pm, you wrote:
> One thing that would be nice in terms of distributing and managing
> multiple aircraft would be for everything related to a single aircraft
> (fdm config, textures, instrument panel, sounds, etc.) to be located
> under a single subdirectory. This simplifies distributing,
> installing, and removing aircraft (especially for those that
> concentrate their efforts on things besides learning to be a
> sys-admin.)
This was my exact reason for making it like it is now. We need to find a
happy medium to prevent duplication as much as possible.
>
> We could have standard instruments, sounds, textures, etc. arranged
> differently so aircraft could opt to reference system files rather
> than their own, but they could override any instrument, texture,
> sound, etc. with something in their local tree.
>
Thats kind of what I mean. IMO stock instrument sets could be grouped
by airframe manufacturer. Picture
Aircraft/
Beech/
Instruments
$model
Cessna/
Instruments
$model
Piper/
Instruments
$model
> Regards,
>
> Curt.
>
> David Megginson writes:
> > John Check writes:
> > > hehe forgot about that one. I think now would be a good time to
> > > consider changing the directory structure to something like:
> > >
> > > Aircraft/
> > > Cessna
> > > /
> > > Instruments
> > > c172
> > > /Panels
> > > Instruments
> > > c310
> > > /
> > > Panels
> > > Instruments
> >
> > I recommend something quite different:
> >
> > Aircraft/
> > Aircraft/Aero/
> > Aircraft/Instruments/
> > Aircraft/Panels/
> > Aircraft/Sounds/
> > Aircraft/Models/
> >
> > Directly inside Aircraft, we would have a top-level property file for
> > each specific model configuration (specifying FDM, aero model, panel,
> > sounds, 3D model, etc.).
I dunno, I think having it categorized by manufacturer is a little tidier.
Aircraft/Manufacturer/Model/ == MODEL_ROOT
>>Aero/ would hold the JSBSim config files,
put in $MODEL_ROOT
> > Instruments/ would hold the instrument property files, Panels/ would
> > hold the panel property files, Sounds/ would hold all
> > aircraft-specific sounds, and Models/ would hold all aircraft 3D
> > models.
Model specific under $MODEL_ROOT
Pretty much what we have now except for the manufacturer
classification.
> >
> > For example, the file Aircraft/c172-vfr.xml might reference
I like that as far as a place to keep the top level aircraft cfg,
but if it references everything under one subdirectory we don't
need any kind of installer/uninstaller script.
rm -rf Cessna/C172-VFR/* will do the trick
We could forget about the manufacturer classifcation here
and do
Aircraft/Instruments/
extremely_generic.xml
Manufacturer/
OEM-style.xml
$MODEL/
Instruments/
model_specific.xml
Have the top level config under Aircraft
Have the different panel styles each have their own $Model dir
with $MODEL-panel.xml at the top and all model specific
parts under. Or something.
> > Aircraft/Aero/c172/c172.xml, Aircraft/Panels/c172-vfr-panel.xml,
> > Aircraft/Sounds/io360.wav, Aircraft/Models/skyhawk.vrml, and many
> > other files. The panel would reference
> > Aircraft/Instruments/gyro.xml, etc.
> >
Yes but maybe we have several styles of whatever.
Unique names takes care of that but it could end up being pretty sloppy.
> > I also recommend changing the options around, so that our current
> > --aircraft option becomes --aero, and the --aircraft option points to
> > the top-level config file. With this arrangement,
> >
> > fgfs --aircraft=c172-vfr
> >
> > causes the top-level Aircraft/c172-vfr.xml property file to be read,
> > and the correct sounds, panel, etc. to be loaded.
> >
> >
> > All the best,
> >
> >
> > David
> >
> > --
> > David Megginson
> > [EMAIL PROTECTED]
> >
> >
> > _______________________________________________
> > Flightgear-devel mailing list
> > [EMAIL PROTECTED]
> > http://mail.flightgear.org/mailman/listinfo/flightgear-devel
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
