On Thursday 21 October 2004 03:05, Boris Koenig wrote: > Ampere K. Hardraade wrote: > > One of the problems, as I pointed out earlier, is that the > > download size of the base package is a bit on the huge size. > > fully agreed, that's something most people seem to complain > about - on the other hand it's fairly "small" to be honest - > if you compare it to other simulators like MSFS, X-Plane etc. > - so having a full simulator by downloading less than 100 MB > data, sounds okay to me. > > On the other hand the scenery is still a whole different > matter, and my example doesn't take into account that FG's > scenery is made available separately. > > Also, if you are merely updating your package and "suffering" > from a low bandwidth connection, you could still check out > tardiff: > > http://tardiff.sourceforge.net > > Stewart & Steven have just recently created new patches for > the latest FG base package version, so it might be worth to > give it a try if downloading another 80 MB does not appeal to > anybody here ;-) > > Even though these patches are CHECKED before they are released > you cannot expect much support for newly encountered problems > after applying a patch, the first advice would be in most > cases to install a conventional package, in order to assure > that there aren't problems caused by the patch. > > > That's also something that Erik mentioned some time ago. > > > Including all aircrafts into an already big download will > > not be a good idea. > > I agree again, I've just checked the size of my local aircraft > folder in $FG_ROOT/data - it's close to 170 MB, but on the > other hand I could imagine that as an aircraft > designer/developer it's also quite a motivation to have your > aircraft by default in the base package, regardless of its > development status, it also assures that users can easily try > out your work and provide feedback. > > So, I am not sure if it's such a good idea to simply stop > packaging unfinished aircraft. > > On the other hand I am certainly not in the position to really > care about the download size ... so my opinion is not > particularly valuable in that regard ;-) > > Personally, I'd hence still prefer getting everything and > being able to tell FlightGear what maturity level I require > for all aircraft minimally. > > > So, the best option will still > > be removing all the work-in-progress aircrafts from the base > > package, and keep the size of the download to a minimium. > > well, if that should really turn out to be the best option, > one might very well end up having two different base packages > - one for developers, and one for end-users who merely want to > have the working stuff. > > But even then, the option to classify aircraft by their > development status might come in handy > > Even if it's not being used by FG directly, on the one hand > one could introduce such a <maturity></maturity> tag in order > to allow scriptable extraction of immature aircraft without FG > even knowing about it. > > On the other hand one could have the launcher (fgrun) display > whether an aircraft can be expected to perform flawlessly or > not by looking at its maturity tag. > > In that regard one might even consider adding some kind of > "remarks" tag to the XML file to allow developers provide some > general information about their aircraft, any bugs that are > existing and maybe even TODOs. > > Neither of these latter two suggestions would require any > direct code changes to FG, because as far as I know the XML > files aren't currently validated anyway. > > So one could simply recommend aircraft developers to maintain > two specific sections within their aircraft definition files, > one being something like > > <maturity>experimental</maturity> > > and the other one > > <remarks>this aircraft has the following known > bugs...</remarks> > > Then it would be fairly straight-forward to either extract > certain aircraft from the base package by using a shell script > based on the defined development status, or alternatively one > could extend fgrun in a manner to take these tags into account > so that it could either display the said info or even offer a > filter so that only aircraft meeting a certain development > status are displayed. > > I haven't yet looked into the sources for fgrun, but I think > it should not be that much of an addition ? > > I think such an approach would have the potential to reduce > some of the frustration and confusion that some new users > encounter. > > What do you think ? > > ---------- > Boris
Based on the assumption that the number of aircraft for FG will continue to grow, most of them will have to be removed from the base package at some point. That doesn't mean that they have to be removed from FG though... I think that what is really needed is some sort of aircraft installer (and uninstaller) and just as there are currently separate packages (and cvs repositories) for the source and data, an additional aircraft repository could be set up and the installer could install the aircraft from there. Some work along these lines has already been done, by making it possible to isolate each aircraft in it's own directory, but it would still need more of someone's time to design, code and test such an installer. IMHO I'd say that this, or an alternative solution, should be considered a requirement for the 1.0 release. LeeE _______________________________________________ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
