Stereo updated Odometer with a new update entry:
32-bit compatibility
Read the rest of this update entry...
32-bit compatibility
Read the rest of this update entry...
Resource icon
Apps Odometer 0.4.2b
- Thread starter Stereo
- Start date
Stereo updated Odometer with a new update entry:
64-bit wouldn't run without certain other apps present
Read the rest of this update entry...
64-bit wouldn't run without certain other apps present
Read the rest of this update entry...
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.
I didn't realise that, that is brilliant news. I'll be using it all the time from now on. Thanks for the reply.
Can't get it to work in AC V1.4. Same thing nothing shows in the app bar even when it's turned on in options.
It dossent show up in the app bar :/
Hey guys, does anyone have issues with the odometer displaying using the latest csp?
For me it looks like this.
For me it looks like this.
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?
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.
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:
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
. 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.
--
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
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.
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]/unitconstThat 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:
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
Last edited:
