Thanks for the report. I'm really not sure what that error is or what's causing it, although I know where it happens. Please download this special debug version of the program. When you run it, after the error has appeared, it should create a file called 'Log.txt' in the same folder as LFSPoints.exe, which should contain much more detailed info about what has gone wrong. If you could post the contents of this text file, I'd be grateful.
Can you please try this version and report back if it works? It may still not work, but even if it doesn't it will help me narrow down the problem. If it still crashes, can you please post the 'Log.txt' file again. Thanks!
OK - I think I've fixed it. I managed to recreate the bug by changing my OS language and text services to Hungarian. The problem seems to have been caused by the different character encodings Windows uses for different languages, which was throwing errors as I was trying to read XML data out of the Tracks.xml file. Anyway, this version works on my PC in both UK English and Hungarian, and should also work for most (all) other language versions of Windows.
This stuff gets complicated some times! Anyway, please try this and see if it works now.
Could this be implemented in a next version??
A possibility to have a minimum race % of driven laps. For example if someone hasn't driven at least 50% of the total race distance, he gets no points. (or another % of lap count)
There is stil a bug with the best laptime of a race. In the last race someone drove 1.14.090 , but it showed up in LFSpoints as 1.14.900.
In the championship standings he got his extra point because 1.14.090 was the fastest lamptime in the race. So internally LFSpoints calculates it right but in the raceresults it showes up wrong.
(you may have fixed this with the latest version) info here
I uploaded our LFSBC Round 5 replay into it (KY2), and it was unhappy as you've named kyoto as 'kyoto' in tracks.xml, whereas the replay says it's 'kyoto ring'. Simple solution is to rename kyoto ring to kyoto in tracks.xml.
The issued with the average speed isn't actually a bug, even though I know it does look funny. If you look at each 'pair' you'll notice their best lap times (which is what the average speed shows the average speed for BTW) are very close to each other, and given the fact that they're rounded down to two places can give this effect. I will however look at the formula used to determine the average speed and see if it can be made more precise. Edit: To be honest the average speed was just added a little idea, it's just a gimmick more than anything else, it's not precise enough to do anything useful with it. As I said, I'll research different ways to do it tomorrow).
OK - I will change it from Kyoto to Kyoto Ring, I never really thought about it before.
Nope, there were no changes to the XSL file in the last release.
LOL - OK, I take it back, I guess the average speed 'bug' really is a bug. Funny how sometimes you just accept some things because you can justify the way you think they work in your head. I broke the formula down into separate variables so I could watch each step of the calculation in the debugger, and I found that when I was converting the times from milliseconds (which is how LFSPoints treats all times internally) into seconds (EG milliseconds / 1000), I was unintentionally casting the resulting seconds into an integer, which meant I was loosing the decimal part of the result. When I changed it to implicitly cast the seconds into a float, the average speeds suddenly became hugely more varied. Just one of those tiny bugs that can easily pass you by... I'll roll out a fix in the next version.
I'm quite pleased, as I spent the day learning about and struggling with character encodings, but now LFSPoints supports all the different character encodings used by LFS. Basically, this means no more ???? in driver names, which is a very good thing.
As always I hope it works. There are still a couple of little things to fix mind you... Please let me know if you spot any oddities in driver names.