[REL] TinyPedal - open source overlay for rF2 (Pacenotes,Radar,FFB,Deltabest,Relative,Fuel Calculator)
Jernej Simoncic
Registered
I've got a weird problem with LMU Hypercar mediums not displaying correctly. Wets and hards work fine, but if I put mediums on the car, it assumes I've got hards.
davehenrie
Registered
svictor annwers now in Github
Tale a look to this post
https://forum.studio-397.com/index....ve-fuel-calculator.71557/page-47#post-1149384
Diego Barjollo
Registered
Hi, a friend who's using VR can't run the program. Can you confirm it's just open the overlay menu and mark "VR compatibility"? That's all he need to start it?
svictor
Registered
Thank you guys, all comments and thoughts and helps are greatly appreciated as always. @Corti Thanks mate for helping posting update log.
@Jernej Simoncic
This was a known game API bug from February update, and only game developer can fix it.
Unfortunately, it appears that there wasn't much attention on this issue so far. Please consider report or comment in following linked post, so that there may be higher chance it will be fixed sooner by game developer if more people reported it:
https://community.lemansultimate.co...ound-name-for-hyper-class-while-driving.6224/
@Diego Barjollo
VR Compatibility option does not by itself support to show overlay in VR.
You will still need a third party program (such as OpenKneeboard) to project overlay windows (widgets) into VR.
VR Compatibility option simply enables the ability for those third party programs to discover and project overlay windows into VR. If VR Compatibility option is disabled, then those third party programs may not be able to detect overlay windows, hence this option is provided.
Those info are now added to FAQ page as well:
https://github.com/s-victor/TinyPedal/wiki/Frequently-Asked-Questions#q-how-to-display-overlay-in-vr
As usual, you can post your urgent issues or questions or suggestions on github issues page, as I won't be able to visit the forum often:
https://github.com/s-victor/TinyPedal/issues
@Jernej Simoncic
This was a known game API bug from February update, and only game developer can fix it.
Unfortunately, it appears that there wasn't much attention on this issue so far. Please consider report or comment in following linked post, so that there may be higher chance it will be fixed sooner by game developer if more people reported it:
https://community.lemansultimate.co...ound-name-for-hyper-class-while-driving.6224/
@Diego Barjollo
VR Compatibility option does not by itself support to show overlay in VR.
You will still need a third party program (such as OpenKneeboard) to project overlay windows (widgets) into VR.
VR Compatibility option simply enables the ability for those third party programs to discover and project overlay windows into VR. If VR Compatibility option is disabled, then those third party programs may not be able to detect overlay windows, hence this option is provided.
Those info are now added to FAQ page as well:
https://github.com/s-victor/TinyPedal/wiki/Frequently-Asked-Questions#q-how-to-display-overlay-in-vr
As usual, you can post your urgent issues or questions or suggestions on github issues page, as I won't be able to visit the forum often:
https://github.com/s-victor/TinyPedal/issues
Diego Barjollo
Registered
Understood, thanks for the reply.
svictor
Registered
@Flavio Giunchi I saw you have also posted your question on github. Unfortunately, I don't have VR so it is impossible to help you with VR problem. And there is low chance to get answers for VR problem on github, since currently I'm the only active developer.
Also note that Radar widget is no different from any other widget, so if radar doesn't show, you might want to check your widget setting (such as widget's position, auto-hide setting), or the setup in other VR APP that projecting the widget.
And you may have better luck asking VR related questions directly from others who use VR and have been running this APP successfully in VR. There were quite few people have shared how to setup "CrewCheif" or "OpenKneeboard" to work with VR from previous posts in this thread, or check out other places such as discord see if anyone willing to help.
For reference, the most recent video about how to run tinypedal with "OpenKneeboard" in VR can be found in this page:
https://github.com/s-victor/TinyPedal/pull/73
Also note that Radar widget is no different from any other widget, so if radar doesn't show, you might want to check your widget setting (such as widget's position, auto-hide setting), or the setup in other VR APP that projecting the widget.
And you may have better luck asking VR related questions directly from others who use VR and have been running this APP successfully in VR. There were quite few people have shared how to setup "CrewCheif" or "OpenKneeboard" to work with VR from previous posts in this thread, or check out other places such as discord see if anyone willing to help.
For reference, the most recent video about how to run tinypedal with "OpenKneeboard" in VR can be found in this page:
https://github.com/s-victor/TinyPedal/pull/73
Last edited:
svictor
Registered
v2.28.0 (2025-05-05) update
https://github.com/s-victor/TinyPedal/releases/tag/v2.28.0
After weeks of development and testing, I'm now happy to share with you all the latest major addition to TinyPedal, the new Pit Stop Estimate Widget, designed specifically for LMU.
This new widget helps solving the two notable issues:
With this new widget, you can now easily find out:
Notable features:
Show estimated pit-lane pass through (drive-through) time, calculated from pit-entry to pit-exit line. Average accuracy is within "0.5" seconds. Note, for any new tracks, at least one pit-lane pass through is required to record data for pass through time calculation.
Show estimated pit stop time while making a service stop or serving a penalty, calculated according to each setting from MFD "Pitstop" page and underlying service timing and concurrency differences. Average accuracy is within "1" seconds.
Show maximum total random pit stop delay which game may add on top of pit stop time. For example, if estimated pit stop time is "12.0"s, and maximum delay is "+3.0"s, then final pit stop time will be between "12.0"s and "15.0"s.
Show estimated minimum total pit time, which is the sum of "pass_duration", "stop_duration", and "additional_pitstop_time". Note, this reading is recalculated only while not in pit lane.
Show estimated maximum total pit time, which is the sum of "minimum_total_duration" and "maximum_delay". Note, this reading is recalculated only while not in pit lane.
Show pit timer, useful for comparing against other pit time readings.
Show actual relative refilling, as the total additional fuel or virtual energy that will be added in next pit stop according to remaining fuel or virtual energy and user refill setting from MFD "Pitstop" page.
Show total relative refilling, as the total additional fuel or virtual energy that is required to finish the race. This is the same value as seen from "refill" column of Fuel Widget or Virtual energy Widget.
With both "actual" and "total" relative refilling readings, users can determine precisely how much fuel or virtual energy that will be added in next pit stop, and whether the refilling will be enough or more pit stops are required.
Finally, to save your time from generating pit-lane track info (as seen from the new Track Info Editor, see change log or user guide for details about "track info"), I have prepared a "tracks.json" preset in forum attachment that contains all required pit-lane data for every tracks currently available in LMU. To use, simply place "tracks.json" file in "TinyPedal\settings" folder, then restart TinyPedal.
Have fun
User Guide:
https://github.com/s-victor/TinyPedal/wiki/User-Guide#pit-stop-estimate
https://github.com/s-victor/TinyPedal/wiki/User-Guide#tracks-preset
https://github.com/s-victor/TinyPedal/wiki/User-Guide#track-info-editor
https://github.com/s-victor/TinyPedal/releases/tag/v2.28.0
After weeks of development and testing, I'm now happy to share with you all the latest major addition to TinyPedal, the new Pit Stop Estimate Widget, designed specifically for LMU.
This new widget helps solving the two notable issues:
- How much time it will take to make a pit stop?
- Are there enough refilling for the next pit stop for LMU's absolute refilling mechanism?
With this new widget, you can now easily find out:
- Total seconds it takes to do a drive-through pit (no pit service), with an average accuracy of 0.5s.
- Total seconds it takes to do a service pit stop (or serving a penalty), with an average accuracy of 1.0s.
- Actual amount additional fuel or virtual energy (same as relative refilling) that will be added in your next pit stop according to your refilling setting from MFD menu. Plus total additional fuel or virtual energy required to finish race, so you can quickly glance the two number to know if refilling setting is enough or more pit stops are required.
Notable features:
Show estimated pit-lane pass through (drive-through) time, calculated from pit-entry to pit-exit line. Average accuracy is within "0.5" seconds. Note, for any new tracks, at least one pit-lane pass through is required to record data for pass through time calculation.
Show estimated pit stop time while making a service stop or serving a penalty, calculated according to each setting from MFD "Pitstop" page and underlying service timing and concurrency differences. Average accuracy is within "1" seconds.
Show maximum total random pit stop delay which game may add on top of pit stop time. For example, if estimated pit stop time is "12.0"s, and maximum delay is "+3.0"s, then final pit stop time will be between "12.0"s and "15.0"s.
Show estimated minimum total pit time, which is the sum of "pass_duration", "stop_duration", and "additional_pitstop_time". Note, this reading is recalculated only while not in pit lane.
Show estimated maximum total pit time, which is the sum of "minimum_total_duration" and "maximum_delay". Note, this reading is recalculated only while not in pit lane.
Show pit timer, useful for comparing against other pit time readings.
Show actual relative refilling, as the total additional fuel or virtual energy that will be added in next pit stop according to remaining fuel or virtual energy and user refill setting from MFD "Pitstop" page.
Show total relative refilling, as the total additional fuel or virtual energy that is required to finish the race. This is the same value as seen from "refill" column of Fuel Widget or Virtual energy Widget.
With both "actual" and "total" relative refilling readings, users can determine precisely how much fuel or virtual energy that will be added in next pit stop, and whether the refilling will be enough or more pit stops are required.
Finally, to save your time from generating pit-lane track info (as seen from the new Track Info Editor, see change log or user guide for details about "track info"), I have prepared a "tracks.json" preset in forum attachment that contains all required pit-lane data for every tracks currently available in LMU. To use, simply place "tracks.json" file in "TinyPedal\settings" folder, then restart TinyPedal.
Have fun
User Guide:
https://github.com/s-victor/TinyPedal/wiki/User-Guide#pit-stop-estimate
https://github.com/s-victor/TinyPedal/wiki/User-Guide#tracks-preset
https://github.com/s-victor/TinyPedal/wiki/User-Guide#track-info-editor
Corti
Registered
lucamilan87
Registered
It would be great if you could rotate the map clockwise and counterclockwise to optimize the space on your monitor. Thank you for your great work!
A setting for preferred orientation, vertical or horizontal, I think would work well.
It would be great if you could rotate the map clockwise and counterclockwise to optimize the space on your monitor. Thank you for your great work!
davehenrie
Registered
I will be the GPS police and say any fake floating track map should be oriented as seen from space. No flipping or twisting! The alignment should center on the entryway to the circuit and North should always be at the top. (just kidding!)
svictor
Registered
Thanks for the suggestions guys.
Here is the new update with map rotation and some of the recently requested features:
https://github.com/s-victor/TinyPedal/releases/tag/v2.29.0
Besides new features, this update also addressed a recently reported "Pit Menu" (MFD) flickering issue related to LMU's Rest API "pit data accessing". This issue is now resolved with new and optimized data accessing methods, as well as an option to disable "pit data accessing" completely if needed. See change log for details.
Here is the new update with map rotation and some of the recently requested features:
https://github.com/s-victor/TinyPedal/releases/tag/v2.29.0
Besides new features, this update also addressed a recently reported "Pit Menu" (MFD) flickering issue related to LMU's Rest API "pit data accessing". This issue is now resolved with new and optimized data accessing methods, as well as an option to disable "pit data accessing" completely if needed. See change log for details.
- Major change
- Optimized "Rest API" accessing methods, which adds additional update time delay that reduces unnecessary data accessing if API data has not changed recently.
For example, data from Rest API is accessed every 0.1 seconds on default setting, but if API data has not changed recently, the update interval will be increased up to every 2 seconds instead (for example, "pit strategy" data is only changed when user changes it in MFD menu). - Separated "pit strategy" data accessing from other none-pit data (fuel, energy, damage, etc), and can be turned off completely via the new "enable_pit_strategy_access" option in RestAPI Module.
Note, recently there has been reports regarding an issue related to MFD "Pitstop" menu flickering in "LMU", which can be caused by accessing "pit strategy" data frequently. This flickering issue should not be a concern now for TinyPedal with the new accessing methods mentioned above.
Additionally, a new "enable_pit_strategy_access" option is provided in RestAPI Module, which allows disabling "pit strategy" data accessing completely and avoids the flickering issue.
However note, flickering issue can still be triggered by other programs or plugins that have frequently accessed to those "pit strategy" data.
- Optimized "Rest API" accessing methods, which adds additional update time delay that reduces unnecessary data accessing if API data has not changed recently.
- RestAPI Module
- Apply additional time delay to update interval when data has not changed recently, up to 2 seconds max update interval. Update interval will be reset if data has updated recently. This change helps avoid unnecessary frequent data accessing.
- Add "enable_pit_strategy_access" option, which allows turning off "pit strategy" data accessing completely. Note, "Pit stop estimate Widget" will not be able to display pit data if this option is turned off.
- [New]Suspension force Widget
- Show visualized suspension force (Newtons) and ratio (percent).
- Suspension position Widget
- Add "show_third_spring_position_mark" option, which shows front and rear third spring position mark relative to each suspension position.
- Track map Widget
- Add "display_orientation" option (requested by user "peterkasbergen" and @lucamilan87), which sets track map display orientation in degrees.
For example, a "270" value will rotate map by "270" degrees clockwise. Default value is "0", which always displays track map "north up" in game's coordinate system. - Improved "display_detail_level" calculation to work with smaller maps.
- Add "display_orientation" option (requested by user "peterkasbergen" and @lucamilan87), which sets track map display orientation in degrees.
- Pit stop estimate Widget
- Add "stop_go_penalty_time" option, which sets stop go penalty time in seconds. Default value is "10" seconds.
- Misc
- Add "horizontal_gap", "vertical_gap" options for following widgets: Brake pressure, Ride height, Slip ratio, Suspension force, Suspension position, Tyre load.
- Fixed an issue that would add time increment on pitout prediction (Track map Widget) while outside pit lane.
- Renamed "display_orientation" option to "show_inverted_orientation" in Friction circle Widget.
svictor
Registered
Since recently there has been a lot questions and controversies related to LMU's Rest API accessing with various third party APPs or Plugins, I think it is time write this post to clear up some issues and doubts, and hopefully it may help others to avoid similar issues while working with LMU Rest API.
First of all, as other APP developers already mentioned in various posts on LMU forum, LMU's Rest API is quite buggy, and as many know that there is no support for Rest API from game developer. And it is unknown what fate it will be with potential game API update in future.
---
Currently there are two game-breaking issues exist in LMU's Rest API, which include:
1. Some of the Rest API "URI resource" addresses can crash game if they are accessed or opened under certain conditions.
For example, opening any of the following URI addresses in Web Browser while LMU is running in main menu will immediately crash the game:
However, if those bugged URI addresses are opened while in a loaded track session, then they would not cause crash. But as soon as player leaves current session and back to main menu, accessing those addresses again will cause game to crash.
This is considered a very serious and game-breaking issue. I had contacted with one of the RF2 staff about this Rest API issue approximately twelve months ago , but unfortunately this Rest API issue is still not fixed to this date.
The current solution is to not access them to avoid any chance to cause game crashes.
Note, there are several more URI addresses that can crash game, which are not listed here, it is best to test each URI address you plan to use.
2. Accessing any of the Rest API "pit menu" URI addresses at high frequency can cause "Pitstop" MFD menu flickering. Currently there are several URI addresses related to "pit menu" data and affected by this flickering issue, include but may not limited to:
Among those URI addresses, "PitCarReview", "RepairAndRefuel", and "TireManagement" are more likely to cause flickering from testing results, while "receivePitMenu" has the least chance to cause flickering (probably due to its small data size).
---
As for TinyPedal, a lot tests and precautions were made to avoid those issues mentioned above while providing more telemetry data from Rest API, and all those were working without issue before v2.28.0.
In v2.28.0 update, "pit menu" data accessing was added for the first time to allow calculating and estimating pit stop duration, which is done by reading data from "RepairAndRefuel" URI address. And later on, it was reported that accessing "RepairAndRefuel" can cause flickering if accessed frequently.
So in order to avoid flickering issue, the v2.29.0 update introduced dynamic update interval methods. And instead of accessing "RepairAndRefuel" (which has high chance to cause flickering), "pit menu" data was read from alternative URI addresses "receivePitMenu" and "getPitstopTimes".
However shortly after, "getPitstopTimes" was found to be one of those bugged URI addresses that can crash game if not accessed from a track session, as mentioned above.
(It's my mistake for not testing this "getPitstopTimes" address in different situations, partially because it has been a long time since I reported Rest API game-crash issue to game developer, which is almost one year ago, and I thought it was fixed by then, but apparently they are still not fixed. In v2.29.1 hot fix, all URI addresses were extensively re-tested to ensure they work without crash in all possible situations.)
So in v2.29.1 hot fix, this "getPitstopTimes" address is completely removed from accessing. Because "getPitstopTimes" data is crucial for calculating accurate pit timing estimate, in order to compensate the loss of this data, the "RepairAndRefuel" address (which includes the same reference data as from "getPitstopTimes") was added back, but it is now only accessed once per session and then the data is cached, so it will not cause flickering issue. The only downside of this change is that some of the pit time data such as "car damage repair" may not report accurate estimated time, because the reference time for "car damage repair" changes with live car damage severity, which will not be reflected on old-cached data.
To conclude the changes mentioned above, the only major difference between the latest v2.29.1 and v2.27.1 (or earlier) is the addition of "receivePitMenu" and "RepairAndRefuel" URI addresses for accessing pit menu data from Rest API. And those two data accessing can be completely disabled via the new "enable pit strategy access" option, which then there is no difference from v2.27.1 in terms of Rest API URI accessing.
---
It is also important to note, TinyPedal only reads data (resource) from Rest API via http "GET" requests, this APP does not modify Rest API data in any way.
The reason I mention this is because, recently there have been reports about LMU's pitstop menu selections sometimes would be modified unexpectedly for reasons that currently unknown of. And some users were questioning whether this or other APPs could be the cause. However as said, this APP only reads data from Rest API, there is no data modified. And so far I have never encountered similar issue.
For reference, one of the most recent report of "pitstop menu selection issue" was from following thread:
https://community.lemansultimate.co...sets-changes-your-pit-strategy-mid-race.7736/
And the OP appears not using any overlay applications.
You may also wonder what happens with RF2's Rest API. The answer is simple, RF2's does not have all those data available in Rest API, and thus none of the above issues exist in RF2.
---
Finally, TinyPedal is a community-oriented, completely Free and Open source telemetry overlay project (licensed under the GPL v3 License), it has evolved greatly thanks to many people for contributing in various ways. You are welcome to report issues, make suggestions, help with bug fixes or feature implementations, etc. And all source code is available on github project page, feel free to check them out.
Thanks and happy driving.
First of all, as other APP developers already mentioned in various posts on LMU forum, LMU's Rest API is quite buggy, and as many know that there is no support for Rest API from game developer. And it is unknown what fate it will be with potential game API update in future.
---
Currently there are two game-breaking issues exist in LMU's Rest API, which include:
1. Some of the Rest API "URI resource" addresses can crash game if they are accessed or opened under certain conditions.
For example, opening any of the following URI addresses in Web Browser while LMU is running in main menu will immediately crash the game:
However, if those bugged URI addresses are opened while in a loaded track session, then they would not cause crash. But as soon as player leaves current session and back to main menu, accessing those addresses again will cause game to crash.
This is considered a very serious and game-breaking issue. I had contacted with one of the RF2 staff about this Rest API issue approximately twelve months ago , but unfortunately this Rest API issue is still not fixed to this date.
The current solution is to not access them to avoid any chance to cause game crashes.
Note, there are several more URI addresses that can crash game, which are not listed here, it is best to test each URI address you plan to use.
2. Accessing any of the Rest API "pit menu" URI addresses at high frequency can cause "Pitstop" MFD menu flickering. Currently there are several URI addresses related to "pit menu" data and affected by this flickering issue, include but may not limited to:
Among those URI addresses, "PitCarReview", "RepairAndRefuel", and "TireManagement" are more likely to cause flickering from testing results, while "receivePitMenu" has the least chance to cause flickering (probably due to its small data size).
---
As for TinyPedal, a lot tests and precautions were made to avoid those issues mentioned above while providing more telemetry data from Rest API, and all those were working without issue before v2.28.0.
In v2.28.0 update, "pit menu" data accessing was added for the first time to allow calculating and estimating pit stop duration, which is done by reading data from "RepairAndRefuel" URI address. And later on, it was reported that accessing "RepairAndRefuel" can cause flickering if accessed frequently.
So in order to avoid flickering issue, the v2.29.0 update introduced dynamic update interval methods. And instead of accessing "RepairAndRefuel" (which has high chance to cause flickering), "pit menu" data was read from alternative URI addresses "receivePitMenu" and "getPitstopTimes".
However shortly after, "getPitstopTimes" was found to be one of those bugged URI addresses that can crash game if not accessed from a track session, as mentioned above.
(It's my mistake for not testing this "getPitstopTimes" address in different situations, partially because it has been a long time since I reported Rest API game-crash issue to game developer, which is almost one year ago, and I thought it was fixed by then, but apparently they are still not fixed. In v2.29.1 hot fix, all URI addresses were extensively re-tested to ensure they work without crash in all possible situations.)
So in v2.29.1 hot fix, this "getPitstopTimes" address is completely removed from accessing. Because "getPitstopTimes" data is crucial for calculating accurate pit timing estimate, in order to compensate the loss of this data, the "RepairAndRefuel" address (which includes the same reference data as from "getPitstopTimes") was added back, but it is now only accessed once per session and then the data is cached, so it will not cause flickering issue. The only downside of this change is that some of the pit time data such as "car damage repair" may not report accurate estimated time, because the reference time for "car damage repair" changes with live car damage severity, which will not be reflected on old-cached data.
To conclude the changes mentioned above, the only major difference between the latest v2.29.1 and v2.27.1 (or earlier) is the addition of "receivePitMenu" and "RepairAndRefuel" URI addresses for accessing pit menu data from Rest API. And those two data accessing can be completely disabled via the new "enable pit strategy access" option, which then there is no difference from v2.27.1 in terms of Rest API URI accessing.
---
It is also important to note, TinyPedal only reads data (resource) from Rest API via http "GET" requests, this APP does not modify Rest API data in any way.
The reason I mention this is because, recently there have been reports about LMU's pitstop menu selections sometimes would be modified unexpectedly for reasons that currently unknown of. And some users were questioning whether this or other APPs could be the cause. However as said, this APP only reads data from Rest API, there is no data modified. And so far I have never encountered similar issue.
For reference, one of the most recent report of "pitstop menu selection issue" was from following thread:
https://community.lemansultimate.co...sets-changes-your-pit-strategy-mid-race.7736/
And the OP appears not using any overlay applications.
You may also wonder what happens with RF2's Rest API. The answer is simple, RF2's does not have all those data available in Rest API, and thus none of the above issues exist in RF2.
---
Finally, TinyPedal is a community-oriented, completely Free and Open source telemetry overlay project (licensed under the GPL v3 License), it has evolved greatly thanks to many people for contributing in various ways. You are welcome to report issues, make suggestions, help with bug fixes or feature implementations, etc. And all source code is available on github project page, feel free to check them out.
Thanks and happy driving.
Last edited:
Seven Smiles
Registered
Thanks for providing all the detail, I was not aware of the issues. Crew Chief uses the LMU REST API but only when needed (so at a very low frequency) and no-one has reported any problems. It does POST RepairAndRefuel to set the Pit Menu when the user gives a pit command (and on entering the pits if "Enable LMU auto refuelling when entering pit in race" is selected) but it seems it is not the cause of the bug reported in that LMU post. (If "Enable LMU pit manager" is not selected it will not POST at all.)
Like TinyPedal, Crew Chief is Open Source and relies on people reporting any problems: https://gitlab.com/mr_belowski/CrewChiefV4
Like TinyPedal, Crew Chief is Open Source and relies on people reporting any problems: https://gitlab.com/mr_belowski/CrewChiefV4