[REL] TinyPedal - open source overlay for rF2 (Pacenotes,Radar,FFB,Deltabest,Relative,Fuel Calculator)

I've had optimisations off already. But something happened and after some restarts gsync just worked in LMU. I think made game fullscreen, tried again, realized overlay won't even work on fullscreen, went back to borderless, and at some point I just spotted g-sync indicator being on.

I think it just instantly worked once I went into rF2.

 

I have another problem actually. The Delta is jumping up and down like crazy (well like +-30ms), and if I increase the filtering, it still jumps, just less, and is less and less precise.

 

Hey there, just tried to open tiny pedal and this came out. I'm attaching the log as well.

View attachment upload_2025-1-29_22-27-48.png

 

Gsync indicator being on doesn't always mean that gsync is truly on. The real test is to check for the stutters in the background when moving slowly left to right in the pits for example. If u see frames skipping/juddering while gsync indicator is on, thats a false positive. The image should be butter smooth if gsync is truly active.

For now the only way to make tiny pedal compatible with gsync is for the developer to implement this functionality.

Discussions can be found here. Not sure if this is helpful https://forums.blurbusters.com/viewtopic.php?t=9592

 

@emd86 Thanks, it's a very rare bug found in one of the old version of psutil library before 6.0.0 (mentioned here: https://github.com/giampaolo/psutil/blob/master/HISTORY.rst#600 ), as this APP is currently using psutil 5.9.6 in released file which is affected by this bug. Next update will be using latest psutil version (6.1.1) which fixes this issue.

For those using "run from source", you can run following command to update psutil version:
pip install psutil -U

---

@Jernej Simoncic Delta data fluctuation can happen in two notable cases:

1. If Sharedmemory API access mode is set on 1 (direct access), then there is almost 100% chance to get Delta (or other) data fluctuation during multiplayer session, because direct access mode is not protected against data desync issue (in multiplayer), and is not recommended to use. Double check Sharedmemory API setting, and make sure access mode is set on 0 (copy access) that helps avoid data desync issue.

2. If game's Time Acceleration is activated while Deltabest data was recorded, then Delta data fluctuation can happen because a lot of data is not recorded "in time" due to "Time Acceleration", as there is a hard limit to recording & API data update interval (50fps, or 20ms) which effectively causes recording "skipping". So if you want accurate deltabest data to be recorded, avoid activating "Time Acceleration".

In any case, to fix fluctuation on existing deltabest data, go to main menu > Reset Data > Delta Best to reset inaccurate Delta data, and re-record a new best laptime.

 

Maybe??

 

Regarding Gsync - it was in fact butter smooth. Then I've got a bug (that I've had before) where framerate would drop to half of the refresh rate. So I updated gpu driver and now gsync indicator doesn't turn on again. But it's still butter smooth and limited to 138fps by something in nvidia settings....

And about the jumping delta - I've not recorded delta on time acceleration and I've checked that the Access Mode in config menu is at 0. Thing is this always happens on every track.

 

Minor fluctuation (within 50ms) is normal behavior. The reason for this is that there is a hard limit in driver's distance position (meters into current lap) update rate in API, which is limited/capped at 5fps (200ms), that means driver's distance position only updates every 1/5 of a second, which is extremely inaccurate if use directly for delta calculation (deltabest consists a large amount historic time values each relative to distance position value).

And in order to solve this 200ms limit issue, a special calculation method is added to compensate it, which is:

While during this 200ms hard limit, this APP actively recording driver's global position coordinates data and calculate Euclidean Distance delta, then add it on top of the distance position, which gives a new estimated distance position during this 200ms time frame. (Note, this global position coordinates data is updated at 50fps/20ms from API , which is updated 10 times more frequent than distance position data from API.)

However, because driver/vehicle does not always travel forward along the center line of the track (for example, in extreme case, he may drive backwards), that means this estimated "Euclidean Distance" delta value that added to "distance position" value (that is waiting for the next update in 200ms) can be slightly inaccurate, though it is accurate enough in most cases. That is the ultimate reason that you see this minor delta fluctuation, that's why there is an option for user to set smoothing for filtering out this minor fluctuation.

There are many similar stuff such as this one to workaround various limitation with game's API.

 

Hi Hany,
Thanks for the input. I have confirmed that when TinyPedal is off and GSync in on, that frame delivery is buttery smooth. The FPS caps at 59FPS, bellow the V-sync limit, and the FPS can drop bellow 59FPS and still feel smooth when GPU is overloaded. Maybe because most people are playing RF2 with 144Hz monitors, then microstuttering is not visible. In your case, what setup do you run? Are you able to replicate what I have shown?

 

Yeah, this is an old rFactor2 problem, long before Tinypedal, 60 fps causes visible microstuttering, for me 120 fps is the minimal, even in 60hz monitors. Weird, but it is what it is.

 

