Limiting State data, for bandwidth and less cluttered UI

[mpaperno]

Continued from #42 (comment)

One improvement I was considering is that if you notice there is a lot of watching and
transmitting of data to Touch Portal. I theorized that eventually it would be too much data
and would cause performance issues. I was considering a way for the user to be able to enable
what states they want to watch for, so they have control over that.

Originally posted by @tlewis17 in #42 (comment)

Regarding the States data, I agree. Besides the data exchange issues (wonder if they implemented compression yet?), having so many states (which the user may have no interest in) also makes the UI more cumbersome. Especially where in some cases the TP UI doesn't break them up into categories in the selector. We could generate the states dynamically, only the ones the user wants.

But... how to configure this on the user side. I guess simplest would be a text file with all the states and the user can "comment out" the ones they don't want. Then someone can build a UI to edit that file more easily ... :-) But one issue with that is what happens when the available states list is updated... do we modify the user's config file, or... ?

-Max

[tlewis17]

I considered a simple http listener/browser UI that would modify the appsettings.json. But I haven't looked too far into that. But it would take extra config the user may or may not be aware of. Another option that I wonder if it is possible is for us (either by TP telling us or by us asking TP) what all the variables are that are in use.

[mpaperno]

A real-time method to modify the available states would be cool, sure would beat having to reload the plugin for each change. An HTTP server/Web UI is also a nice idea, and perhaps could be used for other types of interaction down the road. Perhaps even do "double duty" by replacing some other MSFS clients like for a basic map view.

But yea on config... the plugin would still need to work "out of the box" and how many users will actually go to the trouble to turn off states just to save some bandwidth? Or the alternative is to force the user to enable states they need (perhaps with a default set of enabled ones).

The problem with anything saved in the plugin folder structure itself, like configs in appsettings, is they'll get overwritten during the next plugin update (barring having an actual installer, anyway). Anything persistent needs to live elsewhere (some user-accessible location, like AppData or Documents if the config will be editable by hand).

[mpaperno]

Another option that I wonder if it is possible is for us (either by TP telling us or by us asking TP) what all the variables are that are in use.

That would be nice, but... It may be worth asking the TP devs, but I'd be pretty shocked if they had some API for that. But maybe they'll like the idea. The only thing that comes to mind offhand for now is parsing all the user's pages in TP config folder to see which states are used. Pretty ugly... and has it's own issues like when to rescan for changes. And all the states would still need to be in the available states list so the user can select them in the first place.

[mpaperno]

Have you seen this? https://github.com/Dragonlaird/SimConnectHelper

The library is nice, but he's got a complete (?) set of all SimVar definitions in there... https://github.com/Dragonlaird/SimConnectHelper/blob/master/SimConnectHelper/Common/SimVarUnits.cs

And the Demo project has a form-based UI where you can browse all the SimVars and monitor them at various frequencies (and update the writable ones). We'd basically just need to add a checkbox or something for each var for "send to Touch Portal"... :-) We could probably set it up so that literally any of the Sim vars could be sent as a TP state, the list as needed on the fly.

[tlewis17]

Have you seen this? https://github.com/Dragonlaird/SimConnectHelper

The library is nice, but he's got a complete (?) set of all SimVar definitions in there... https://github.com/Dragonlaird/SimConnectHelper/blob/master/SimConnectHelper/Common/SimVarUnits.cs

And the Demo project has a form-based UI where you can browse all the SimVars and monitor them at various frequencies (and update the writable ones). We'd basically just need to add a checkbox or something for each var for "send to Touch Portal"... :-) We could probably set it up so that literally any of the Sim vars could be sent as a TP state, the list as needed on the fly.

I've used an older version of that kind of thing. It is very helpful to see what variables control what while in game.

[tlewis17]

I added you as a collaborator. There is a Touch Portal MSFS organization I created too, at one point we were going to have the Plugin plus various page layouts under that organization, but all the page developers disappeared. I wonder if I should move it back there.

[HiDTH]

Hi Guys
After over a year or moving house and not having had any spare time, I am now back flying on the Sim. I have been working on updating the FltSim 2020 page to add new functionality and to utilise some of the new logic available within Touch Portal. I really appreciate the work that you guys do and look forward to working together to create something that folks find even more useful. Thanks Max for the changes that you have made to the plugin - some of which I was about to ask for and realised you had included them already. I have added a number of additional feature requests to your Plugin branch - but I can add them here as well if you want me to Tim.

[mpaperno]

Thanks Tim, I'm honored! Now watch out... muahaha... :-P

Denham, just wanted to say thanks again, here, for your pages. They inspired/encouraged me to try out this plugin. Your suggestions are well received As long as we're active on this one it's probably best to consolidate here, but either way it's good to have feedback.

---

Back to the topic, I'm really liking the idea of users selecting the data they want to see... basically make this plugin like a proxy between SimConnect and TP. There's probably no realistic way we could include every piece of data everyone may want (or just want to test), and still have a manageable list in TP (especially those parts where they aren't sorted, but that really needs to be fixed in TP). So having the user select what they want from a nice UI, with a clear preview of the value (when sim is running), would be great.

Also, I like the idea of setting the data request frequency per value. Some things need rapid updates, but many don't. This could really go a long way in conserving bandwidth and getting the important data to the user faster.

I know it's not web based, but honestly that UI from the screenshot is almost perfect. I'd like to see the values sorted into groups, and a few other niggles, but basically it's all there. I mainly brought this one up since it's already in .net/c#... and at east that struct of all available vars is just begging to be used... :-)