<UpgradeCode> tag in the results file

Noel Hibbard

Has anyone ever been able to figure out how the <UpgradeCode> tag works in the XML results files? I would like to know how to verify that people have the correct upgrades installed once a race is over.
 
This explanation requires understanding of how the upgrade code is nothing more than a series of bits (but displayed in hexadecimal, IIRC).

Each upgrade type, depending on the number of available levels, gets a number of bits assigned to it. If there are only two levels, it requires one bit. If there are 3 or 4 levels, it requires 2 bits. 5,6,7,8 -> 3 bits, etc. These bits are allocated from the full upgrade code, which is 64 bits.

The first upgrade type uses the least significant bits, the second upgrade type uses the next bits, etc., so it's packed fairly tight. The current level is stored in binary inside the allocated bits.

You might try an easy test with a car that has only one upgrade. Try different numbers of levels, and then also change the selected level and see how the code changes.

Hope that helps.
 
Thanks Bee... That gives me some idea. Now I need to do some trial and error. If I can figure it out I may be able to write a little program that will read the XML results and then display the upgrades that each driver used. This would be really handy for admins.
 
I thought I figured it out but now I am confused.

0 = Option 0 (default)
1 = Option 1
2 = Option 2
4 = Option 3
8 = Option 4
12 = Option 5
16 = Option 6
32 = Option 7
64 = Option 8

It made sense until that 12 was thrown in. To me a 12 would have indicated that Option 3 and Option 4 were both installed. So now I am confused again. Hahaha.
 
It looks like the upgrade groups have some effect on how the options are valued.
 
12 = Option 5
Not sure I understand how you came up with that as a bit value?
 
Scratch what I said before. I thought I understood how it work at that time. I am still a little confused right now but here are some tests I did. I only selected one upgrade at a time. On this list I show at the far right which upgrade was selected. The first number it the upgrade group and the second number is the level. Level one would be default.

<UpgradeCode>00000000 00000000</UpgradeCode> 1 1
<UpgradeCode>01000000 00000000</UpgradeCode> 1 2
<UpgradeCode>02000000 00000000</UpgradeCode> 1 3

<UpgradeCode>00000000 00000000</UpgradeCode> 2 1
<UpgradeCode>04000000 00000000</UpgradeCode> 2 2
<UpgradeCode>08000000 00000000</UpgradeCode> 2 3
<UpgradeCode>0c000000 00000000</UpgradeCode> 2 4
<UpgradeCode>10000000 00000000</UpgradeCode> 2 5

<UpgradeCode>00000000 00000000</UpgradeCode> 3 1
<UpgradeCode>20000000 00000000</UpgradeCode> 3 2
<UpgradeCode>40000000 00000000</UpgradeCode> 3 3
<UpgradeCode>60000000 00000000</UpgradeCode> 3 4
<UpgradeCode>80000000 00000000</UpgradeCode> 3 5
<UpgradeCode>A0000000 00000000</UpgradeCode> 3 6
<UpgradeCode>C0000000 00000000</UpgradeCode> 3 7
<UpgradeCode>E0000000 00000000</UpgradeCode> 3 8
<UpgradeCode>00010000 00000000</UpgradeCode> 3 9

<UpgradeCode>00000000 00000000</UpgradeCode> 4 1
<UpgradeCode>00020000 00000000</UpgradeCode> 4 2
<UpgradeCode>00040000 00000000</UpgradeCode> 4 3

<UpgradeCode>00000000 00000000</UpgradeCode> 5 1
<UpgradeCode>00100000 00000000</UpgradeCode> 5 2
<UpgradeCode>00200000 00000000</UpgradeCode> 5 3
 
Never mind.. Figured it out. And you explained it exactly how it is. Hahaha. I am just a little slow I guess. You can't read the upgradecode without first knowing what upgrades are available for the car so you know how many bits are allocated for each upgrade for the car.

Thanks again Bee for your assistance!
 
So I was sick and took the day off work so I figured I would right this Upgrade Checker app. For pathing reasons you have to install it in your rFactor root directory. If you open an XML results file for a mod that isn't installed in this rFactor root then it will not work. If you have more then one install that you want to use this app with then you will have to install it for each rFactor install. This app will mostly be used by admins and I am sure they will understand the pathing issues.

