Lazza
Registered
Niche application alert!
For testing purposes I've built a modified rF2 Shared Memory Map plugin that can output player telemetry at 100Hz (or higher, for selected telemetry).
I think most people wouldn't notice a difference in what they do (ok, I don't use overlays, maybe it'll show there; DDUs generally won't run fast enough to see anything). My particular use is on a motion rig run through SimHub, and I found that large roll motions (especially) had a stepping/notched feel to them. Eventually worked out that the SMM plugin is outputting data at 50Hz, while SimHub runs and polls the game at 60Hz.
The mismatch in speeds means that SimHub holds the same value across 2 updates every 1/10th of a second or so, which is surprisingly noticeable with low smoothing on motion
I imagine if an on-screen overlay is running at 60fps or higher this 'pause' will also be visible in some data; not something I use so can't say.
I've attached the test plugin, it's the standard filename as the intention is very much to replace the normal one if it's in use. Backup the original or use the original SMM archive to restore later (or just install via SimHub; it complains telemetry isn't configured properly with this one, but it works).
Anyway, if you put this one in it will create a new parameter in the CustomPluginVariables.json file, called NewRefreshMode.
It supports these values:
0 - normal behaviour
1 - player telemetry at 100Hz
2 - player telemetry at ~133Hz*
3 - player telemetry at ~400Hz*
4/5 - 'low latency' versions of 2/3 for testing. Not entirely recommended...
*the higher speed telemetry is limited to certain data relevant to my application, so basically vehicle position/velocity/accelerations, and engine&clutch RPM. This is done via interpolation, as rF2 data is only supplied at 100Hz, but I'm aiming to provide smoother where plugin/SimHub timing doesn't line up nicely. (options 4/5 actually extrapolate telemetry data - slightly dangerous!)
Options 2-5 can have X * 100 added to them (e.g. 102, 202, 302) which will increasingly forecast RPM to help sync displays with on-screen RPM lights. Not related to motion, just something that sometimes irks me so I'm testing a simple workaround. (doesn't work very well at the moment, at some point I'll refine it)
If anyone - and I mean anyone! - finds this at all useful or beneficial please let me know. At this point I suspect I might be all by myself
PS If this continues to test ok and I get it to a point where I'm happy with it, I may consider submitting it for inclusion in the official plugin. Given the lack of rF2 updates that's not strictly necessary currently, substituting the file in once isn't hard...
(also works for LMU, until they change how telemetry works)
For testing purposes I've built a modified rF2 Shared Memory Map plugin that can output player telemetry at 100Hz (or higher, for selected telemetry).
I think most people wouldn't notice a difference in what they do (ok, I don't use overlays, maybe it'll show there; DDUs generally won't run fast enough to see anything). My particular use is on a motion rig run through SimHub, and I found that large roll motions (especially) had a stepping/notched feel to them. Eventually worked out that the SMM plugin is outputting data at 50Hz, while SimHub runs and polls the game at 60Hz.
The mismatch in speeds means that SimHub holds the same value across 2 updates every 1/10th of a second or so, which is surprisingly noticeable with low smoothing on motion
I imagine if an on-screen overlay is running at 60fps or higher this 'pause' will also be visible in some data; not something I use so can't say.
I've attached the test plugin, it's the standard filename as the intention is very much to replace the normal one if it's in use. Backup the original or use the original SMM archive to restore later (or just install via SimHub; it complains telemetry isn't configured properly with this one, but it works).
Anyway, if you put this one in it will create a new parameter in the CustomPluginVariables.json file, called NewRefreshMode.
It supports these values:
0 - normal behaviour
1 - player telemetry at 100Hz
2 - player telemetry at ~133Hz*
3 - player telemetry at ~400Hz*
4/5 - 'low latency' versions of 2/3 for testing. Not entirely recommended...
*the higher speed telemetry is limited to certain data relevant to my application, so basically vehicle position/velocity/accelerations, and engine&clutch RPM. This is done via interpolation, as rF2 data is only supplied at 100Hz, but I'm aiming to provide smoother where plugin/SimHub timing doesn't line up nicely. (options 4/5 actually extrapolate telemetry data - slightly dangerous!)
Options 2-5 can have X * 100 added to them (e.g. 102, 202, 302) which will increasingly forecast RPM to help sync displays with on-screen RPM lights. Not related to motion, just something that sometimes irks me so I'm testing a simple workaround. (doesn't work very well at the moment, at some point I'll refine it)
If anyone - and I mean anyone! - finds this at all useful or beneficial please let me know. At this point I suspect I might be all by myself
PS If this continues to test ok and I get it to a point where I'm happy with it, I may consider submitting it for inclusion in the official plugin. Given the lack of rF2 updates that's not strictly necessary currently, substituting the file in once isn't hard...
(also works for LMU, until they change how telemetry works)