kaiusl
commented
8 months ago Before I rebase and or rebuild (potentially into multiple PRs) this I wanted to ask. Firstly if I should do this at all.
I would be happy to accept PRs that implement multi game support.
But then in terms of design especially how and if other game multiclass should be handled, as it would require in the UI the ability to add more classes, perhaps require defining car names that would be put into the class (for AC for example), but especially the car classes could no longer be handled by an Enum.
I suppose we could use a dict to map between car and class and other properties, shouldn't be too much of an issue. Then we could use some kind of data files that define the mapping, say car name,pretty name,manufacturer,class name.
We'd provide some definitions from the plugin side and then accept another file where the user can add it's own definitions and overrides if needed.
I think a simple config file would suffice for start. UI option could always be added later.
We would also need to add a way to generate lap data for proper gap calculation on the fly (well I was thinking of adding this anyway).
Currently the other game support is run by in large parts emulating the way the websocket messages would be reencoded into classes like RealtimeUpdate (but instead using another constructor that takes the simhub data to construct it) using the ProcessViaSimHub function in Values.
How well does this approach work? Are there any weird edge cases? The logic is based on how ACC handles things and I suppose other games could have major differences there.
Also what games have you used it with?
For the other things that can be turned into other PRs:
ACC driver swap work around:
SimHub thinks the game is no longer "running" if you are not actively driving. While you can swap SimHub to spectator mode, to remember to swap this back prior to the driver swap is difficult and cumbersome (also causes all plugins to reload)
- So, if the game is ACC, and our websocket is not already connected, and SimHub doesn't think ACC is running, then check the Windows API to see if we can find the process running, if it is try connect (if it fails we retry after a bit)
- That win api poll is slow (5ms), but because it only triggers when the game truely isn't running we don't need to worry about causing SimHub to drop updates
- Obviously data like session time or session time are not updated, we do have these values from the websocket, so could add them as propertys (I did a hack workaround for Session Time Remaining)
Apparently I added at some point actions that swap the leaderboard into specfic modes (instead of having only cycle actions)
Some fixes for Values going out of bounds (like my most recent commit to make a workaround for GT2)
I think all of these are nice improvements and any of them would be welcome as a PR.
I have been maintaining a personal fork to allow me to use this leaderboard plugin for all my streams, even if the game is not ACC (and also address some short comings). https://github.com/LukasLichten/KLPlugins.DynLeaderboards/tree/generalized
However it is currently not in a state of being turned into a PR:
Before I rebase and or rebuild (potentially into multiple PRs) this I wanted to ask. Firstly if I should do this at all. But then in terms of design especially how and if other game multiclass should be handled, as it would require in the UI the ability to add more classes, perhaps require defining car names that would be put into the class (for AC for example), but especially the car classes could no longer be handled by an Enum.
Currently the other game support is run by in large parts emulating the way the websocket messages would be reencoded into classes like RealtimeUpdate (but instead using another constructor that takes the simhub data to construct it) using the ProcessViaSimHub function in Values.
For the other things that can be turned into other PRs: