Howto talk:Build your own Panel or Cockpit - Software
Telnet get/set polling vs. listeners
Note that there is very simple support for using listeners, too. This is accomplished by using the subscribe/unsubscribe commands to get notifications whenever a property changes; under some circumstances this may be preferable/beneficial, i.e. for non-tied properties that change rarely: Telnet usage#subscribe and unsubscribe
This was originally implemented as a workaround for Improved J661 support#Patch prototype - while this functionality is not necessarily all that useful, the patch demonstrates that the underlying mechanism is fairly straightforward to extend/customize as needed. HTH --Hooray (talk) 10:22, 21 August 2016 (EDT)
I found when i did a general subscribe to instrumentation that there were several instruments that were constantly updating with changes that would not be observable in an actual cockpit. The calculation of these values appears to have too high a level of precision. Its likely that these values are being calculated in simgear, but not rounded after calculation. Whether they should be rounded in simgear itself or not is debatable. A small change like that could have unforeseen consequences, possibly with the autopilot engaged.
The impact on an attached cockpit though is we'd get a lot of noise when things are changing slightly and repeatedly. Possibly this should be rounded at the telnet source: Don't report a change unless it's significant. Pressure altitude 3.1 ft is near enough to 3.0 ft for instrument display purposes.
subscribe instrumentation (sample)
/instrumentation/altimeter/indicated-altitude-ft=2.327798529 /instrumentation/attitude-indicator/tumble-norm=0 /instrumentation/attitude-indicator/internal-roll-deg=0.1046475675 /instrumentation/encoder/mode-c-alt-ft=0 /instrumentation/airspeed-indicator/indicated-speed-kt=2.598276758 /instrumentation/airspeed-indicator/indicated-mach=0.003935676163 /instrumentation/airspeed-indicator/true-speed-kt=2.603332023 /instrumentation/altimeter/mode-c-alt-ft=0 /instrumentation/altimeter/pressure-alt-ft=3.52124289 /instrumentation/altimeter/indicated-altitude-ft=2.327798519 /instrumentation/attitude-indicator/tumble-norm=0 /instrumentation/attitude-indicator/internal-roll-deg=0.1046475675
- Yeah, that's a known "feature" - it's not an actual bug, it's because of the way listeners work, i.e. they're "dumb", they merely notice that something has changed, but don't actually take any threshold (or other heuristics) into account (in fact, you could write the same value back to the property, and it would still trigger the listener callback). It would be fairly straightforward, and useful, to adapt the patch accordingly - in fact, back when this was implemented (years ago), it was added in the comments, and I think it can still be found in $FG_SRC. Like you say, some kind of optional "threshold" should be easy to support. For details, refer to the patch. I think it should not require more than 15-20 lines of code to extend the subscribe command accordingly, so that it may optionally take custom heuristics into account. Equally, it would be possible to limit the resolution/interval of checks, and thus, update notifications (e.g. if you don't care about property changes more than once per second, and are only interested in changes exceeding a certain (display) tolerance. We kinda hit a similar problem back when we were with Canvas displays, that would basically update at framerate unnecessarily, despite heading/bearing changes being minischule (inviisble) in comparison. By the way, the mechanism itself is fairly dumb/simple, but I once also used it to easily sync a full /canvas sub-tree and replicate it in another fgfs instance. With this use-case in mind (think dual/shared cockpit, and multi-screen setups), it would actually be useful to adapt the original implementation accordingly, possibly by also supporting binary (UDP) notifications in a PUB/SUB fashion. --Hooray (talk) 17:35, 23 August 2016 (EDT)