It's not noted in car files, no. The only correct way would be to pull out the geometry details as you've said. Perhaps you can get a close approximation by analysing a delta in ride height against suspension position and tyre vertical deflection? I'm not that up on these sorts of details so maybe there's another method I'm not aware of. Yes, it's been Grip Fract forever in DAMPlugin (thanks for paying attention... lol) Sorry, I haven't sorted out a good way to handle this yet. For certain technical reasons I haven't been inclined to automatically find and convert partial files, so what you have there unfortunately is 9MB of nothing.
I'm just waiting for a bit more testing, @Josh.H is back on the case and unfortunately the driver swaps still aren't working as expected, so I'm going to change my approach which should (should!) ensure everything works. I'm also making some other changes so I'll try to make sure they're stable before I do a full version upgrade.
Yes it has but not seeing any other version how would I know it was represented by a different name nothing like Grip Fract . When given a workbook containing slide Pct It is easy to interpret as percentage of sliding but I saw no linkage to that in the name grip Fract so I thought it reasonable to ask. To the author the names make perfect sense to others we may need to ask for clarification. Thanks for watching this thread LOL
@whitmore Actually I can't remember when it changed, or why it was ever Slide Pct. It's starting to look like it was something I decided on, which is a shame because it's the opposite of a 'slide percentage' (it's at 100% with no sliding). All the plugin interfaces I can see back to rF1 called it GripFract. Ah well
Just a quick (progress) update, I'm fairly confident a new approach to logging activation will work with and without driver swaps. Unfortunately I didn't fully take on board the findings of some forum members some time ago in this regard, for non-driver-swap situations I was stubbornly holding onto the same system I'd been using since around 2009 in rF1, and combining the two was proving to be problematic. Abandoning the old way completely and just treating everything the same should work fine. Some other internal changes I've made have caused some intermittent issues I need to track down, plus I've discovered a timing bug related to the game going out of realtime (ie when the game goes out of realtime, my log timings start to go wrong; the game doesn't directly report that it's gone out of realtime, and I had wrongly assumed all telemetry and scoring updates would be provided regardless, so I want to cater for that situation in an efficient way [so I don't cause the game to out of realtime more than it already is!]), once I've sorted those out I should have a new version for testing and release.
Would you suggest going back to .76 or is it "safe" to use the new version for single driver logging?
@Wergilius Well on one hand, as far as I know .763 will work fine, but apart from .761 separating the formation lap from lap 1 there's no difference to .76. There was a report of incorrect laptimes in 0.762 but I haven't been able to reproduce it. I hope they're all stable, but everything's stable until it crashes or breaks
see this post https://forum.studio-397.com/index.php?threads/damplugin-for-rf2.49363/page-16#post-935043 and downwards, should be safe
@Lazza , i'm being using an old rfactor2 motec plugin, https://forum.studio-397.com/index.php?threads/rfactor-2-telemetry-plugin.29852/ My motec version is 1.0.3, this old plugin gives me all the information. Recently i "updated" to this newer version, and basic information channels like Ride Heights isn't available. Can you explain me why?
The old one logs all the channels all the time, which means extra CPU cycles and bigger files for people who don't even want probably 60% of that information. This one allows you to decide which groups of channels you want to log, and then also choose to have extra large value ranges or extra precision if that's what you need. Find your DAMPlugin.ini file in your rF2\UserData\player folder, and down the bottom is the section defining which groups get logged. Change all those "= 0" to "= 1" and you'll get all the channels again. Check the first post in this thread, it also links to a list of all the channels available and which groups they're in. As for i2Pro, the newer versions (1.1.x) behave better on modern versions of windows, the old ones had some redraw issues at least. Plus there have been bugfixes along the way. If I'm remembering the one you're using correctly I think it doesn't even have GPS? (I could be wrong)
Sometime ago i responded a thread saying that this plugin may cause crashes in rf2. In fact the old version does, i imagine that this new one doesnt, correct?
I'm not aware of it causing crashes, but I don't think I was aware of the old one causing them either. Can't rule it out.
I think that Aero_1 and Suspension_1 are very basic information, probably most of motec projects around internet uses this data, at the point i was imagining that this plugin had a bug, I reverted to the old one until i had an insight about maybe that is something related to configuration. Just now talking to you that finally i'm using the newer version. What you think about settings these 2 channels on by default? Ride Heights everyone uses to know the rake of the car as an example, and motec is the only way to do it.
@ebeninca I might take a look at the base channels, but bear in mind the default i2Pro workspace doesn't have ride height either. It has suspension position which is then used for the damper FFT. I do realise that new people tend to think suspension position means ride height, but even having ride height logged won't mean they'll see it in the channel list. So as it is right now they need to know they want ride height, add it in the plugin, and add it to their workspace. I think mostly this problem is alleviated by reading how this plugin works, instead of assuming it's like the old one that logged everything. But I'll think about it. Aero not so much - most people don't have a need for that, so I'm not inclined to log them all the time.
@Lazza, i left the game running all night, on a total of 10 hours, with the DAMPlugin running, and no crash happened. Definitely if the old version had a memory leak, this one doesn't, thx.
First I want to mention I have been using 0.763 and it have been working ok on a few tracks (i think). Then had an strange behavior when logging on Racefactor Spa, first time on this track. When I opened the files (3 with only 3-6laps), start/finish was i the middle and on the other it was more than one lap in the actual lap. I went back to 0.76 and it worked as expected. Now I tested to upgrade to 0.763 again and error returns, I can linkt to one of each logs if it helps. Regarding custom key for enable, if you select no prefix (ctrl) the logging just go on/off directly for each key press.
@Wergilius Thanks mate, I haven't tracked down any specific timing bug in the latest version(s) but I've been reworking how some of the internals work and that's led me to reorganising some of the timing, so I'm hoping to fix any such issues with the next version. Along with the driver swaps, I hope. I would say I overlooked a side effect when I was trying to respond to driver swap events and that got the laps themselves wrong.
It actually seems track dependent, Paul Ricard HTT works ok and RaceRfactor Spa 2013 I get the fault every time with 0.763 (but works ok with 0.76) Start of an old and new file: Then we look forward to next release when it's done
