David Megginson wrote:
Julian Foad writes:OK -- thanks. I have now fixed up all the other XML files in the base package accordingly.
> I attach a patch which does these, and an update to navcom-radio.xml > which specifies "resolution" appropriately and sets "max" to 118 or 136 > instead of 117.95 or 135.975. Other files will need to be updated > similarly; how is this for a start? It seems to work without skipping > values.
Committed -- thanks.
But what have I got myself into? I have introduced special handling of discrete values (by specifying the new tag "resolution"), but I haven't resolved the inconsistencies between the four cases:
- Analogue Clamped: min <= x <= max (this makes sense)
- Analogue Wrapped: min <= x < max (this makes sense)
- Discrete Clamped: not available (why not?)
- Discrete Wrapped: min <= x < max (matches analogue case but is unintuitive)
What we have is sensible behaviour for analogue values but not for discrete values.
It is silly not to have Discrete Clamped behaviour available. The sensible definition of it, from the meaning of the word "maximum", would be "min <= x <= max". But it would also be sensible to be able to switch between "wrapped" and "clamped" without changing the value of "max".
Discrete Wrapped behaviour is now stable in the presence of floating-point error (when "resolution" is specified to mark it as being a "discrete" value), and its definition (meaning of "max") matches the analogue case which I thought was a good idea. However, the meaning of "max" here is not the intuitive meaning of the word. I said before that the "max" value specified should not depend on the (variable) step size, but now we have a fixed "resolution" which it could depend on. We could specify "min=108, max=117.95, resolution=0.05" unambiguously with an intuitive meaning of "max". In this example the range finishes just before a round number, and it would be nicer to be able to write something like "<lessthan>118</lessthan>" instead of "<max>117.95</max>". When the range finishes on a round number, such as (say) engine number 1 to 4 inclusive, then we want to write "min=1, max=4" and for this to mean 1 to 4 inclusive, regardless of whether it is wrapped or clamped.
This leads to:
- Analogue Clamped: min <= x <= max
- Analogue Wrapped: min <= x < max (we could allow or require "lessthan" instead of "max")
- Discrete Clamped: min <= x <= max or min <= x < lessthan
- Discrete Wrapped: min <= x <= max or min <= x < lessthan
This seems reasonable from a user's point of view, but at the cost of another new tag ("lessthan"). Is there a simpler way to handle discrete values?
We could store the discrete value (e.g. radio frequency) as an integer (e.g. 108000 to 117950 kHz in steps of 50, or channel number 0 to 199). How would we _like_ to specify these?
- frequency: min=108000, lessthan=118000, step=50 or 1000 (but doesn't lend itself to an analogue adjuster unless we also specify resolution=50)
- channel: type=integer, min=0, lessthan=200 (wrapped or not)
- channel: type=integer, min=0, max=199 (wrapped or not)
- engine: type=integer, min=1, max=4 (wrapped or not)
By storing a channel number rather than an frequency, we can make use of the existing property attribute type="int" to provide the snap-to-valid-value behaviour, rather than the "resolution" tag. But then we have to convert the cahannel number to a frequency for display and for output. This also requires that the property manager handles integers in an appropriate manner, such as rounding to the nearest integer when converting from floating-point representation. So maybe that wouldn't be easier after all.
What to do? Implement "lessthan"? Or don't implement any support for discrete values in the property-adjust commands, but let the radio-specific C++ code take care of it in the getter and setter functions tied to its frequency properties?
- Julian
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
