--- On Wed, 9/4/08, Melchior FRANZ wrote:
> * Stuart Buchanan -- Wednesday 09 April 2008:
> > As I mentioned in my reply to Vivian, I don't want
> any dependency
> > on the Aircraft tree,
>
> You don't want that, fine. And *I* don't want a
> parallel structure of aircraft with megabytes of duplicated files.
I could have worded that better as the following: "I don't think there is any
benefit to adding AI aircraft if they have a dependency on the Aircraft tree."
> So, please let's discuss that first, before anyone
> dumps more of that stuff into $FG_ROOT/AI/!
Hence my original post - discussion is good.
In my opinion, adding AI version of the aircraft I maintain was reasonable,
they are fairly small anyway, and converting to png etc. makes them smaller.
> Do we really want MP support for all aircraft in the base
> package, at a cost of an extra 200 MB of data? Wrappers are fine
> (like Vivian described), but do we want a complete concorde.ac with all
> textures *again* in the AI/ dir? If someone wants the Concorde
> displayed, then s/he can install it, no?
Yes, I strongly think that there would be a real benefit for everyone who uses
the base package to be able to see all MP aircraft. As well as making the MP
experience faster (which everyone would benefit from), I think it would make it
richer for new users.
Even though I have a fairly fast machine, MP flying around KSFO is still
marginal. It is likely to get worse as the number and complexity of aircraft
increase. Creating AI models (and also promoting a culture of creating AI
models for all new aircraft) would go a long to helping this.
In that context, another 50 - 100MB of data in the base package seems
reasonable.
I think it should be possible to create AI aircraft at less than, say, 500KB
per aircraft, which would grow the base package by less than 100MB. For
example, the Vulcan AI model is around 200KB.
Some aircraft are going to be much easier to make AI versions of than others,
and some may require the .ac file to be edited. Most of "my" aircraft are
almost trivial in complexity.
> I'd prefer fgfs to show better information about which
> aircraft
> couldn't be shown because they aren't installed,
> and a better LOD
> concept (LOD in the aircraft dir, where it belongs). And if
> we really
> want the independence, then we should make sure that this
> is cheap.
> Textures should be scaled down a *lot*, the model should be
> drastically
> poly-reduced, the whole aircraft shouldn't take more
> than 250 kB (or
> something). And we don't need MP-versions of Ogel,
> wrightfligher and
> others.
How about the following
- Maximum size 250KB.
- All textures converted to PNG and scaled to 1/4 size in both dimensions.
Does that seem reasonable?
-Stuart
___________________________________________________________
Yahoo! For Good helps you make a difference
http://uk.promotions.yahoo.com/forgood/
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
