-----Original Message----- From: Lee Elliott [mailto:[EMAIL PROTECTED] Sent: Fri 22/10/2004 22:07 To: FlightGear user discussions Cc: Subject: Re: [Flightgear-users] classifying development statusofaircraft&extending fgrun (was: "Flyable" aircraft) Arrgghh!! I don't mind top-posting or bottom-posting, but not alternating:)
So just to really muck it up I'll in-line my responses:) Anyway... On Friday 22 October 2004 14:22, Giles Robertson wrote: > This produces some interesting problems. > > I've hacked up a script to show dependencies between a/c (it's > currently very, very bad, so I won't mislead anyone with the > results), and thinking about a/c installation brings up some > quite odd problems. > > 1) If we split each a/c into its own directory, then there is > a lot of duplication. There's only a lot of duplication while stuff is 'borrowed' between aircraft. Ultimately, the goal must be for each aircraft to have it's own authentic instruments etc. and then the duplication problem disappears. > > 2) If we keep a/cs interdependent, then we could face > versioning hell. For example, the T38 maintainer changes the > directory structure for the T38, breaking the 737 (which is > dependent on the T38). In that case, a simple packaging system > would have to require that the user hold two copies of the T38 > package (if the user wanted an up to date T38) - one that was > 737 compatible, and the latest T38 version. This seems > undesirable, and I do not relish debugging a user's setup when > he or she has multiple versions of the same package. There's no need for a 'versioning hell' situation. It would be pretty easy to come up with a versioning scheme that would be easy for the developers to work with. It would need some thought of course... :) > A more complicated packaging system could work out that the > update broke the 737, copy the required files to the 737 > package, and then introduce a dependency on the T38 that read: Interdependencies between different a/c designs, as opposed to models or versions, have got to be a big no-no. For multiple versions, or models, within a basic design, the responsibility must rest with the a/c developer. > > If user has 737 installed, 737 version must be > x, but 737 is > not required for T38 to run. > > This is a particularly odd dependency, in that it isn't a > dependency at all; more something to limit the damage on the > rest of the users setup. > > Furthermore, there would be no easy way of removing that > dependency; it would remain in perpetuity to provide backwards > compatibility. Also, if the T38 was reorganised again, it > would be nontrivial to reintroduce the dependency of the 737 > on the T38. > > The result of this scenario is a duplication of files, without > removing a dependency (just replacing it with a weirder one). > > Iterate this process over many a/c over many years, and you > should have a situation where most a/c are self contained, but > there is a pile of old, weird dependencies lying around, which > brings us back to situation 1). > > 3) I think, however, that there is a middle way. We already > have shared resources - the Instruments, Instruments-3d and > Generic folders - and if we shift commonly used files to a > general resource, and are careful how we update that, we can > eliminate much of the waste of duplication. Such a system > would require that no a/c be dependent on any other a/c, but > would allow any a/c to use the shared resources. I'll start > looking at which files are good candidates to be moved to a > shared folder. > > Giles Robertson IMO, all of these problems are due to the development state of FG (0.9.x). Currently, the most important thing is to get the program working right. Then worry about packaging it - no point in having a beautifully packaged bit of software that doesn't work... ;) LeeE > > > -----Original Message----- > From: Lee Elliott [mailto:[EMAIL PROTECTED] > Sent: Thu 21/10/2004 19:06 > To: FlightGear user discussions > Cc: > Subject: Re: [Flightgear-users] classifying development status > of aircraft&extending fgrun (was: "Flyable" aircraft) > > On Thursday 21 October 2004 18:57, Lee Elliott wrote: > > 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 > > While I remember, if there was a separate aircraft repository > it would be useful if FG could be told to check for new > aircraft or updates, and then install them if requested. > > Also, while I'm thinking about it, it would be a Very Good > Thing to provide a rollback facility so that if a user has > problems after updating an aircraft, they can easily revert to > the previous working version. Hopefully, it'll never be > needed;) > > LeeE > > _______________________________________________ > Flightgear-users mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-users > 2f585eeea02e2c79d7b1d8c4963bae2d _______________________________________________ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d I've little to say, so it can come right down here. Hone everybody's scrolling skills. ;) The main problem is 'borrowed' equipment. However, I think that this is exactly what we have an open-source simulator for; considering aircraft will perpetually be in development, and so probably borrowing bits from other aircraft, we might as well create a system that makes this easy; and this system needs to be easy both for developers, and for users. This is indeed nontrivial, but I suspect that sorting it would aid further development. I seem to recall complaints about downloading the entire CVS base package over 56k ;) Giles Robertson
<<winmail.dat>>
_______________________________________________ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