Here is a screen shot:
2010-12-22_162216.png


And here is a download link:
http://storage.srrs-racing.net/Misc/Upgrade Checker 0.95.exe

Oh yeah, this app requires dotNet 2.0 which most people probably have by now.

Thanks again Bee for your assistance!
 
Last edited:
Noel can i ask you something quickly since its silly to create an account on your website just for a quick question :)

We have added weights to our mod (F171) as upgrades. it ranges from 0 to 100KG. drivers select their own weight and after the race we check if they took the correct ones.

We are seeing that not all weights are displayed proporly in the checker. for example a driver with 80kg's shows as 5KG's in the checker or 80 shows as 40KG (yes we tested it ourselfes)

I see somewhere in your threads that the mod needs to be installed proporly in rf and the checker must be in root.

Now, we have kept F171 vannila, created a secondary league mod with adjusted hdv and upgrade ini's and people can switch to either one using a batch file.
Could this be the problem? Because the mod is not 100% where it should be?
mod folders: F171 and then either F1-71OrigFiles or F1-71TWFCFiles.

This thing is doing my head in, i cant find the source for the errors and the mod-split might be it?

Any advise is appreciated :)
 
Thx for your reply Noel,

We are allready using 1.00

All we did basicly was adding the weight upgrades to each car's upgrade.ini

So for example the F171 Mclaren upgrade ini looks like this:
Code: 
UpgradeType="Gear Indicator"
{
Instance="COCKPIT"

  Incremental=1

    UpgradeLevel="Hide Gear Indicator"
  {
    Description="Hide Gear Indicator"
    GEN=<COCKPITex>="//"
         GEN=<COCKPITex>="//"

  }

  UpgradeLevel="Show Gear Indicator"
  {
    Description="Show Gear Indicator"
    GEN=<COCKPITex>=""
        GEN=gear_indicator.gmt

  }
}


UpgradeType="FFB"
{
  Incremental=1

  UpgradeLevel="Assist Level 3"
  {
    Description="Maximum Assist, Lightest Steering"

    HDV=[CONTROLS]
    HDV=SteeringFFBMult*=1
  }

  UpgradeLevel="Assist Level 2"
  {
    Description="Decreased Assist, Heavier Steering"

    HDV=[CONTROLS]
    HDV=SteeringFFBMult*=3.5
  }

  UpgradeLevel="Assist Level 1"
  {
    Description="Minimum Assist, Heaviest Steering"

    HDV=[CONTROLS]
    HDV=SteeringFFBMult*=5.0
  }
}

  UpgradeType="Shifting Type"
  {
  
  UpgradeLevel="autoblip"
  {
    Description="Paddle type shifting with clutch time"

     HDV=[DRIVELINE]
     HDV=SemiAutomatic=0
     HDV=UpshiftDelay=0.21
     HDV=UpshiftClutchTime=0.21
     HDV=DownshiftDelay=0.21
     HDV=DownshiftClutchTime=0.35
     HDV=DownshiftBlipThrottle=0.05 
  } 
       
  
UpgradeLevel="no autoblip"
  {
    Description="H type Shifting no clutch time"

    HDV=[DRIVELINE]
    HDV=SemiAutomatic=0
    HDV=UpshiftDelay=0.20
    HDV=UpshiftClutchTime=0.00
    HDV=DownshiftDelay=0.20
    HDV=DownshiftClutchTime=0.00
    HDV=DownshiftBlipThrottle=0.00 

  }

UpgradeType="Arms"
{
  Instance="WHEEL"
  UpgradeLevel="Arms"
  {
    Description="Arms"
    GEN=<WHEELEXISTS>=""
    GEN=<arms>=arms.gmt
    GEN=<LEGSEXISTS>=""
    GEN=Legs.gmt
  }
  UpgradeLevel="No Arms"
  {
    Description="No Arms"
    GEN=<WHEELEXISTS>="//"
    GEN=<arms>=arms.gmt
    GEN=<LEGSEXISTS>="//"
    GEN=<LEGSEXISTS>="//"
  }
}

UpgradeType="Areo Package"
{
  Instance="DEBRIS0"
  UpgradeLevel="areo1"
  {
    Description="areo1"
    GEN=<DEBRIS0EXISTS>="//"
    GEN=<intake>=air_1a.gmt
  }
  UpgradeLevel="areo2"
  {
    Description="areo2"
    GEN=<DEBRIS0EXISTS>=""
    GEN=<intake>=air_1a.gmt
  }
}

UpgradeType="Areo Package"
{
  Instance="RWING"
  UpgradeLevel="areo1"
  {
    Description="areo1"
    GEN=<RWINGEXISTS>=""
    GEN=<rwing>=rwinga.gmt
  }
  UpgradeLevel="areo2"
  {
    Description="areo2"
    GEN=<RWINGEXISTS>=""
    GEN=<rwing>=rwinga_2.gmt
  }
}

  }
