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

[ebeninca]

Maybe??

 

[Jernej Simoncic]

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.

 

[svictor]

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.

 

[Killian Lobato]

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

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?

 

[ebeninca]

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.

 

[svictor]

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

 

[EmperorOfFinland]

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.

 

[svictor]

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

 

[Hany Alsabti]

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.

 

[svictor]

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

 

[svictor]

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.

 

[Hany Alsabti]

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.

 

[ebeninca]

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.

 

[Hany Alsabti]

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, this is why the widget is complex...

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.

 

[svictor]

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)

 

[ebeninca]

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)

Yeah, recently I noticed that the LMU MFD pit screen utilizes absolute values, almost ran out of fuel one time. Makes sense to configure for abrefill.

 

[ebeninca]

@svictor first time I did a proper testing on "abfill" column data for the Virtual Energy Widget, and @Hany Alsabti is right, the info is broken...

I set a 30 min race with the BMW GT3 at Imola, my fuel configuration at the start was:

View attachment upload_2025-2-12_21-15-33.png

I did 2 laps, and took this screenshot...

View attachment upload_2025-2-12_21-12-55.png

Basically, at that point the "abfill" column value should be negative as the "refuel" was.

I think you should set abfill as default in VE widget, because it's the format that is showed in LMU MFD, and this widget isn't used in rF2.

 

[svictor]

From your screenshot, it's working as intended. The calculated value is not broken.

Absolute refill value will never go "negative", as this was specifically mentioned in the Additional info regarding absolute refueling section of this post (the spoil section) when "absolute refill" option was added.

This and related questions are also answered in github FAQ page here:
https://github.com/s-victor/TinyPed...ions#absolute-refueling-vs-relative-refueling

Here is some of the quotes:

Q: Why is absolute refueling value constantly decreasing while more lap distance is traveled?
Unlike relative refueling, absolute refueling shows the total amount fuel required to finish the remaining race length. When more lap distance is traveled (as more race length completed), there is less remaining race length to be done, so is less absolute total amount fuel value displayed. And absolute refueling value will never go below zero, unlike relative refueling value that excludes the fuel in tank and can be negative.

Q: How to know if there is more pit stop and refueling required with absolute refueling since the value cannot be negative?
The easiest way is by checking pits column in Fuel or Virtual energy Widget, which indicates amount pit stops required if making a pit stop at the end of current stint; or early column, which indicates amount pit stops required if making a pit stop at the end of current lap. See Fuel section in User Guide for detailed explanation.

Another way is by comparing remaining fuel value with absolute refueling value. If absolute refueling value is higher than remaining fuel value, then additional pit stops and refueling is required.

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

To some doubts about fuel calculation:

All fuel related calculation have been extensively tested in various conditions (hundreds of hours to say the least), the values you see from "Fuel, Virtual Energy, Relative Finish Order, Fuel Energy Saver Widgets" or "Fuel Calculator" are all using the same calculation formula and procedures. And those haven't been changed since v2.17.0 (more than half a year). If you believe there is any calculation error, please feel free to examine (or make correction) the source code on github.

Now to give more insight, the very basic formula (excluding all the other variables) for relative refilling is:
relative refilling = total estimated laps left * fuel consumption per lap - remaining fuel in tank

And absolute refilling is:
absolute refilling = total estimated laps left * fuel consumption per lap

So, absolute refilling value is actually calculated before relative refilling. And if "show absolute refilling" option is enabled, by subtracting "energy" from "abfill" column, it will give you the same value as relative refilling.

Some examples:

1. From your screenshot, energy is 92.95, abfill is 46.77, then relative refilling is:
46.77 - 92.95 = -46.18
which gives the negative value as expected in this case (and you can see that "pits" column is 0, that also indicates that no more pit stop required).

2. From this screenshot posted earlier:
Energy is 45.00, abfill is 26.32, then relative refilling is:
26.32 - 45.00 = -18.68
which this value is the same as the -18.7 value from 0s column of the Relative Finish Order widget (as below).

Of course, the driver also need to make sure fuel ratio is set correctly so they actually have enough "fuel" (besides virtual energy) to finish the race.

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

Thanks the suggestion about making "show absolute refilling" as default. My opinion is that it may be better for user to first understand what is going on with refilling in LMU (and check out info in FAQ & User Guide), then they can decide whether they want to enable it or not. As it could be very confusing for user to see both relative & absolute refilling value at the same time, especially if it's their first time using this APP.

Please free feel comment below, if more people think "show absolute refilling" should be enabled by default for Virtual Energy widget, I'll make it happen.

Cheers

 

[ebeninca]

From your screenshot, it's working as intended. The calculated value is not broken.

Absolute refill value will never go "negative", as this was specifically mentioned in the Additional info regarding absolute refueling section of this post (the spoil section) when "absolute refill" option was added.

This and related questions are also answered in github FAQ page here:
https://github.com/s-victor/TinyPed...ions#absolute-refueling-vs-relative-refueling

Here is some of the quotes:




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

To some doubts about fuel calculation:

All fuel related calculation have been extensively tested in various conditions (hundreds of hours to say the least), the values you see from "Fuel, Virtual Energy, Relative Finish Order, Fuel Energy Saver Widgets" or "Fuel Calculator" are all using the same calculation formula and procedures. And those haven't been changed since v2.17.0 (more than half a year). If you believe there is any calculation error, please feel free to examine (or make correction) the source code on github.

Now to give more insight, the very basic formula (excluding all the other variables) for relative refilling is:
relative refilling = total estimated laps left * fuel consumption per lap - remaining fuel in tank

And absolute refilling is:
absolute refilling = total estimated laps left * fuel consumption per lap

So, absolute refilling value is actually calculated before relative refilling. And if "show absolute refilling" option is enabled, by subtracting "energy" from "abfill" column, it will give you the same value as relative refilling.

Some examples:

1. From your screenshot, energy is 92.95, abfill is 46.77, then relative refilling is:
46.77 - 92.95 = -46.18
which gives the negative value as expected in this case (and you can see that "pits" column is 0, that also indicates that no more pit stop required).

2. From this screenshot posted earlier:
Energy is 45.00, abfill is 26.32, then relative refilling is:
26.32 - 45.00 = -18.68
which this value is the same as the -18.7 value from 0s column of the Relative Finish Order widget (as below).

Of course, the driver also need to make sure fuel ratio is set correctly so they actually have enough "fuel" (besides virtual energy) to finish the race.

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

Thanks the suggestion about making "show absolute refilling" as default. My opinion is that it may be better for user to first understand what is going on with refilling in LMU (and check out info in FAQ & User Guide), then they can decide whether they want to enable it or not. As it could be very confusing for user to see both relative & absolute refilling value at the same time, especially if it's their first time using this APP.

Please free feel comment below, if more people think "show absolute refilling" should be enabled by default for Virtual Energy widget, I'll make it happen.

Cheers

Ok, now I got it !!!

 

[Timotej Andonovski]

Would anyone be able to help me? VE calculations are stuck on 0.00. Fuel calcs are fine, and every other widget works as intended, but VE is stuck on zero.
Enabling all modules does not help.