David Megginson writes:
> I've been thinking about this for a while, and I think that the best
> approach would be to read scenery from multiple directories at once.
> For example, I could have the main scenery under
> /usr/local/FlightGear/Scenery/, and major landmarks under
> /usr/local/FlightGear/Landmarks/, and configure it something like
> this:
>
> FG_SCENERY_PATH=/usr/local/FlightGear/Scenery/:/usr/local/FlightGear/Landmarks/
Ok, I have just commited changes that impliment this optional
behavior. You can specify a list of directories to search. Here are
a couple of notes:
- I used ";" as the path delimiter. This sucks for unix people
because that is the command separator. However, ":" would suck even
worse for windows people because that is a critical component of
their file naming scheme. Unix people can escape the \; or put the
entire argument in double quotes. I'm open to a better path
separator if someone wants to suggest one.
- There are some subtle path ordering limitations:
Once the system finds a valid base tile, it will stop searching
through the remaining directories. This allows us to specify a base
tree of scenery, and preceed the search path with a tree of newer
tiles ... but the newer tree may be incomplete or cover a smaller
area so we want to fall back to the older data if the newer data
doesn't exist for a particular tile. If we didn't stop searching,
we could load an old and new tile concurrently which would generally
be bad.
So to work with this system you would want to do the following:
- if you have a smaller set of tiles that you want to take
precidence over a larger (older set) the list the highest priority
stuff first in the path.
- if you have a set of overlays (like landmarks for instance) then
list those first in the path before any directories that could
contain base tile data.
Hopefully this makes some sort of sense. It seems to work on limited
tests here, and if you just define a single search path (or inherit
the default scenery path off the root path) then you will get an
equivalent of the previous behavior with no extra disk seeking.
Regards,
Curt.
--
Curtis Olson IVLab / HumanFIRST Program FlightGear Project
Twin Cities curt 'at' me.umn.edu curt 'at' flightgear.org
Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
