[REL] rF2 Pedal Overlay Plugin

MarcG said:
That's no good as I use other plug-ins, was wondering if there's a specific key bind to lose this one, if not add it to the "ideas" list TechAde ;) thanks
Click to expand...

Same here. I use TracIR and disabling hardware plugins disables it too, obviously. I'd be great if it was possible to disable the rF2PedalOverlay on its own without uninstalling it, even if you had to manually edit the ini file to do it.
 
Version 10 is released, attached to first post.

Version 10 adds:

* Steering bar (rendered horizontally below pedal/FFB bars)
* Ini file option to disable overlay (OverlayEnabled=True|False, defaults to True)
* Ini file option to diplay filtered inputs (FilteredInputs=True|False, defaults to False)
* Rebuilt against latest InternalsPlugin.hpp (version 6). Presumably this means it will require rF2 build 660 or above.
 
Thanks for the update Ade but I'm not getting an INI file to edit :confused: started RF2, loaded a track and the plug-in works fine, but alas no INI to alter.
 
The ini now resides in UserData, rather than alongside the plugin. Made this change a couple of versions ago thanks to the evils of UAC!
 
aahh I thought the OverlayEnabled= would allow in game turning off but alas it does'nt, any plans to add this?
 
Quoting this from another thread but replying in this one...
Comante said:
So, can I ask you something? Do you think it would be useful to have the FFB bar having a positive and negative (L & R ) differentiation? I mean so that we can see at any moment in which direction is the force pulling.
I don't really know if it would be helpful.. but I think it should be like that. :)
Click to expand...
That's a good idea, thanks. Next time I dive into the code I'll do that, make it horizontal like the steering bar.
Comante said:
A probably more helpful function would be to keep the FFB bar red for a bit longer than the FPS in which clipping occur. As I said elsewhere, the phisycs engine run at much higher speed than our monitor refresh, so you really miss most of the clipping. This would mean that we would see the bar colored red even if the value actually displayed is no more 100%.
Click to expand...
How about some sort of 'high water mark' that stays behind for a little while, indicating the highest value reached over the last few seconds? That shouldn't be too tricky (he says not so confidently!).
 
MarcG said:
aahh I thought the OverlayEnabled= would allow in game turning off but alas it does'nt, any plans to add this?
Click to expand...

No, sorry, at least not unless I can find some key detection code that isn't as heavy on the CPU as GetKeyState(). With rF1 it wasn't so bad as the physics thread wasn't hitting the CPU so hard, but with rF2 any extra CPU load is a problem, especially on slower systems.

Edited to add:

You can back out to the monitor, edit the ini (alt-tab or windowed), then hit the track again and it will re-load the ini, if that helps?
 
TechAde, maybe it would be more clear some sort of diagram, with time in the horizontal axis, just like the ram or the cpu usage in the resource manager of the PC. You would really need to display just less of 1 second history, but this amount should be customizable. So, I figure you have a rectangle, and the right side show the realtime data, and streaming to the left the history is constantly updated. But what would be important is to show most data possible, but unless you use a 400 pixel bar, you cannot show 1 second history, maybe 0.25 sec. will be enough. And if due to this you have to cut data out of the display, they must not be the 100% values.
I hope this is clear, today english is still sleeping in my mind.
 
Comante said:
TechAde, maybe it would be more clear some sort of diagram, with time in the horizontal axis, just like the ram or the cpu usage in the resource manager of the PC. You would really need to display just less of 1 second history, but this amount should be customizable. So, I figure you have a rectangle, and the right side show the realtime data, and streaming to the left the history is constantly updated. But what would be important is to show most data possible, but unless you use a 400 pixel bar, you cannot show 1 second history, maybe 0.25 sec. will be enough. And if due to this you have to cut data out of the display, they must not be the 100% values.
I hope this is clear, today english is still sleeping in my mind.
Click to expand...

Nice idea but rather beyond the scope of this simple little plugin I'm afraid.

However, what I do plan to work on at some point is a full telemetry overlay plugin with which it'll be possible to overlay a graph of any of the telemetry data available in the UpdateTelemetry() call. Don't hold your breath though, real life keeps me _very_ busy these days, what with work, a toddler and now another baby due soon!
 
TechAde said:
No, sorry, at least not unless I can find some key detection code that isn't as heavy on the CPU as GetKeyState(). With rF1 it wasn't so bad as the physics thread wasn't hitting the CPU so hard, but with rF2 any extra CPU load is a problem, especially on slower systems.

Edited to add:

You can back out to the monitor, edit the ini (alt-tab or windowed), then hit the track again and it will re-load the ini, if that helps?
Click to expand...

Ooh good thinking I'll try that when I next use your plug in, cheers mate
 
Brake Wear Plugin available?

Hi, Techade! Grats on the baby.
I haven't seen it anywhere, and after having brake failure twice this season, I'm wondering if there is a brake-wear overlay available for RF2. There may be a preexisting one I just don't know about. Help!
:confused:
 
You must log in or register to reply here.
Back
Top