UpgradeType="Laptime Reset"
{
  UpgradeLevel="Option 1"
  {
    Description="Change from option 1 to 2 (or vice versa) to delete any existing qualifying lap times"
  }

  UpgradeLevel="Option 2"
  { 
    Description="Change from option 1 to 2 (or vice versa) to delete any existing qualifying lap times"
  }
}

UpgradeType="Weight"
{
Incremental=0

Instance="REWARDS"

  UpgradeLevel="none"
  {
    Description="none"
    IconLevel=0
  }
  UpgradeLevel="+5 kg"
  {
    Description="+5 kg"
    IconLevel=0
    HDV=[GENERAL]
    HDV=Mass+=5
   }
  UpgradeLevel="+10 kg"
  {
    Description="+10 kg"
    IconLevel=0
    HDV=[GENERAL]
    HDV=Mass+=10
  }
  UpgradeLevel="+15 kg"
  {
    Description="+15 kg"
    IconLevel=0
    HDV=[GENERAL]
    HDV=Mass+=13.61
   }
  UpgradeLevel="+20 kg"
  {
    Description="+20 kg"
    IconLevel=0
    HDV=[GENERAL]
    HDV=Mass+=20
  }
  UpgradeLevel="+25 kg"
  {
    Description="+25 kg"
    IconLevel=0
    HDV=[GENERAL]
    HDV=Mass+=25
  }
  UpgradeLevel="+30 kg"
  {
    Description="+30 kg"
    IconLevel=0
    HDV=[GENERAL]
    HDV=Mass+=30
  }
  UpgradeLevel="+35 kg"
  {
    Description="+35 kg"
    IconLevel=0
    HDV=[GENERAL]
    HDV=Mass+=35
  }
  UpgradeLevel="+40 kg"
  {
    Description="+40 kg"
    IconLevel=0
    HDV=[GENERAL]
    HDV=Mass+=40
  }
  UpgradeLevel="+45 kg"
  {
    Description="+45 kg"
    IconLevel=0
    HDV=[GENERAL]
    HDV=Mass+=45
  }
  UpgradeLevel="+50 kg"
  {
    Description="+50 kg"
    IconLevel=0
    HDV=[GENERAL]
    HDV=Mass+=50
   }
  UpgradeLevel="+55 kg"
  {
    Description="+55 kg"
    IconLevel=0
    HDV=[GENERAL]
    HDV=Mass+=55
  }
  UpgradeLevel="+60 kg"
  {
    Description="+60 kg"
    IconLevel=0
    HDV=[GENERAL]
    HDV=Mass+=60
  }
  UpgradeLevel="+65 kg"
  {
    Description="+65 kg"
    IconLevel=0
    HDV=[GENERAL]
    HDV=Mass+=65
  }
  UpgradeLevel="+70 kg"
  {
    Description="+70 kg"
    IconLevel=0
    HDV=[GENERAL]
    HDV=Mass+=70
  }
  UpgradeLevel="+75 kg"
  {
    Description="+75 kg"
    IconLevel=0
    HDV=[GENERAL]
    HDV=Mass+=75
  }
  UpgradeLevel="+80 kg"
  {
    Description="+80 kg"
    IconLevel=0
    HDV=[GENERAL]
    HDV=Mass+=80
  }
  UpgradeLevel="+85 kg"
  {
    Description="+85 kg"
    IconLevel=0
    HDV=[GENERAL]
    HDV=Mass+=85
  }  
  UpgradeLevel="+90 kg"
  {
    Description="+90 kg"
    IconLevel=0
    HDV=[GENERAL]
    HDV=Mass+=90
   }
  UpgradeLevel="+95 kg"
  {
    Description="+95 kg"
    IconLevel=0
    HDV=[GENERAL]
    HDV=Mass+=95
  }
  UpgradeLevel="+100 kg"
  {
    Description="+100 kg"
    IconLevel=0
    HDV=[GENERAL]
    HDV=Mass+=100
  }

The wierd thing is, eventhough the upgradechecker tells us a car used +5kg it was in fact 80KG. and 80KG was also selected by the driver, plus it did 'feel' like 80KG's and gave the required preformance.
So it was never 5KG to begin with.
Same for the 80KG usage showing as 40KG in the checker.


The 'main' F171_Upgrades.ini in the mod-root also has the same weight upgrades btw.
 
I think, there should be brackets (" } ") at the end of the file. Sorry if thats not the case.
 
I am downloading F171 right now and then I will add the code you quoted and then I will try to debug this thing. It is possible Type-R is right though. I will report back shortly.
 
Okay I am on to something. It has to do with UpgadeType="Areo Package" being in the file twice. rFactor consolidates it into one category but my tool does not. So the bitmap from rFactor doesn't match the bitmap my tool expects. Long story but I should be able to fix the problem.

I should have a fix posted at NoGrip shortly.
 
Hi Noel,

Thx allot for your response, updating the checker was way beyond what i expected from this so many kudo's for you :)

We have done a series of tests with v1.01, including Type-R's suggestion (thx for that) and unfourtunately we are still stuck with the same results.

The new checker now also shows the mods that are available (or that it recognizes) and F171 was part of the list.
However, as previously mentioned, we have split up F171 into 2 parts, original and league, with a batch file enabling a user to change back and forth.
I thought this was the problem but after installing the upgrade checker in my 2nd rfactor, adding the upgrades to a fresh and unmodified F171 installment it came back with the same results. some cars will give the correct values, others not. Yet the assigned weights where in effect on-track.

Since we grabbed the weight upgrades from another mod (SCC) and changed some of the weights i decided to add the original upgrades from SCC to the fresh F171. same result, no luck.
SCC itself seems fine with the checker but thats inconclusive because we dont have the time to test all cars innit so i'm not sure if it 100% works in SCC using original upgrades.


I'm beginning to think there's more to it then just upgrade files, there might be entries in hdv/scn/whatever files that communicate with all this beneath the surface. i've tried to find them, also in SCC to compare entries in files. can find nawt.
And tbh, i'm not too experienced with altering mods.

I dont expect anyone to dive to deep into this on our account, i was just hoping i could get a quick fix here since we have been at it for weeks trying to figure it out but atm its looking like we will have to use mass.ini's again.

Thx allot guys, your help is much appreciated :)
 
