Jon Stockill wrote:
Curtis L. Olson wrote:
Jon Stockill wrote:
Currently the smallest area it's broken down to is one of the 10x10
degree scenery tiles. The biggest of these files is only 500k (the
whole planet fits in a 4MB tarball), so I didn't see a need to break
it down any further. If you're interested in just a specific area
then drop me an email and I'll see about exporting just the area
you're interested in (if you're just interested in seeing what
objects are in a particular area you may find that entering partial
lat/lon info into a search on:
http://fgfsdb.stockill.org/objects.php
Jon,
I see a distribution issue which I'd like to discuss.
The object database lives in it's own separate tree. Right now to
use your object database a person needs to add a set of models to
their base package. Then they need to install the object tree.
However, from my perspective, if I want to roll up a 10x10 chunk of
terrain + objects I have a big problem. I need to either roll these
two trees together in one big tree (which makes it hard to change or
upgrade the objects.) Or I need distribute 2 tgz files (and the end
user needs to download and correctly install 2 tgz files) for each
10x10 chunk.
Would it make sense to make your object database (for the entire
world) part of the official base package and put it all in cvs?
If we want to leave these objects as user-add-on-after-the-fact
entities, then it's ok how we are doing it now, but they add a *lot*
to the flightgear experience so I would really like to make them part
of the default some how without imposing an overwhelming burden on
the end user to do extra complex downloads and installs by hand.
I'm not sure I'm explaining the issues very well, but hopefully
someone understands what I mean and can offer suggestions.
It would be easy enough for you to include the latest version of the
database when you built the scenery - the Terrain and Objects split
works really well to make this relatively easy, and simple for someone
to add the latest version of the objects before the next scenery update.
If your scenery package were to have the following (example) structure
in the tarballs:
Objects/w010n50/
Objects/w010n50/w002n53
Objects/w010n50/w002n53/295555.stg <-- entries just for objects
(Static scenery models would be included here)
Terrain/w010n50/
Terrain/w010n50/w002n53
Terrain/w010n50/w002n53/295555.stg <-- entries for airports
(Airport and terrain tiles appear here)
roll the whole lot up in a tarball for w010n50 and it can be installed
as a single package under your scenery directory. If anyone wants to
update the models at a later date then they can just replace the
Objects/ tree with the latest version.
That might be what we have to do, but that implies a change in where
scenery files are extracted relative to the scenery tree which would
could cause a fair amount of confusion ... not that the current process
is completely unconfusing ...
Curt.
--
Curtis Olson http://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
