On Monday 22 November 2004 22:43, Boris Koenig wrote:
> Curtis L. Olson wrote:
> > I think step #1 needs to be making aircraft relocatable.
> If I did get everything right, the major problem is that
> aircraft rely on instruments and other devices that reside in
> abitrary locations within the $FG_ROOT directory structure.
> As a workaround it might really be already sufficient to
> simply use a bunch of variables that simply refer to $FG_ROOT
> - that way there wouldn't be any messing around with relative
> paths - rather, FlightGear itself would simply look for a
> supported environment variable such as $FG_INSTRUMENTS or
> $FG_AIRCRAFT and would automatically return a corresponding
> such as $FG_ROOT/data/Instruments or $FG_ROOT/data/Aircraft.
> This is really no big deal and would essentially allow
> Aircraft to reside anywhere - right ?
> Alternatively, one could also decide to use the Property Tree
> to store the absolute paths, so that these can be dynamically
> modified at runtime - if necessary.
> > Then step #2 and beyond could be coming up with an a
> > useful/interseting categorization, organization, and
> > filtering scheme.
> I think this would be mainly about providing additional tags
> that support specification of the <type> of aircraft, number
> of <engines>, the <engine_type>, possibly using also data such
> as weight, pax etc.
> --------
> Boris

Well, someone has to suggest it...    :)

...perhaps some rdbms code has to be integrated into FG.

The downside would be that an installer/un-installer would become 
a necessity.

At a minimum, only the paths need be stored, together with the 
classification tags, but who could resist the temptation of 
storing absolute a/c components...

Only joking folks:)


Flightgear-devel mailing list

Reply via email to