On Sun, Dec 12, 2010 at 9:42 AM, Martin Spott wrote: > Stuart Buchanan wrote: >> Martin - does this address your concern? > Well, at the end of the day it's completely irrelevant if my concerns > are being addressed ;-)
Not at all. Such decisions need to have community-wide "buy-in" to have any effect, and you raised a valid point. Plus, not to at least try to answer your concerns would be rude on my part. > In fact, it's not my 'playground'. I just got the impression that the > gap between the ideas of a rating system for use with the download page > and its pratical realization is getting biggger, the more elaborate the > rating system is being designed. Hence my comment. If you're convinced > that it'll be going to work, then please don't care about my concerns. Eventually I'd like to see the rating system used in the download page, to allow some filtering/ordering. With an XML-tag approach, this should be straightforward. At the moment, as Hal has pointed out, the status tag is very general, and up to the very subjective opinion of the developer. Using a rating system would at least allow the developer to make a more objective judgement. (See below for an example with the c172p :) On Sun, Dec 12, 2010 at 10:04 AM, Detlef Faber wrote: > Am Samstag, den 11.12.2010, 16:00 -0800 schrieb Hal V. Engel: >> The thing about Stuart's system is that it is very objective, easy for devs >> to apply (IE. it is not complex and only takes a few minutes to do) and >> provides users with a lot more information about the state of the models >> development. But it could also be used to make the current system more >> objective and more consistent. > > Objectivity is very hard to achieve, given the fact that most FDMs are > guesswork regardless how well the numbers fit. Judging the FDM of an > Aircraft which one hasn't flown is walking on thin ice and will most > certainly lead to bad mood. Yes it is hard, but we strive to do the best we can. I think "bad mood" translates better as to "feeling depressed how far their FDM is from the real aircraft"? I'd agree - see below. > Starting point of the discussion were Users complaining about too much > incomplete Aircraft on the download Page (which is undoutably so). I'd > say it's up to the developer to decide wether the current state is > usable (from a Users point!) or not. Absolutely. The problem at the moment is that there is no standard for describing status. What we're attempting to do is to provide the developer with the tools to assess the quality of their aircraft. Hal wrote: > Stuart wrote: >> 18 or higher = advanced production (minimum 4 in each rating) >> 16 to 17 = production (minimum 4 in each rating) > > For production perhaps at most 1 category with a 3 rating all others 4 and > above to get a little bit of a sliding scale between production and advanced > production. I couldn't decide whether to make the minimum for "production" 3 or 4. A 3 would allow an aircraft with an FDM that just matched the PoH for rate of climb and cruise numbers, which feels to my mind as being a bit weak. >> 12 to 15 = early production (minimum 3 in each rating) >> 9 to 11 = beta (minimum 2 in each rating) >> 7 to 9 = alpha >> less than 7 = not rated > > The above system is very strict. There will be only a handful of aircraft > that make it into the "advanced production" status if there are any at all and > only a few will be production status. As an indication of how strict this is > the p51d-jsbsim and the C172p would both get an early-production status > because each has at least one 3 rating although both are almost production > quality. This level of strictness is a good thing as I think we want this to > reflect very high standards at the higher status levels. I agree it's quite strict. After writing the ratings I measured the c172p, and realized that the FDM was the weakest area and really stopped it from being a truly "production" level aircraft. While I've spent some time attempting to match the cruise and rate of climb specs, I certainly haven't checked the stall speed in different configurations. I think this validates the rating system and the mapping to status tag. It makes it very clear that the c172p is not quite as good as I had previously thought, and that I (or anyone else!) need to spend some time working on the FDM rather than (say) improving the 3D model in some way. > This also means that many aircraft that currently have a production status > will be down graded to early-production or beta status and many currently at > beta status will end up being alpha or not rated. So we should expect that > some aircraft devs might get their feathers a little ruffled by this. Possibly. I think there are also some developers who are very strict with themselves. We should be striving for excellence, and if this means being more honest about the quality of our aircraft, we shouldn't shy away from doing so. > On the > other hand it gives devs a lot of useful feedback about where their model > needs work and this might encourage aircraft devs to either focus on areas > with the lowest ratings or seek help from others to improve these areas. Exactly. > One thing that is currently not rated by this system is sounds. Perhaps a > Sounds category should be added for a overall scale of 0 to 25? And of course > the rating to status conversion would have to be adjusted to the new scale. I think it might be better to add them as part of either the model of cockpit sections. At the moment, the FDM only accounts for a quarter of the rating, and I'm loath to "dilute" it further. Equally, I'd like to avoid making the conversion from rating to status more complicated than necessary. > I also like having a minimum for each individual rating category so that > everything has to have had approx. the same level of work to move up the > status scale. I could extend the minimum values downwards so that an "alpha" aircraft needs a minimum score of 1 in each category. Is that what you meant? -Stuart ------------------------------------------------------------------------------ Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