Just a real quick check is to be sure you are really running 1.0.1.0. It is possible my installer isn't overwriting the old one properly. To check the version just right click on the EXE and then select properties and then click the details tab. It should show 1.0.1.0 on the file version. I am going to look through my code one more time to be sure I am not missing something.
 
Also, a little info on how my tool finds the upgrades files. First it reads the config.ini which is in the same directory as the upgrade checker. From the config.ini it gets the path to your rFm directory. Then it reads every *.rfm file in the rFm directory to get a list of each mod you have installed (within this install). From the *.rfm files it get the mod name and the "vehiclesdir=" for each mod. Then when you double click on a mod it then reads all the *.veh files in the "vehiclesdir=" (including subdirs) for that mod and generates a list of cars. Then when you double click on a car it reads the *.veh and looks for the "Upgrades=" line which tells it the path to the upgrade.ini for that car. It then reads the upgrade.ini file and generates a list of all the upgrades for that car.

So fo rthe cars that don't work with my tool, check the veh file for that file to verify the path to the upgrade.ini and then copy and past the code from the upgrades.ini and I will look into it.

We will figure this out I am sure.
 
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.
 
Noel,

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.

View attachment 11170
 
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.

https://dl.dropbox.com/s/buiwhq0djnktbuh/rFUpgradesCheck.exe
 
Hi,

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!

Olivier
 
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.
 
You must log in or register to reply here.

Back
Top