First of all, thanks for an awesome plugin! It really opens up a lot of possibilities for third-party services.

While working on KeRD I've noticed that for interactive stuff like the navball and orbital properties (ap/pe in particular), having a 500-1000ms delay can be a bit too much, and it's a bit risky watching the Telemachus values if your ap/pe or orientation change quickly.

1. I've been thinking that it would be nice to be able to subscribe to different data values at different rates (not everything is as useful to receive at a higher rate), so you'd be able to refresh e.g. the navball at 10hz and the rest at 1-2hz. Would such a feature be possible/difficult to implement?
2. Do you have any benchmarks for higher global data refresh rates? Would it be possible to have e.g. a 10hz global refresh rate for all the data points available without impacting the game noticeably? I haven't succeeded in decreasing the interval below ~500ms even with rate values like 50-100ms, but I'm not sure if the data rate is capped by Telemachus or the game.
3. I'm guessing that past a certain point, JSON serialization will impact the plugin and/or interfaces to the point that performance will drop in-game. Would it be possible to implement some sort of lightweight alternative to JSON (e.g. msgpack or BSON) for higher rate data streams?

1. This shouldn't be too hard to implement and I've already sketched out a design.
2. I've only performed qualitative tests, in that I've seen navballs being driven by Telemachus without any noticeable lag or performance impact on the game. However, this was while only pulling down a couple of values and I suspect a solution to 1. will help the situation.
3. It will be possible but it's not something I plan to do until I actually have some proper benchmarks written. I guess these proper benchmarks would be useful to test the impact of 1 ...

If I get time this weekend I will implement some benchmarks and a solution to 1.

I have implemented a benchmark for the web socket server, which will allow me to sweep combinations of API strings and data rates. The benchmark reports the requested rate (milliseconds), the obtained interval (milliseconds) and the average FPS of the game during the test period. So I'll be able to identify any API calls which affect the obtained interval and impact the FPS.

Sample output:

api string: Array[3]
0: "r.resource[oxidizer]"1: "v.altitude"2: "g.fps"length: 3__proto__: Array[0]
average fps: 59.798453596638694
obtained: 16.80672268907563
requested: 1

The rate at which the web socket server sends data is tied to the frame rate, which why the obtained interval peaks at about 16 milliseconds for ~60FPS.

Now I need to throw together a good test regime.

I primed the benchmark using all the API strings used by KeRD (except TAC resources), and the results show that you should be able to pull data back at the games FPS (rates between 33 and 16 milliseconds for 30 - 60 FPS respectively).

I'll release the benchmark tomorrow so you can run it for yourself and check I've made no errors. I expect your could throw your own benchmark together in about 10 minutes though.

That's awesome, thanks a lot for looking into this! Let me know if you need any help with testing.

Excellent, I doubt it will be necessary to receive the data that often though, as repainting in the browser is expensive as well. I think a refresh rate of about 10hz should be sufficient for KeRD at least. It would be nice to have the ability to match the in-game refresh rate if you have a powerful computer, so I'm glad to hear that it runs well even with higher refresh rates.