Magic Data Discussion
Posted by TomMK
I was able to confirm the conversion factor for desc48 (fuel per lap) of 2979 = 1 kg. Never found a proper explanation of where it came from, so here it is:
The exact conversion factor (for pounds) is 1048576 / int(437318/563), which results in 1351.2577; converting to kg, the factor is 2979.0133.
Constants 437318 and 563 are stored in GP4.exe, in offsets 0x202A48 and 0x202A40, respectively, in decrypted v1.02. These constants are also used elsewhere in the code for yet unknown reasons so I wouldn't advise changing them.
My unfinished tracks: [www.grandprixgames.org]
Send bug reports and track editing questions to f1virtualblog@gmail.com
The exact conversion factor (for pounds) is 1048576 / int(437318/563), which results in 1351.2577; converting to kg, the factor is 2979.0133.
Constants 437318 and 563 are stored in GP4.exe, in offsets 0x202A48 and 0x202A40, respectively, in decrypted v1.02. These constants are also used elsewhere in the code for yet unknown reasons so I wouldn't advise changing them.
My unfinished tracks: [www.grandprixgames.org]
Send bug reports and track editing questions to f1virtualblog@gmail.com
I don't have so much time for GP4 at the moment, sorry for that. Anyway, many thanks to Prblaco for identifying the detailed function of this feature and sharing it with the community, great!
And, of course, many thanks to TomMK for sharing his descriptions.txt-file with the whole community, as well! That was exactly, what I was looking for
!
And, of course, many thanks to TomMK for sharing his descriptions.txt-file with the whole community, as well! That was exactly, what I was looking for
!Hi superman77m,
Let me go through an example. Here is a screenshot of the 2009 Turkish Grand Prix.
2009 was the last year F1 had refueling, and we had info about consumption available on broadcast. Based on this pitstop for Vettel, we know that 54 litres = 16 laps (these values are rounded, so we'd need to check multiple pitstops to get an average, but it's not relevant for this example), so 1 lap = 54/16 = 3.375 litres.
For magic data we need to know the mass of fuel. A good approximation is that 1 litre of fuel = 0.75 kg, so 3.375 litres/lap = 2.53125 kg/lap. We multiply this value by 2979 and the result is 7540.627, so the fuel value in magic data is 7541 (rounded to nearest integer).
Istanbul is a 5.338 km circuit, so by our calculations we get that average consumption is around 0.47 kg/km. That means your calculation of 2979 units of fuel per km is exaggerated, it should be 2979 per kg. It's important to pay attention to this distinction.
For modern F1 cars, we don't have refueling info but we have a limit of 110 kg on the fuel tank. Each race lasts at least 305 km, so can estimate fuel consumption as 110 kg/305 km = 0.36 kg/km. Using again Istanbul, we'd then multiply this value by the track length to get kg/lap, 0.36 kg/km * 5.338 km/lap = 1.92 kg/lap, then multiply this again by 2979 and the magic data value is approximately 5735 (in other words, modern cars use around 25% less fuel per lap than those of the V8 era).
Just for completeness I'll also talk about Monaco, which is the only race to run for 260 km. A quick Google search says that teams use just over 90 kg of fuel there, that would yield 0.35 kg/km, not that different from any other race.
-----
Now about "Fuel Consumption Player" (desc70) and "Fuel Consumption AI" (desc71). Both values are multipliers, with 16384 meaning 100%. "100% of what", you ask: I have no idea (maybe there's some "master consumption" hidden in GP4.exe, but again that's not relevant here). That does mean, however, that a fuel consumption value of 24576 will make cars spend fuel 50% faster, and a value of 8192 will make cars spend fuel 50% slower. To set these I have no better method than trial and error.
Let's say we initially set Fuel Consumption AI to 16384 (100%). Then run an AI-only race, so you can check their fuel level in the steering wheel. Let's say one of the cars starts the race with 28.0 laps of fuel. As this car completes lap number 10, let's say it has 16.2 laps of fuel. So it has spent 11.8 laps of fuel in 10 laps, which means it's burning fuel faster than expected and we need to reduce the Fuel Consumption value. It's good to repeat this process with at least two or three different cars to get a good average, or across different numbers of laps, since there's always some slight variation.
With this data in hand, you can adjust the Fuel Consumption value. We multiply the current value (in this case 16384) by the amount of fuel we expected to burn (in this case 10) and divide by the amount of fuel actually burned (in this case 11.8). The result is 13885, so this is the value we update in magic data. For player the process is the same, except you have to drive it yourself. And if you can get a friend to also drive and be your second opinion then better, since driving styles do influence fuel consumption.
Also refer to the table posted by Soutsen on the previous page for reference values for the original tracks. Fuel Consumption Player is always a little higher than Fuel Consumption AI.
And don't forget that all these calculations assume that fuel per lap (desc48) is correct, so be sure to set that value first.
My unfinished tracks: [www.grandprixgames.org]
Send bug reports and track editing questions to f1virtualblog@gmail.com
Let me go through an example. Here is a screenshot of the 2009 Turkish Grand Prix.
2009 was the last year F1 had refueling, and we had info about consumption available on broadcast. Based on this pitstop for Vettel, we know that 54 litres = 16 laps (these values are rounded, so we'd need to check multiple pitstops to get an average, but it's not relevant for this example), so 1 lap = 54/16 = 3.375 litres.
For magic data we need to know the mass of fuel. A good approximation is that 1 litre of fuel = 0.75 kg, so 3.375 litres/lap = 2.53125 kg/lap. We multiply this value by 2979 and the result is 7540.627, so the fuel value in magic data is 7541 (rounded to nearest integer).
Istanbul is a 5.338 km circuit, so by our calculations we get that average consumption is around 0.47 kg/km. That means your calculation of 2979 units of fuel per km is exaggerated, it should be 2979 per kg. It's important to pay attention to this distinction.
For modern F1 cars, we don't have refueling info but we have a limit of 110 kg on the fuel tank. Each race lasts at least 305 km, so can estimate fuel consumption as 110 kg/305 km = 0.36 kg/km. Using again Istanbul, we'd then multiply this value by the track length to get kg/lap, 0.36 kg/km * 5.338 km/lap = 1.92 kg/lap, then multiply this again by 2979 and the magic data value is approximately 5735 (in other words, modern cars use around 25% less fuel per lap than those of the V8 era).
Just for completeness I'll also talk about Monaco, which is the only race to run for 260 km. A quick Google search says that teams use just over 90 kg of fuel there, that would yield 0.35 kg/km, not that different from any other race.
-----
Now about "Fuel Consumption Player" (desc70) and "Fuel Consumption AI" (desc71). Both values are multipliers, with 16384 meaning 100%. "100% of what", you ask: I have no idea (maybe there's some "master consumption" hidden in GP4.exe, but again that's not relevant here). That does mean, however, that a fuel consumption value of 24576 will make cars spend fuel 50% faster, and a value of 8192 will make cars spend fuel 50% slower. To set these I have no better method than trial and error.
Let's say we initially set Fuel Consumption AI to 16384 (100%). Then run an AI-only race, so you can check their fuel level in the steering wheel. Let's say one of the cars starts the race with 28.0 laps of fuel. As this car completes lap number 10, let's say it has 16.2 laps of fuel. So it has spent 11.8 laps of fuel in 10 laps, which means it's burning fuel faster than expected and we need to reduce the Fuel Consumption value. It's good to repeat this process with at least two or three different cars to get a good average, or across different numbers of laps, since there's always some slight variation.
With this data in hand, you can adjust the Fuel Consumption value. We multiply the current value (in this case 16384) by the amount of fuel we expected to burn (in this case 10) and divide by the amount of fuel actually burned (in this case 11.8). The result is 13885, so this is the value we update in magic data. For player the process is the same, except you have to drive it yourself. And if you can get a friend to also drive and be your second opinion then better, since driving styles do influence fuel consumption.
Also refer to the table posted by Soutsen on the previous page for reference values for the original tracks. Fuel Consumption Player is always a little higher than Fuel Consumption AI.
And don't forget that all these calculations assume that fuel per lap (desc48) is correct, so be sure to set that value first.
My unfinished tracks: [www.grandprixgames.org]
Send bug reports and track editing questions to f1virtualblog@gmail.com
Terrific explanation teacher Paulo. 
My Grand Prix 4 Files
I'm a total dick. How many people can say that?
A quick search through GP4 code and I can't find any references to desc 38-41 and 43-44, so I believe "unused" is correct as it was in the earlier pages of this thread. In truth the values are read and stored once, but only during the general "load magic data" routine and then never again.
Desc49 is used once in the code and only in certain conditions but I can't make any sense of it, other than the explanation we already have.
My unfinished tracks: [www.grandprixgames.org]
Send bug reports and track editing questions to f1virtualblog@gmail.com
Desc49 is used once in the code and only in certain conditions but I can't make any sense of it, other than the explanation we already have.
// GP4 v1.02 offsets 0x02ff6d to 0x02ffcc
if (currentCar.var_09C.bit1 | opponentCar.var_09C.bit1) {
ax = sub_40DC8A(currentCar, opponentCar); // GP4 v1.02 only
} else {
ax = opponentCar.var_0E2 - currentCar.var_0E2;
}
var_603E70 = ax;
if (currentCar.var_0CE.bit7) {
cx = ax - var_62D208; // var_62D208 = magic data desc49
} else {
cx = ax - var_603BA2;
}
dx = currentCar.var_09A / 128; // var_09A = speed, 128 = 2 ft/s
if (dx >= cx) {
currentCar.var_0CB.bit0 = true;
}My unfinished tracks: [www.grandprixgames.org]
Send bug reports and track editing questions to f1virtualblog@gmail.com
Thinking a bit more about the current desc49 explanation, and the piece of code it's used, I'm trying to make some sense of it.
At first it doesn't make much sense to compare distance (ax and cx variables) with speed (dx variable), but actually this can be used to estimate the gap between two cars. For example, if both cars are running at 100 m/s and they are 100 m apart, it means the gap between them is 1 second. If they are 50 m apart at the same speed then the gap is 0.5 seconds and so on.
Back to the formula. Let's assume that ax is simply the distance between both cars (ignoring whatever comes out of GP4 v1.02-only function sub_40CD8A). If desc49 is zero, then the final condition (dx >= cx) is true if the gap between both cars is 0.5 seconds or less.
If everything up to this point is true, the main takeaway is that it's something that activates when cars are close.
Now let's put desc49 back into play. Its effect is to extend the distance in which the final condition is true. It's a fixed distance rather than a fixed time gap. So a desc49 of 128 (default value in 10 of the original tracks) would mean an extension of 128 feet (39 metres) which is roughly 0.7 seconds at 200 km/h or 0.45 seconds at 300 km/h. These are added to the "default" 0.5 second gap.
Which means, desc49 increases the gap in which this unknown effect activates. Since klausfeldmann already ruled out this influencing the defensive behavior of the AI, we can only guess for now.
Also assuming desc49 is a signed 2-byte integer, its maximum is 32767 and any values above that are interpreted as negative (up to 65535).
var_603BA2, which is under certain conditions used instead of desc49, has a fixed value of 64.
Desc49 can also be interpreted in terms of track sectors. Since each sector is 16 feet, a value of 128 means 8 sectors; so the gap for the unknown effect to activate would be 0.5 seconds + 8 sectors. For the other values used in original tracks, 256 = 16 sectors, 384 = 24 sectors and 512 = 32 sectors.
My unfinished tracks: [www.grandprixgames.org]
Send bug reports and track editing questions to f1virtualblog@gmail.com
At first it doesn't make much sense to compare distance (ax and cx variables) with speed (dx variable), but actually this can be used to estimate the gap between two cars. For example, if both cars are running at 100 m/s and they are 100 m apart, it means the gap between them is 1 second. If they are 50 m apart at the same speed then the gap is 0.5 seconds and so on.
Back to the formula. Let's assume that ax is simply the distance between both cars (ignoring whatever comes out of GP4 v1.02-only function sub_40CD8A). If desc49 is zero, then the final condition (dx >= cx) is true if the gap between both cars is 0.5 seconds or less.
If everything up to this point is true, the main takeaway is that it's something that activates when cars are close.
Now let's put desc49 back into play. Its effect is to extend the distance in which the final condition is true. It's a fixed distance rather than a fixed time gap. So a desc49 of 128 (default value in 10 of the original tracks) would mean an extension of 128 feet (39 metres) which is roughly 0.7 seconds at 200 km/h or 0.45 seconds at 300 km/h. These are added to the "default" 0.5 second gap.
Which means, desc49 increases the gap in which this unknown effect activates. Since klausfeldmann already ruled out this influencing the defensive behavior of the AI, we can only guess for now.
Also assuming desc49 is a signed 2-byte integer, its maximum is 32767 and any values above that are interpreted as negative (up to 65535).
var_603BA2, which is under certain conditions used instead of desc49, has a fixed value of 64.
Desc49 can also be interpreted in terms of track sectors. Since each sector is 16 feet, a value of 128 means 8 sectors; so the gap for the unknown effect to activate would be 0.5 seconds + 8 sectors. For the other values used in original tracks, 256 = 16 sectors, 384 = 24 sectors and 512 = 32 sectors.
My unfinished tracks: [www.grandprixgames.org]
Send bug reports and track editing questions to f1virtualblog@gmail.com
Quote
zifox
Where does the snippet of code your posted come from ? Is it decompiled code from the executable that you are reworking to have meaningful names ? (and commentaries ?)
Actually I use a disassembler which converts the .exe instructions like shown below (it's the same section I posted yesterday). Then I search for sections of interest and translate them into "regular" code by hand, but I don't care if it compiles back into the same instructions, and most of the time even if it compiles at all. In this case I knew from previous experiments that magic data desc49 is stored in variable word_62D208 which made searching easier.
As for the logical question, am I aiming for a full source code decompilation? No, it would need too much time, too much knowledge, and Mr. Crammond would probably want his secrets to remain hidden.
.text:0042FF6D F6 86 9C 00 00 00 02 test byte ptr [esi+9Ch], 2 .text:0042FF74 75 19 jnz short loc_42FF8F .text:0042FF76 F6 83 9C 00 00 00 02 test byte ptr [ebx+9Ch], 2 .text:0042FF7D 75 10 jnz short loc_42FF8F .text:0042FF7F 66 8B 83 E2 00 00 00 mov ax, [ebx+0E2h] .text:0042FF86 66 2B 86 E2 00 00 00 sub ax, [esi+0E2h] .text:0042FF8D EB 05 jmp short loc_42FF94 .text:0042FF8F E8 F6 DC FD FF call sub_40DC8A .text:0042FF94 66 A3 70 3E 60 00 mov word ptr dword_603E70, ax .text:0042FF9A 66 8B C8 mov cx, ax .text:0042FF9D F6 86 CE 00 00 00 80 test byte ptr [esi+0CEh], 80h .text:0042FFA4 74 09 jz short loc_42FFAF .text:0042FFA6 66 2B 0D 08 D2 62 00 sub cx, word_62D208 .text:0042FFAD EB 07 jmp short loc_42FFB6 .text:0042FFAF 66 2B 0D A2 3B 60 00 sub cx, word_603BA2 .text:0042FFB6 66 8B 96 9A 00 00 00 mov dx, [esi+9Ah] .text:0042FFBD 66 C1 FA 07 sar dx, 7 .text:0042FFC1 66 3B D1 cmp dx, cx .text:0042FFC4 7C 07 jl short loc_42FFCD .text:0042FFC6 80 8E CB 00 00 00 01 or byte ptr [esi+0CBh], 1
My unfinished tracks: [www.grandprixgames.org]
Send bug reports and track editing questions to f1virtualblog@gmail.com
Quote
klausfeldmann
Is it at least secure that var_0CB.bit0 is used anywhere later in the source code, if var_0CB.bit0 is true?
Yes, there is a function that checks it once for currentCar. This function's output is the same if either var_0CB.bit0 is false, or if there is no opponent car. That's all I've figured out so far.
My unfinished tracks: [www.grandprixgames.org]
Send bug reports and track editing questions to f1virtualblog@gmail.com
Okay, I have news to report. Desc49 is used only at the start of a race.
Remember this bit from the code:
Or, in original assembly:
Desc49 is used only when var_0CE.bit7 is enabled, and bit7 can also be written 0x80 in hexadecimal. Remember the original description for desc73 (rail-line length)? a segment nr before which flag 0x80 in car.flags_ce is not cleared. It happens to be the exact same variable. So, during a race start, when that bit is set, the game uses desc49. After the first couple of corners, then it reverts to the smaller value of 64 stored in variable 603BA2.
So I made a quick patch to use desc49 for the whole race (changing byte at 0x02FFA5 from 09 to 00), set desc49 to 4096 (8 times the original value at Monza) and analysed the changes.
Turns out I didn't notice any change in slipstreaming behavior. However, AI cars were yielding position much much earlier than what they normally would, to the point of ridiculousness: on the first chicane at Monza, a car nearly stopped around the 150-meter mark so I could pass him, and I wasn't even close to the braking zone! The same happened before the Lesmo corners.
Then I did the opposite test: set desc49 to zero and watched how it affected race starts. It became a bit more difficult to outbrake the whole grid on the inside, because cars would go three-wide more often. They still yielded if I got close enough, but nowhere near the wide open avenue of the default settings.
Finally, going back to the original values for desc49, it seems quite reasonable to me that it's lower when the starting straight is short or the first corner is fast; and higher when it's the opposite.
My unfinished tracks: [www.grandprixgames.org]
Send bug reports and track editing questions to f1virtualblog@gmail.com
Remember this bit from the code:
if (currentCar.var_0CE.bit7) {
cx = ax - var_62D208; // var_62D208 = magic data desc49
} else {
cx = ax - var_603BA2;
}Or, in original assembly:
.text:0042FF9D F6 86 CE 00 00 00 80 test byte ptr [esi+0CEh], 80h .text:0042FFA4 74 09 jz short loc_42FFAF .text:0042FFA6 66 2B 0D 08 D2 62 00 sub cx, word_62D208 .text:0042FFAD EB 07 jmp short loc_42FFB6 .text:0042FFAF 66 2B 0D A2 3B 60 00 sub cx, word_603BA2
Desc49 is used only when var_0CE.bit7 is enabled, and bit7 can also be written 0x80 in hexadecimal. Remember the original description for desc73 (rail-line length)? a segment nr before which flag 0x80 in car.flags_ce is not cleared. It happens to be the exact same variable. So, during a race start, when that bit is set, the game uses desc49. After the first couple of corners, then it reverts to the smaller value of 64 stored in variable 603BA2.
So I made a quick patch to use desc49 for the whole race (changing byte at 0x02FFA5 from 09 to 00), set desc49 to 4096 (8 times the original value at Monza) and analysed the changes.
Turns out I didn't notice any change in slipstreaming behavior. However, AI cars were yielding position much much earlier than what they normally would, to the point of ridiculousness: on the first chicane at Monza, a car nearly stopped around the 150-meter mark so I could pass him, and I wasn't even close to the braking zone! The same happened before the Lesmo corners.
Then I did the opposite test: set desc49 to zero and watched how it affected race starts. It became a bit more difficult to outbrake the whole grid on the inside, because cars would go three-wide more often. They still yielded if I got close enough, but nowhere near the wide open avenue of the default settings.
Finally, going back to the original values for desc49, it seems quite reasonable to me that it's lower when the starting straight is short or the first corner is fast; and higher when it's the opposite.
My unfinished tracks: [www.grandprixgames.org]
Send bug reports and track editing questions to f1virtualblog@gmail.com
Sorry, only registered users may post in this forum.