Resource icon

Apps Odometer 0.4.2b

Login or Register an account to download this content
Can it be 're-sized at all? If it were smaller it would be perfect. It's the sort of app I'd constantly use if it were smaller, tucked away in the corner or at say 50% opacity.
 
The config.ini in the app's folder has a scale parameter, you can just set that to 0.5 and it'll make it smaller. I didn't want to include a bunch of buttons on the app itself since you hardly ever need to change it.
 
The config.ini in the app's folder has a scale parameter, you can just set that to 0.5 and it'll make it smaller. I didn't want to include a bunch of buttons on the app itself since you hardly ever need to change it.
I didn't realise that, that is brilliant news. I'll be using it all the time from now on. Thanks for the reply.
 
Hey guys, does anyone have issues with the odometer displaying using the latest csp?
For me it looks like this. :O_o:

1593068330883.png
 
Generally that means another app is behaving badly in the render thread, so the odometer never gets to draw all its textures. Very little able to go wrong for odometer itself.
 
Unfortunately, I lost my AC install folder, and therefore my Odometer stats.

Luckily, CSP has stats, and and it's located in the Apps Data folder and didn't get lost. Not only that, but they seem to auto-import into Stereo Odometer.

That's neat, but Odometer seems to start off with an adjustment of 1 on load, and changes after a few corners. Also, for some reason, CSP then imports that data and overwrites the correct one.

---

For example: Car X was driven for 10,000km before Odometer resets, CSP says.
When launching it in Odometer, it reads 10,000, but after a few corners it jumps to 12,451km as it finds the correct adjustment value and applies it to the value that had been added before (even though it had already been adjusted when it was recorded). When you then go into CSP, it has erased its 10,000 value and replaced it with 12,451.

---

I tried editing car.originalvalue = 0 so that it would read, say, 10000000, and put car = 0.
After a single session, original value remained at 1000000000, but car jumped up to 12451000 or whatever.

I'm trying to find a way around this issue before I corrupt all my data in CSP (since it's the only "real" data I have and have already lost a few cars, unbeknownst to me). Would there be a way to:

1. Import a list of every car's adjustment value, or generating one without actually running the odometer (thereby polluting my data).
2. Have the initial value not be modified by the adjustment value (so that, in my example, 10,000km remains flat and whatever gets added to it is subjected to the adjustment.
3. Another way to sort this out I haven't thought of?
 
Well the deal with the adjustment value is that Odometer stores the distance traveled without the adjustment cause that's what AC provides (I'm not sure what exactly it represents... radians the driven wheels have spun or something). So I think what you'd need to do is write down the amount of km, drive enough to get an adjustment value, then reverse the calculation to figure out the number that produces that distance using the adjustment.

I haven't seen what CSP does with the odometer config file, if it's just inserting a bunch of values without adjustments for any car you've driven, then you could back up that file once it's done so. I also don't know what originalvalue means, it's not generated by the app.
 
Last edited:
Well the deal with the adjustment value is that Odometer stores the distance traveled without the adjustment cause that's what AC provides (I'm not sure what exactly it represents... radians the driven wheels have spun or something). So I think what you'd need to do is write down the amount of km, drive enough to get an adjustment value, then reverse the calculation to figure out the number that produces that distance using the adjustment.

I haven't seen what CSP does with the odometer config file, if it's just inserting a bunch of values without adjustments for any car you've driven, then you could back up that file once it's done so. I also don't know what originalvalue means, it's not generated by the app.


Thanks for your reply!

What you proposed is actually what I initially tried. Sure, it would take a while for a few hundreds of cars, but I was willing :D.

Following my example I would use 10000 and divide it by its adjustment of 1.2451, and edit the odometers file with the result, 8031 in this case, hoping that when Odometer reloads it multiplies that amount by its adjustment and we'd be back to 10000. Problem is, CSP still shows 12451, and whenever I reload Stereo Odometer, it takes the value from CSP, not the one from the odometers.txt file, so it shows 12451 and upon closing AC, the odometer.txt file reads 12451 rather than 10000. That led me to my point 1, which is to have adjustments somehow preloaded.

Here's what I mean by original value; an extract of my odometers.txt file. All the data was seemingly extracted from CSP, as I haven't driven the R8 LMS since the Great AC Folder Loss, and definitely not 2000km.

[Cars]
ks_toyota_ae86 = 4521.30336889772
lotus_exos_125 = 3127.716110169204
ks_lotus_72d = 35631.89469659545
mclaren_mp412c_gt3 = 0.034565509178355554
ks_audi_r8_lms = 2310985.9534233077
ks_audi_r8_lms.originalvalue = 0
ks_ferrari_f2004 = 934209.2117386917
ks_ferrari_f2004.originalvalue = 0


[Adjustments]
ks_toyota_ae86 = 1.0417532911082348
lotus_exos_125 = 1.1704971568265725
ks_lotus_72d = 1.1904487054408905
mclaren_mp412c_gt3 = 1.0 (I loaded it, didn't drive it)
ks_audi_r8_lms = 1.0 (I loaded it, didn't drive it)
ks_ferrari_f2004 = 1.1665273973678372

--
 
Hmm, seems like at some point CM is checking the distance and then replacing it if its stored number is higher. So originalvalue is the number it replaced (0 cause it wasn't in the txt yet).

Next thing I can think of trying is edit the python so it retroactively corrects for the problem when it picks an adjustment value. I think you'd go to line 156 and add
Code:
    unitconst = gspeed/dtspeed*(1+(slips[2]+slips[3])/2.0)
    odo[0] = odo[0]/unitconst
    odo[1] = odo[1]/unitconst

That way if it loads in with 10000 and then picks a 1.25 constant, it'll drop the stored value to 8000 and save it that way. I'm not sure how often CM is checking the values, but this way at the end of the session it should just see 10001km or whatever and not jump to 12500.

This should only be enabled while correcting the restored CM values, if you ever deleted an adjustment on a car that was already correct, this would make the stored distance wrong.
 
Last edited:
Next thing I can think of trying is edit the python so it retroactively corrects for the problem when it picks an adjustment value. I think you'd go to line 156 and add
Code:
    unitconst = gspeed/dtspeed*(1+(slips[2]+slips[3])/2.0)
    odo[0] = odo[0]/unitconst
    odo[1] = odo[1]/unitconst

Well, early attempts are extremely promising. I took cars that I haven't driven since odometers data got wiped, and it looks "normal", importing data from CSP and not applying the extreme multiplier!

The cars I have driven recently have problems within CSP (for example, if I delete one car's data from both CSP and odometer, then I drive it, back in CSP it inexplicably returns to yesterday's data, the "12451") but that's nothing you are responsible for, and it's limited to a handful of cars. Thank you so much for taking the time to reply and finding a solution so promptly to a plugin you haven't even updated for years!

---

EDIT: I solved the mystery of yesterday's data problem. When the data turned from 10000 to 12451, it exported that data to CM. Then, it exported the CM data to Sidekick. Today, since Sidekick was at 12451, it kept importing it from there after every race. So I turned that setting off, problem solved.

I'll keep on going through my cars tomorrow and see if it all makes sense, but it's crazy how two lines of basic code probably solved this issue :D
 
Last edited:

Latest News

Are you buying car setups?

  • Yes

  • No


Results are only viewable after voting.
Back
Top