What are Non-Monotone Key Frames
Non-Monotone key frames are key frames where the key frame table is not in order. Here are some examples:
N1 ANGLE 0 50 50 270 100 230
This key frame table makes the angle of the needle increase as N1 goes up, but then the needle will reverse and go back down a bit. In this case, “angle” is non-monotone.
In this table for a a rotary;
enum image 0 0 1 2 2 1 4 3 3 4
Both the input and output are non-monotone.
When Would I Want Non-Monotone Key Frames?
Generally you’ll want non-monotone key frames under two cases:
- If an instrument has to move forward and backward in response to data (e.g. the N1 needle example above).
- If you need to remap the enumerated values for a rotary (e..g the rotary example).
When Are Non-Monotone Key Frames Allowed?
- The value (but not dataref) key frame column can be non-monotone as long as the instrument reads but does not write the dataref. So non-monotone output can be used for a needle as long as it is not draggable, for example.
- Rotaries may have non-monotone key frames for both input and output, as long as values are matched _exactly_ without interpolation.
Previewing Non-Monotone Key Frames in Plane-Maker
Plane-maker recognizes that if you have out-of-order non-monotone key framing tables then you are probably intending to use a dataref that EXACTLY hits the key frame, like an int dataref that passes in enums. (You would use this to re-order the mapping between enums and rotary positions.)
In this case Plane-Maker will snap-round the simulated dataref to exact key frames so that you can see a sane preview of the dataref.
If you have done this but the dataref in x-plane is NOT rounded to key frames, you will then see wrong interpolation in x-plane, since we can’t cleanly interpolate non-monotone functions!!