2.24.0 (2025-02-06)
https://github.com/s-victor/TinyPedal/releases/tag/v2.24.0

• General
  • Add log info for showing various style presets loading status.
  • Unified preset backup file name format.
  • Add preset file validation for "classes.json" and "compounds.json".
  • Removed "tyre_compound_symbol" option from "units" config.
• [New]Compounds Preset
  • Add new "compounds.json" preset file in "settings" folder, which is used for displaying custom
    tyre compound symbol and heatmap style that matches specific tyre compounds.
  • Add default tyre compound styles for all tyres currently found in "LMU".
  • Add default tyre compound styles for some popular vehicles found in "RF2".
  • Add tyre compounds auto-detection system, which automatically adds missing tyre compounds found
    from all running vehicles to "compounds.json" and assigns closest matched compound symbols.
    A "?" symbol will be displayed if a compound name is not commonly known.
  • "compounds" file name is now reserved for "compounds.json" preset.
• [New]Tyre Compound Editor
  • Add "Tyre Compound Editor" to "Tools" menu in main window, which allows customizing "compounds.json" preset.
    See User Guide "Compounds preset" section for complete usage.
• Classes Preset
  • Extended classes preset structure to support more customization in future.
    The new structure now saves alternative "class name" under "alias" key, and "class color" under "color" key.
  • Old "classes.json" file will be auto-updated to this newer structure,
    and a "classes.json.old" backup file will be created in "settings" folder.
• Vehicle Class Editor
  • Now shows customizable classes styles in table view, including "Class name", "Alias name", "Color" columns.
  • Now supports multi-selection for deleting multiple classes.
  • Now supports classes sorting.
• Delta, Energy, Fuel Module
  • Add "minimum_delta_distance" option, which sets minimum recording distance (in meters) between each delta sample.
    Lower value may result more samples recorded and bigger file size; higher value may result less samples recorded and inaccuracy.
    Default value is "5" meters. Recommended value range in "5" to "10" meters.
  • Improved calculation and significantly reduced data fluctuation.
• Relative, Rivals, Standings Widget
  • Now shows tyre compound symbols (front and rear) that matches specific tyre compounds defined in "compounds.json" preset.
• Tyre carcass, Tyre inner layer, Tyre temperature Widget
  • Add "enable_heatmap_auto_matching" option, which enables automatically heatmap style matching
    for specific tyre compounds defined in "compounds.json" preset.
    This option applies matching heatmap style to front and rear tyre compounds separately.
    While this option is enabled, "heatmap_name" option has no effect. This option is enabled by default.
    Note, separate compounds info for tyres on the same axle is not available from game API,
    which currently it is not possible to show left and right compounds separately.
  • Now shows tyre compound symbols (front and rear) that matches specific tyre compounds defined in "compounds.json" preset.
• Misc
  • Updated User Guide info for related changes above.

--------------------------------

Q: Is it possible to add all tyre compounds at once from all vehicle mods found in game?
A: Unfortunately, currently there is no way to do that. Also note, tyre compound data are only updated while driver is "on track", that means changing tyre compound in setup page without exiting garage will not update tyre compound data.

Q: Do I need or must use "Tyre Compound Editor" to add missing compounds?
A: That is not necessary, as there is an auto-detection feature that automatically adds missing compounds from all drivers (who are on track, including you) in an active session to compounds preset, and automatically converting common compound names to symbols. Just make sure to go out of garage after changed compound in setup page to have that compound automatically added to compounds preset.

Q: Is it possible to show compounds for left and right tyres separately?
A: Unfortunately, separate compounds info for tyres on the same axle is not available from game API, which currently it is not possible to show left and right compounds separately. And due to this limitation, for example, when you set left tyre compound differently than right compound, the API will only output and show compound info from left tyre.

Q: Are there plan to add heatmap auto-matching feature for brake temperature as well?
A: Hopefully it will probably be done at later time.

Compounds preset & Tyre compound editor guide:
https://github.com/s-victor/TinyPedal/wiki/User-Guide#compounds-preset

 

I have been thinking would it be possible to have a RPM rev counter for the GEAR widget ie that you can use it for RPM if the car would lack RPM counter on it or so on. So for example you could use it to fuel save by easily seeing when to shift up and down. Ie that you could have RPM bar but also the engine RPM counting on it?

Otherwise it works very well in VR and i have been enjoying using this.

 

Thanks, I will try add RPM reading to gear widget in next update.

 

Hi, I just wanted to report that the Tiny Pedal fuel calculation at Le Mans seems to be highly inaccurate.

In two races with fuel usage set to x2, Tiny Pedal's Abrefill suggested I take 15% VE to finish the race. However, it was impossible to complete a lap with 15% VE unless I lift-and-coast the entire lap, losing over 5 seconds in the process.

I had the option to show absolute refill turned on.

 

