You may want to look at the patch and ground velocity channels - you may be able to use them for that purpose, though I'm not sure exactly how they're aligned. PS Thanks for the thanks, but no donation for this one
Sorry, presumed some familiarity on your part there. Some of the optional channels (check the channel list linked in the first post) are (tyre) contact patch velocities and ground velocities. They sound like they should allow you to calculate the speed of the tyre surface across the track surface, but I'm not sure how their axes are aligned and therefore whether you can get the longitudinal slip you're after.
Hehe good one OK I dig a bit down in other tire channels than the Rot Speed. To get a (hopefull) more usefull channel.
Hey Lazza, did you get a chance to look at boost pressure? In the mean time, I have a temporary solution in the form of an expression, measuring fuel use per engine revolution. Code: max(-derivative('Fuel Level' [l]), 0) / 'Engine RPM' [rps] The resulting unit is in litres, and I'd suggest displaying it in microlitres. More fuel per rev = higher boost pressure. It'll get a bit weird if an engine uses different mixtures across its map, but for the mods I'm working on this is enough to get an idea of what's going on.
Sorry, not yet. Haven't been home for 3 weeks and wasn't getting much time for this stuff previously, I'll try and fix up some stuff soon but if I give a timeframe I'll just disappoint (ah... story of my life) soooo soon it is
hi, I've little question. I'm using DAM plugin for data acquisition and in telemetry I notice that the red point on trackmap isn't sincronised with data, the point seems to be faster than data recorded. Someone else have same problem? There's a solution to fix it? Thanks a lot.
For now regenerate the track map using G forces (not GPS) and the dot should be much better synchronized. I need to sort out the GPS data/scale, when I get it right I'll fix it in the plugin - will only want to do that once (it breaks GPS comparisons with previously logged data).
Updated to 0.75 - Adjusted GPS positioning. Generating track maps by GPS coordinates (i2Pro default) should now produce correct lap distance scaling. This should be the last major adjustment to GPS data. - Fixed Turbo Boost Pressure values. Note that the pressure is absolute, not relative to normal atmospheric pressure, so 101.325kPa is 'zero' boost. - Both the 32- and 64-bit plugins are now called DAMPlugin.dll, in line with more recent rF2 convention (no more _x64 suffix, which will also mean no separate entries in CustomPluginVariables.JSON). Those doing manual installs please note the last item above. You'll need to delete the old 64 bit plugin.
Fantastic thanks Lazza, was just coming to this thread to see if i could fix the misalignment of track position only to find this update that solved the issue. brilliant
Thanks Lazza ! Installed the plugin (Steam) and Motec program and everything is working ! Cheers ! Gilles
I think in case of Long Races with Pilot Changes, if have an option to turn on/of in options. Working: In race the pluguin save 1 lap, and consecutive add the dates of 2 lap and save and continue. If the game crash or lost conection, or going to spectate mode, the file is there on /LOG saved.
The structure of the log file means 'adding' more to an existing log isn't straightforward. Over time it will become a more and more expensive (execution time) operation. My intention is to provide two options here: 1. Have the plugin, or the Handler program, rescue aborted logs and make them work in i2Pro, and 2. Allow per-lap logging, which would create a new log for each lap completed. Obviously I don't have either of those in place yet.
Could vehicle Yaw, Pitch, Roll angle be added to the log? Also, could fastest time for incomplete/partial laps be discarded from the header? So that only complete/valid laps show up with a time in the file open dialog. Thanks in advance.
Damn, I forgot to add the orientation stuff for this one... I will add that, yeah. The fastest lap info is generated by i2Pro, but you're right, I should remove all timing info from partial logs. I'll have to check the effects on partial logs (so outlap / partial lap 'tests' are still useful), but it should be possible. I agree having bogus fast laptimes showing up is a bit annoying/confusing
Many thanks for the quick response. And yes I mean that partial logs should still be saved, but just not be shown as fastest laps.