Magic Data Discussion

could you try with 20000 and 40000 as you're on it ?

Lo2k schrieb:
-------------------------------------------------------
> could you try with 20000 and 40000 as you're on it
> ?


Okay, I will do so tomorrow .

Nice to get your advice in this issue. I guess you know much better, what to do while checking how a feature works .

And one with 60000 if it's possible.
Yep, having results for these values could lead to same better interpretation, particulary if it is linked to tyre "wear" as it seems it is.

I just tested a lot of additional values. Now the pattern is much clearer, but the general use of the cc-shuffler is still a kind of mystery to me.

It affects the general laptime and the laptime development over a complete stint. With some cc-shuffler-values, the cars start quick and set a good time in the 2nd lap. Thereafter they are getting slower and slower for the next 30 laps, until they start to get faster again and set a new best time e.g. in 50th lap. Weird.

I took the whole data into an excel worksheet with some charts within. Here is a link:
[docs.google.com]

Lo2k schrieb:
-------------------------------------------------------
> And one with 60000 if it's possible.
> Yep, having results for these values could lead to
> same better interpretation, particulary if it is
> linked to tyre "wear" as it seems it is.


Lol, just uploaded my worksheet. It doesn't contain a 60,000-value, but a lot of other values. Tell me, if you still need the 60,000er cc-shuffler .



Edited 1 time(s). Last edit at 08/02/2013 02:53PM by klausfeldmann.

New Worksheet!

*60,000er cc-shuffler added
General results were confirmed by the new test .

Link:
[docs.google.com]

Thanks for all the testings
Hmm... You might joke, or not, but if we suppose it's an integer value, I thought it was a 2 bytes value... and it's a 4 bytes one.
Thus instead of a range -32768,32767 (or 0-65535), we have a 0-4,294,967,295 range !
It might be long to test every 10 000 :p
Or maybe it must be read as two 2 bytes values and in this case, the actual 0-65535 range tests are enough, we just have to figure what we have in front of us...

PS: Also note that on your drawing, we have a false display of values because they are evenly spaced despite half of them are in the range 0-7500 and the second half in the 7500-65535 range.





Edited 1 time(s). Last edit at 08/02/2013 03:56PM by Lo2k.

Lo2k schrieb:
-------------------------------------------------------
> Thanks for all the testings
> Hmm... You might joke, or not, but if we suppose
> it's an integer value, I thought it was a 2 bytes
> value... and it's a 4 bytes one.
> Thus instead of a range -32768,32767 (or 0-65535),
> we have a 0-4,294,967,295 range !
> It might be long to test every 10 000 :p
> Or maybe it must be read as two 2 bytes values and
> in this case, the actual 0-65535 range tests are
> enough, we just have to figure what we have in
> front of us...

Huge range for sure! Why did they programm it as an 8 byte value when most of the tracks do only need values of about 3,000? Any idea?


> PS: Also note that on your drawing, we have a
> false display of values because they are evenly
> spaced despite half of them are in the range
> 0-7500 and the second half in the 7500-65535
> range.

Yes, you're right. Actually I'm good in Excel, but this time I was unable to tell Excel to use the first row just as x-axis-description. So, I needed to use simple index-numbers, which - in fact - deform the whole pattern .

Is there anything I can do to get to know the cc-shuffler better?

Well, you can gather data for laps 10/20/30/40 or try other cc-shuffler values in 0-65535 range to see if it confirms things.
Only if you have some time. On my side, I really don't know how to interpret these values so far.

Lo2k schrieb:
-------------------------------------------------------
> Well, you can gather data for laps 10/20/30/40 or
> try other cc-shuffler values in 0-65535 range to
> see if it confirms things.
> Only if you have some time. On my side, I really
> don't know how to interpret these values so far.


Allright. Is there a way to get AI's laptimes over a the whole stint automatically, like we can get the player's time in GPxlap-log:

End lap  0: car 11, racepos  1, time -:--.---, PO   0/  0%, 0.0s slomo
End lap  1: car 11, racepos  2, time 1:44.429, PO  49/117%, 0.8s slomo
End lap  2: car 11, racepos  2, time 1:37.865, PO  42/204%, 0.0s slomo
End lap  3: car 11, racepos  2, time 1:38.135, PO  41/ 86%, 0.0s slomo
End lap  4: car 11, racepos  2, time 1:37.880, PO  38/121%, 0.0s slomo
End lap  5: car 11, racepos  2, time 1:38.064, PO  36/ 71%, 0.0s slomo
End lap  6: car 11, racepos  2, time 1:38.067, PO  36/177%, 0.0s slomo
End lap  7: car 11, racepos  2, time 1:38.585, PO  39/ 74%, 0.0s slomo
End lap  8: car 11, racepos  2, time 1:39.031, PO  38/ 69%, 0.0s slomo
End lap  9: car 11, racepos  2, time 1:39.346, PO  37/ 64%, 0.0s slomo
End lap 10: car 11, racepos  2, time 1:39.223, PO  36/ 81%, 0.0s slomo
...

???


Just one thought for the interpretation of the values:
We have to consider, that the car has lost a lot of weight due to less fuel within it's 55-laps-stint. So a win of about 1.5 seconds till the end of the stint actually is a lost considdering the loss of weight.

Of course this can nevertheless not explain why the cc-shuffler causes with values of more than 20,000 faster laptimes again. It was especially with values of more than 40,000, that cars got slower at the beginning of the stint and getting faster again after about 30, so that they set new fastest laps from the 50th lap onwards again.

Maybe it is a kind of parameter to control how cc-cars do save their tyres over the whole stint!? It could be a kind of parameter / coefficient for a graph. And changing the parameter (cc-shuffler), changes the gradient of the graph in a coordinate plane as well.

