I'm not sure why I have this in the back of my mind, that UpdateScoring() could be called 10 times per second instead of the current (that I see) 5 per second, every 0.2s. Is it possible? If so, how?
I tried a few things here, but UpdateScoring() is called five times per second no matter what. There's an underlying problem I want to solve. I need UpdateScoring() to be called more often because I am working on the Delta Best or Delta split plugin and 5 times per second is a bit too low resolution. It looks like I have two options: make the rF2 engine call UpdateScoring() more often. get the data I need with UpdateTelemetry(). Unfortunately, UpdateTelemetry() doesn't seem to give me access to VehicleInfo.mLapDist to gauge where the vehicle is within the track. Ideas?
Can't you use the distance traveled (tracked via updatetelemetry) to approximate the lapdistance, based on the previous interval? How are you storing and comparing the overall times now anyway? Maybe your method is introducing some rounding errors that make it look worse.
I'm afraid distance traveled, if available, doesn't tell me much without a heading. You could go backwards, or sideways, and that doesn't mean you are in the same point of the track you were on your best lap. Right now I'm doing mLapDist interpolation with 1 meter precision, so even though scoring is called every 0.2s, the delta is quite accurate according to my tests. Thanks for your answer btw.
Sorry, was typing on my phone so couldn't really explain what I meant properly. I meant that if you travelled, say, 10.0m in the previous updatescoring interval (0.2s) according to .mLapDist, but in telemetry your distance travelled (either x-y-z, or x-z, though not sure it would make much difference) was 11.0m, your actual distance travelled is obviously 1.1 * the mLapDist. So to get an approximation of your mLapDist after 0.1s you might get your distance travelled (updateTelemetry position change) and divide it by 1.1. Still not perfect of course, but your car direction won't change all that much in 0.1s and the AIW won't turn all that much either in the space of ~5m (a hairpin might introduce a lot of 'turn', but you should be going slower so the distance [and therefore direction variation] will be lower, while at high speed the track itself will likely not turn very much at all even if you're covering 10m in that 0.1s. If for some reason the car is travelling at an unusual speed for that section of track which makes these figures very inaccurate, the driver's probably out of control anyway and the wrong delta won't matter). Regarding the precision you mentioned interpolation so I imagine you're doing something like: - previous mLapDist was 200.4m - previous ET for lap was 45.3s - current mLapDist is 206.2m - current ET for lap is 45.5s therefore: - ET/m = (45.5-45.3)/(206.2-200.4) = 0.03448 - ET @ 201m = (201-200.4)*ET/m + 45.3 = 45.3207 - ET @ 202m = (202-200.4)*ET/m + 45.3 = 45.3552 etc. In which case, yeah, I wouldn't expect a lap-lap comparison to be very far off.
Lazza, I just tried your suggestion, so using UpdateTelemetry() to get 100 hz updates, and using -1.0 * info.mLocalVel.z as speed. With a dt of 0.01s, I measured the difference between (dt * speed) and the actual mLapDist traveled, and they are pretty damn close! It seems that -mLocalVel.z is always pointing forward relative to the car, so it gives a good approximation of the traveled lap distance. I didn't expect this: that's a good surprise Thanks again for the suggestion, it put me on a good track.
