1 is discussed in another thread, I'll get to that later. 2 try this (I haven't actually looked into this previously, so here's my first guess!): (note the quantity, result unit, and display unit) **(also note I assume average rear toe is zero. The plugin captures setup values, the rear toe values can hopefully be incorporated into the formula to compensate for any offset)
The game itself doesn't provide any direct (especially digital) indicator for these. Hopefully at some point that gets added, and I presume it'll be an analog signal which we'll then be able to scale as we see fit for analysis. Anyway... TC: as Robin suggests, this is as easy as checking filtered vs unfiltered throttle. The game reduces throttle input when applying TC and this is reflected in the filtered value, but still logs your actual input with the normal value. Note: filtered throttle is also reduced when the game helps handle a gear change (auto-lift), and possibly other occasions I can't think of right now (oh, pit speed limiter, there's one) as the filtered value will reduce from the full throttle value, if you want a 0-1 indicator you'll have to decide the threshold yourself, and work it out as a percentage of full throttle. I'd also recommend ignoring very low throttle applications to avoid dirtying your data/graph. An example formula: I've ignored (raw) throttle positions below 20% and used the min() function along with a scaling factor of 2.0 (you could make that a constant and adjust it separately, along with the min throttle threshold) to push the 'TC active' value to 1 when the filtered position is less than 66.6% of the unfiltered, and keep the maximum output value to 1. There's basically an unlimited number of ways to calculate and approach this, so this is just one example. (I've used max(0.001,...) in the denominator to remove division by zero; you could forego this and somewhat remove the TC active indication during gearchanges, but I'm not sure I like the idea of it being invalid if TC actually makes filtered throttle zero...) I haven't played much with the various functions relating to data boundaries, you could possibly use those to remove the throttle filtering around gear changes. ABS: there was discussion of this in this thread, and @Kevin van Dooren gave good concise information I later tested there illustrating how it works. I've just done a formula and regrettably it's ended up quite a mess as I've included all 4 wheels, but it uses a similar principle to TC above: Notes: I'd definitely define the threshold ('20') and the scaling factor ('2.0') as constants and reference those instead, so that this is much easier to adjust. It might be easier to manage (and clearer for display) to do each wheel separately rather than all together. You could have another overall indicator that combines those. One of my test logs had many driving aids turned on, and strange things were happening with the brake pressures (e.g. the total brake front + rear brake pressure exceeded 100%!). I have very little experience with the aids so I can't give good guidance on that, I've only tested this stuff with the on-vehicle ABS/TC. In case you want to just try this as-is, here's the text so you don't have to recreate that monstrosity: Code: choose( 'Brake Pos' [%] > 20, max( max(min(1, (('Brake Bias Rear' [%] / 'Brake Pressure RL' [%]) - 1) * 2.0), min(1, (('Brake Bias Rear' [%] / 'Brake Pressure RR' [%]) - 1) * 2.0)), max(min(1, (((100 - 'Brake Bias Rear' [%]) / 'Brake Pressure FL' [%]) - 1) * 2.0), min(1, (((100 - 'Brake Bias Rear' [%]) / 'Brake Pressure FR' [%]) - 1) * 2.0)) ), 0) and here's the TC one as well just for ease of use, though I think this one could definitely use refining: Code: choose( 'Throttle Pos' [%] > 20, min(1, ('Throttle Pos' [%]/max(0.001,'Throttle Pos Filtered' [%]) - 1) * 2.0), 0)
Thanks! I should remember that I can calculate this. It's fundamental vehicle dynamics. For ABS and TC, I will try that later, I just found out my current log file does not include control_1, which recorded the Filtered throttle position.
Thanks for your reply! The plugin's log can be normally created on the folder, the only error I get is the one previously described. Apparently the error is related to "ntdll.dll" and happens simultaneously when the plugin starts the log or immediately right after it. Faulting application name: rFactor2.exe, version: 1.1.3.2, time stamp: 0x6411ebf9 Faulting module name: ntdll.dll, version: 10.0.19041.2130, time stamp: 0xb5ced1c6 Exception code: 0xc0000374 Fault offset: 0x00000000000ff6a9 Faulting process id: 0x3418 Faulting application start time: 0x01d959e9e8a0c51b Faulting application path: D:\SteamLibrary\steamapps\common\rFactor 2\Bin64\rFactor2.exe Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll Report Id: 6efbb742-1fcb-4e86-a66e-1b1a0d18731a
I'm not sure I understand what is and isn't working for you. Can you share an rF2 trace file and the complete DAMPlugin logs? (Output and error log)
For some reason, 2 dlls from the DAMPlugin were registered in the following archive: CustomPluginvariables.json. The second DLL register was causing the issue. I deleted the second DLL registered and it began to run normally again. Thanks again, Lazza.
Thanks for the update! My first thought was having 2 copies of the actual dll (named differently) which seemed very unlikely. I didn't know multiple entries in that json could do this, very interesting
I've added v0.931. I'm (still) yet to overhaul some of the code in this relating to the channels, I did make some minor changes to value ranges but I'm hoping I haven't broken anything. Additions: Delta Best is now logged, at all times (it's in the base scoring group). This is generated by the game itself. Note that by default it's limited to +/- 10 seconds (the game displays up to 9.999 in the HUD). By setting the base scoring group to 3 (high range logging) you can get up to 3600s (1 hour). I've defaulted to 10s because it basically matches the game itself and it gets good precision without increasing filesize too much. Battery Charge Level is logged as part of the base Vehicle group. 0 - 100% Electric motor channels are added to the Vehicle_1 group. These are: Motor State. Values 0 - 3 -> Unavailable, Inactive, Propulsion, Regeneration Motor Torque. (Positive when providing power, Negative when regenerating) Motor RPM Motor Temperature Motor Water Temperature The various available rates for these channels are largely matched to their similar mechanical/combustion counterparts. As usual, could almost make this my signature: any problems, let me know. If you get a virus warning on the Handler, just use the Manual version.
Hello lazza! quick question, is it possible to get separated lateral g force for front and rear axis? I guess the game only have 1 output for this, i'm only asking to be sure. Thanks
Lazza Have you ever seen this error? I am unable to open rf2 .ld files through Motec but if i double click on the actual .ld file it opens OK in Motec. Running DAMPlugin 0.931 and 1.15.85
That's not an error, just information. It won't affect opening logs. I've just checked the same i2Pro version, and logs are opening fine (with that same message).
You aren't somehow opening a different version of i2Pro when double-clicking files? And it's using the same project when doing so? Seems a bit weird. I should ask - what does it actually do, or not, when opening a file? Just show nothing at all?
It was causing i2 pro to crash all the time when you tried to open. I have found the issue. My log folder was 13Gb so I deleted a whole heap of files and bingo it worked like a dream. I assume it must have been struggling to read all the files. I kept the files I was having trouble with and they open faultlessly now. I have no answer why but it worked
Ok, glad you worked that out I've certainly had some major slowdowns with lots of files in there, I guess I've never reached crashing stage before moving some out. Good to know!