You know what I mean? It's just an idea, how I would have implemented the feature for saving tyres.

Yep, I know what you mean, that's why it would be interesting to study lap times for a few races every x laps, at least for 2 cc-shuffler values, ie 1500 and 5000.
This way we could see evolution of lap times along the race and see if there's some pattern.

Lo2k Wrote:
-------------------------------------------------------
> Yep, I know what you mean, that's why it would be
> interesting to study lap times for a few races
> every x laps, at least for 2 cc-shuffler values,
> ie 1500 and 5000.
> This way we could see evolution of lap times along
> the race and see if there's some pattern.


Please see this thread for some cc shuffler related info..

[www.grandprixgames.org]

When making my Tahiti track I tried experimenting around with this. Setting tyre wear to 12000 and cc shuffler to 1000 gives the effect that laptimes get better over a stint. The cc shuffler value seems to be affect the weight of the fuel.
The AI would post their best laps just before pitting, which is realistic for pre-Pirelli F1. Cars on a one stopper, pitting on lap 40ish, would see their laptimes go from a 1:10 to a 1:08. AI on a two stop would see their laptimes get better by a second or so.
The effect is the same for the human player too.

re, the OP, if magic data is stored in the .dat why does Cmagic pull it from the exe ?

thx

F1Dev

nm, I read lo2k's post a bit further down.

Does anyone know if there's a definitive method of altering the MD for pitstops when running less than 100% ?

tia

F1Dev

I can't replicate this problem. Can you answer these for me:

1) Can you paste the Magic Data file you're trying to use?

2) How did you "install" the new magic data? Did you use CMagic or TSM?

3) How are you installing new tracks? TSM or GPxTrack?

4) Are you using CSM?

=====================================================


Intel NUC 8i3, 8GB RAM, MS Sidewinder Wheel

I'm using CSM & TSM, the pitstop info matches the info I insert into the .dat with CMagic, there's no problem there, everything works as it should on a 100% race length. ALL the cars stop twice in the given window.

From the md3 file .....


0 ; pitstop group 1 %
0 ; stop 1
0 ; pit window 1
0 ;
0 ;
0 ;
0 ;
0 ;
100 ; pitstop group 2 %
16 ; stop 1
4 ; pit window 1
32 ; stop 2
4 ; pit window 2
0 ;
0 ;
0 ;
0 ;
0 ; pitstop group 3 %
0 ; pit window 1
0 ; stop 2
0 ; pit window 2
0 ; stop 3
0 ; pit window 3
0 ;

It would make sense if you want 50% race length that you would half all the values

So...


0 ; pitstop group 1 %
0 ; stop 1
0 ; pit window 1
0 ;
0 ;
0 ;
0 ;
0 ;
100 ; pitstop group 2 %
8 ; stop 1
2 ; pit window 1
16 ; stop 2
2 ; pit window 2
0 ;
0 ;
0 ;
0 ;
0 ; pitstop group 3 %
0 ; pit window 1
0 ; stop 2
0 ; pit window 2
0 ; stop 3
0 ; pit window 3
0 ;

And set the race distance to 50% in game....but it doesn't work, some cars don't stop and some stop only once.

All these changes I am making are reflected instantaneously in the TSM Magic Data Tab..... I don't use, or save the Default.tmd so it remains empty, TSM is reading from the .dat.

Like I said, everything is working fine at 100%, problems arise when using anything less.

I remember seeing a CSM Mod with a "race distance" option in the menu and possibly a "pitstop strategy", but can't find it, and that's what I'm looking for...launch CSM, set race distance.....set number of stops.....play.
I don't know whether it's possible in CSM, there's so little information about setting up the menu's.

F1Dev

The race strategies in the Magic Data apply to 100% race distances.

I think the problem is you are expecting cars to still stop twice when you reduce the race length below 100%. Actually GP4 adjusts the strategies if you reduce the race length below 100%.

In your magic data every car will stop twice if the race length is 100%. If you reduce the race length, they don't need to stop as many times, so they'll maybe only stop once. If you reduce the race length enough (say <50%), they probably wont stop at all.

=====================================================


Intel NUC 8i3, 8GB RAM, MS Sidewinder Wheel

Yeah I figured that, I'll leave it at 100%, less hassle obviously there's no way to stop gp4 overriding things.

F1Dev

i agree turbo lover its the number of track sections to pit in line and also exit from pits, could be a long pit lane etc

Thanks for the elaborate experiment on magic-data values! I think it is very interesting, although I do have some remarks:

1) As far as I know GP4 always adds an error term to the race performance, so there may still be some "noise" in the data.
2) We now know that cc shuffler influences the (AI) tire wear, but it would be useful to see whether or not it influences the "fuel effect". In the experiment we know the laptimes when the car is at its heaviest (2nd lap) or when the tires are shot (55th lap). It would be interesting to know the laptimes when fuel is low and the tires are in good condition. This can be achieved by making a late pitstop (for example in lap 50) in order to estimate the effect of worn tires and the effect of the fuel load on laptimes.

From the data I understand two things:
1) The relation between cc shuffler and actual tire wear is nonlinear. It seems to increase rapidly (quadratically? exponentially?) with cc shuffler until cc shuffler values of about 3000.
2) There is probably a limit to tire wear. Laptimes cannot increase by more than about 6 seconds due to tire wear in this experiment. That's why the 55th-lap times do not deteriorate any further for cc shuffler values above 3000, and it explains why laptimes suddenly start to improve again at some point in the race.

Maybe the tire-wear limit is also defined by some (yet unidentified) parameter in the magic data. Can someone please confirm if cc shuffler affects the player car's laptimes? Then, what is the interpretation of the tire-wear value in the magic data? Is it just to finetune the player car's tire wear?