Jon S Berndt writes: > How are switches usually handled in the property system? > Is there state defined by 0/1, or true/false? In the case > of rotary switches, I suppose those must be defined in a > 0...n manner, no?
When possible, it's nice to abstract the input more. For example, lets say that you have a transponder with a rotary switch labelled - OFF - SBY - ON - ALT When modelling that, you could have a property named /radios/transponder/knob-pos and set it to a number from 0-3, but it doesn't take into account the fact that other transponders may have different input methods, and it is not particularly descriptive. Instead, you should analyse the knob and figure out what it actually controls: 1. Is the transponder power on or off? 2. Is the transponder answering interrogations or not? 3. Is the transponder providing altitude (mode C) encoding or not? Then you create three separate boolean properties, one for each function, something like the following (I'm not sure what the other radios use): /radios/transponder/power /radios/transponder/active /radios/transponder/altitude The input binding system is sophisticated enough that we can map a knob position in a 2D panel instrument into the correct combination of these three properties, and later, if we model a different kind of transponder (say, one with a separate on/off switch), the properties will still look the same to the rest of FlightGear. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
