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:) LeeE _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
