Julian Foad wrote: > Hey, it's slightly different! How about we scrap the differences > and the anomalies and combine them? To do so, I'd suggest:
If you guys are thinking of changing the way we do "linear function of a property value" definitions in configurations, let me argue for a slightly different way to do it: The problem with specifying a multiplier (e.g. "scaling" or "rotation") and an offset is that these two opperations don't commute. Especially when coupled with a syntax that is order-independant (you can *specify* the scaling last, but it still happens first, or vice versa) it's a constant confusion for the user as to what the final result will be, with the end result that the generated configurations are hacked up balls of goo. Be honest everyone: how many people have ended up typing random values into things like this trying to get the results they expect? I know I have. Instead, why not specify a range mapping. That is, input values in the range [a,b] get mapped linearly to output values in the range [c,d]. Input values outside of [a,b] can be clamped to that range before computation. This has a few advantages: + Out of bounds values are eliminated by the clamping step. This is especially useful for sounds, where beyond-maximum scaling factors cause distortion. + The offset and multiplier are specified simultaneously and implicitly, so the user doesn't need to remember any precedence rules. + No need to handle the mind-bending gymnastics involved in negative scaling factors if you want something to scale in the reverse direction. (Negative scaling factors invert the direction of the offset only if the offset comes last; no wait... you get the idea). This is the way that YASim handles its property input and output specifiers*, and it's worked pretty well. Take a look at the reaction jet definitions for the harrier for an example of how much complexity this can eliminate. Andy * albeit not in a standard way -- YASim doesn't use the property tree parser, since I didn't know about it. It uses the lower-level XML callback API. -- Andrew J. Ross NextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
