On 02/25/2007 02:39 PM, Roy Vegard Ovesen wrote: > I suggested an encoding altimeter as an instance that has both. Do you think > that makes sense?
Yes, that has been suggested. But what's the rationale? It's not the craziest idea in the world... but I still haven't heard an argument for it that comes close to outweighing the arguments against it, to wit: -- Having a separate "steam gauge" instance and a separate "encoder" instance is more consistent with real life and more consistent with the existing FG fleet -- Having the altimetry object serve as an oracle for computing the Kollsman shift is entirely natural if there are separate instances, but introduces highly unrealistic complexity and obscurity, especially if a single instance is required to accept multiple "settings" as input. > I have not, and I don't think Dave Perry has either, expressed optinions to > indicate that the pressure altitude should not be quantized. What we have > said is that indicated altitude should not be quantized. My version of the altimetry object does not quantize the indicated output except insofar as it is based on the pressure altitude which might be (upon request) quantized. This is entirely realistic and natural behavior for a backup altimeter indication based on encoder output, such as we sometimes have in real life. Again, I have not heard any *rationale* for providing a fully-analog indicated altitude in cases where the underlying pressure altitude is quantized. This seems conspicuously unrealistic. I cannot imagine any real- life instrument that would or could work that way. If I'm wrong about that, the easiest thing to do is explain what instrument you have in mind ... then it will be straightforward to model that instrument. I am not in favor of a model instrument that is conspicuously unlike any real-world instrument. I'm a real-world kind of guy. Offering a quantized pressure altitude is realistic and makes sense. Having the encoder object also serve, optionally, as a backup altimeter (quantization steps and all) is also realistic and makes sense. The fact that this encoder instance (*not* the steam-gauge instance) can also be tricked into serving as an oracle for computing the Kollsman shift (by subtraction) is not entirely realistic, but is a natural by-product of the realistic features, so I'm happy to support this bit of trickery. Unrealistic features that increase the complexity, obscurity, and inefficiency need *some* kind of rationale, and I still haven't heard that. The two-instance solution has been available for many days now, along with instructions on how to use it. Why not just use it? ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
