Hi Noel, just a quick note, haven't gotten arround to testing this but a quick look showed that this might indeed be the culprit.
Atm i have little time to test but there's others as well whom are working on this thing. It does give us the issue of changing the mod itself (as aposed to what we do now and offer both original and the tweaked mod) and i'm not sure if we would want to do that.
Anyways, will test this out soon, if anything just to give you the propor feedback ensuring it was not the checker itself.
thx man :-)
Noel, sorry for the late update man.
I can confirm it is indeed the lack correct of .veh entries that causes these errors.
Sadly that means we will not be able to use this mod for such upgrades but i thank you for your time and effort trying to help us out. Much appreciated!
Can the Upgrade Checker be used on a Dedicated Server as well? Works fine on the client - but can't get it working on the server !
Thanks in advance
You can't take an XML and copy it to another computer and run it through my tool unless you have the mod installed on that machine too. The upgrade code is meaningless to my tool unless it also has access to the upgrades.ini for that mod. The tool parses the config.ini to find the path to your rFm folder... then it reads the rFm for the mod used in the XML file, then it reads all the VEH files for the mod until it finds the one that matches the car your checking and then from there it knows which upgrades.ini to read.
So, it should work on a client or server as long as you have the mod installed and you are running my tool from the root folder of your rF install.
thanks for your quick response.
What we are trying to achieve is exactly what you are recommending. We would like tzo verify the upgrades used by the driver based on the log file on the server with the rFUpgradesCheck installed on the same server.
We did some further testing and and it seems that the error message "System.ArgumentOutOfRangeException: InvalidArgument=Value mit dem Wert 0 ist für SelectedIndex ungültig" just appears it you try to load a log file containing 0 laps.
Attached you can find a log file which causes the failure.
It shouldn't matter if there is a lapcount in the log. I don't even pay any attention to the laps. This log works okay on a client machine though?
To figure out exactly what is going on I will probably need the whole mod.
But first, give this version of my tool a shot. I have made some changes and fixed a few bugs that I haven't officially released. Maybe one of the bugs I fixed will solve your problem.
I'm trying to decode UpgradeCode in php for checking the upgrade that drivers are using. But I can not find the rules that determines the order of each upgrade code in the whole string UpgradeCode.
I can decode each part of the whole string, but I can't find the order they are aranged in the whole string.
Do you have any information about that?
Thanks en advance...
The first few posts should answer your question, if you understand bitfields and hex. The upgrades should be applied in order as they appear in the upgrades file.
decoding the binary image of each upgradetype is not the problem.
When I have done some testing to understand the order of each UpgradeType in the whole string (ex: f9217701 00000000), it seemed that it wasn't always in the order as they appear in the upgrade file.
But I will check it again and give you a new status.
Thanks for a so quick answer!
Just be aware they aren't kept separate, so if an upgrade has 3 options it only needs 2 bits and will be combined with, say, another upgrade with 5 options that therefore needs 3 bits, and another with 9 options which occupies 5 bits takes the total to 10 but the two highest bits will then be in the 2nd byte. So yeah, easiest to play with a couple of combinations to work out exactly how your upgrades are represented.