Please share more detail about which cars you were driving, plus session setup and also best with screenshots of both fuel refill usage & energy refill usage data. Also it is recommended to use Fuel Calculator from Tools menu to plan fuel/energy before the race to minimize possible margin of error.

Besides, it is highly likely related to the leader's estimated finishing position that different from your estimated finishing position, which there is a chance that if you are "relatively" ahead of the leader at the moment when race timer ends, you have to do an extra lap. If that is the case, you should consider use "Relative Finish Order Widget" to know whether there is a "chance" of extra lap due to difference of leader's relative finish position (in case you really want to squeeze that little advantage and save time; or else, just add an extra lap of fuel for the safe side).

All previous discussions about the relative finishing position issue can be found in following posts:
https://forum.studio-397.com/index....ve-fuel-calculator.71557/page-36#post-1145024
https://forum.studio-397.com/index....ve-fuel-calculator.71557/page-36#post-1145191
https://forum.studio-397.com/index....ve-fuel-calculator.71557/page-43#post-1148267

It may seems complex at first, but it is not difficult to use this "Relative Finish Order" widget after take some time to check out the explanation & usage guide. See full guide here:
https://github.com/s-victor/TinyPedal/wiki/User-Guide#relative-finish-order

 

Here are some visualized examples of the relative finish position issue that may or may not result extra final lap(and extra required fuel) for player.


In example 1, estimated leader's relative finish position is 0.10 (10% into lap), and estimated your(player) relative finish position is 0.90 (90% into lap). Because 0.90 > 0.10, it indicates that you are relatively ahead of leader when timer ended, which would require you to do an extra lap (and that requires an extra lap of fuel).


In example 2, estimated leader's relative finish position is 0.20 (20% into lap), and estimated your(player) relative finish position is 0.25 (25% into lap). Because 0.25 > 0.20, it indicates that you are relatively ahead of leader when timer ended. However, if we assume the average lap time difference is 0.10 (10% per lap) between leader (LMH) and you (LMGT3). Then it is 0.25 - 0.20 = 0.05 (5%) lap time difference when timer ended, and since 10% > 5% that means leader can overtake player on his final lap, so there is no extra final lap for player.


In example 3, estimated leader's relative finish position is approximately between 0.98 to 0.01 (98% to 1% into lap), and estimated your(player) relative finish position is 0.90 (90% into lap). Because leader is very close to finish line when timer ended, there is chance that leader may drive fast enough to catch up that 2% lap time distance before finish line, and initiate an extra final lap when timer ended. So it could result either 0.98 (leader) > 0.90 (you) that no extra final lap; or, 0.90 (you) > 0.01 (leader) that need extra final lap.


Finally, Relative Finish Order widget is provided to show you all those estimated relative finish position and lap time difference values that helps determine the chance of extra lap and whether extra amount refueling is required.

Note, your (local player's) fuel & refueling values (that shown on fuel & energy widget) are always calculated from your own fuel usage and lap time pace. This calculation does not take other player's performance (that handled by Relative Finish Order widget mentioned above) into consideration.

 

Thanks for the additional information. This widget is quite complex tbh.

I main the gt3 class and I've no information whether the leader in the faster class still needs to make a pitstop or not, and if he does, how long that pitstop will be.

Ideally, I need to know early in my last stint if there is a chance for an extra lap to have enough time for saving VE.

 

Predicting if one extra lap will happen is almost impossible, you never know when the leader will crash or run out of fuel in the end changing everything, breaking the info that the widget is giving to you...

I have been using tinypedal for a long time now, I prefer to focus on the "refill" column in the VE widget, I think it's easier to manage during the race, you wanna have this value equals "minus one lap of VE", e.g. if your consumption is 3% a lap, you always want to keep the refill column at -3, it's a safer position which guarantees that you'll never run out of fuel.

 

I'm using the ABrefill column and it would be nice if that column also shows minus when there is more than enough VE left. Currently it doesn't.

 

Thanks, these are some nice points. In real racing or team based e-sports, there are usually a team of people helping the driver analyzing those data in the background while the driver can focus on driving, which is difficult to do for casual player. But either way, "extra lap" is always an unstable variable, and in the end someone has to make the decision to either add more fuel or add less and save fuel, which may or may not work out, as part of the racing.

Relative Finish Order Widget also provides "show absolute refilling" option, so you can have both relative & absolute refilling displayed by:

Set Fuel (or Virtual Energy) Widget to "show absolute refilling", and then set Relative Finish Order Widget to not "show absolute refilling", or you can set them the other way around. Note, the 0s column from "Relative Finish Order Widget" always shows exact same-calculated refilling value as seen from refill column on "Fuel or Virtual Energy Widget".

You can also simplify Relative Finish Order Widget display, by setting "number of prediction" option to 0 or 1, so there is less data on widget, such as below that shows only 3 columns of prediction:


("0s" column here is for no pit stop, "30s" column is the custom pit stop duration, last column shows leader's/player's last recorded pit stop duration)