Magic Data Discussion

Posted by TomMK 
Re: Magic Data Discussion
Date: January 09, 2019 10:31AM
Posted by: TomMK
Quote
landex
Does the bumps do any significant effect? I try all from 0 to 3, the car vibration feels all same.

Try experimenting with the bump factor and bump shift values (desc138/139), use some extreme values and see what effects you feel.

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


Intel NUC 8i3, 8GB RAM, MS Sidewinder Wheel
Re: Magic Data Discussion
Date: January 09, 2019 10:52AM
Posted by: SDI
The desc75 value has nothing to do with hotseat. It is a real-time factor, but uses desc74 in the formula. The desc74 value is a lap time indication, that happens to be used for hotseat duration, amongst other things. The real-time factor means that it speeds up or slows down the time. So if you would time your lap with an actual stopwatch, you'll get a different lap time than the in-game lap time. For example, if you make desc75 equal to desc74, the factor is 0.5 and the in-game lap time should be half of the real lap time (e.g. 40s in-game, 1m 20s on your stopwatch).

@RHill: the CC aggressiveness min/max is the same as braking range min/max. See GPxSet documentation for the description. Here's a quick formula that should make it more clear:

braking point range = [normal - X * max, normal - X * min]

where normal is the normal braking point (let's say distance from the apex, e.g. at 100m sign). The min and max have some conversion factor X, which I haven't figured out.

René Smit, Independent Software Developer.
Download my GPx tools here.
Re: Magic Data Discussion
Date: January 09, 2019 12:36PM
Posted by: Noog
Apologies for another long post. Hope it's worthwhile...

@ TomMK

That's useful Tom, thanks. That'll be making it's way into my cmagic4.ini file shortly. One thing that I THINK might be outdated though is desc51 and desc52. René's Braking Range Minimum and Braking Range Maximum seems (from my limited testing) to give more insight into what's going on. I'd be interested in your experiences with these values so far because you seem more disciplined in your testing than I. My observations so far are explained below.

@RHill

According to my few tests a BrakingRangeMin (desc51 aka CC aggressiveness) value of -10000 will make a car brake earlier into corners, but other cars will eventually run into it and push it off. The effect of a value of -500 or -1000 is barely noticeable but more realistic. I assign the value only to one or two back markers.

A higher BrakingRangeMax (desc52) value will make a car brake later into corners. In my tests I found that a value of up to 3000 works seems to work quite well, often leading to better CC lap times, whereas, say, 10000 seemed to lead to more offs. I've been assigning one or two drivers a value of about 2500 and another pair a value of about 1000, At that level the effect is subtle (but I'm sure it's there) and it seems to add to the game slightly in that you find the modded cars will sometimes corner faster than expected leading to some interesting overtaking-on-the-outside behaviour that you wouldn't see otherwise. I use this for one or two real-world drivers that I deem to be quick but a bit reckless!

The thing to remember though is that many circuits already have a desc51 value that's near the maximum (65536), so since I've been experimenting with this I've started to reduce the defaults in all tracks to 62526 to leave room for the increased BRMax value. It's time consuming because it can have knock on effects with things like CC grip etc, but according to my tests so far, it's probably worth it once it's done. (It's all very subjective though, so I could be wrong!).

The original request that gave rise to all this was to enhance the degree to which individual drivers could be assigned a more or less aggressive driving style. As I said, it is a bit of work to set it all up, but it seems to work quite well, ie a car with a BRMax enhanced by 2500 will often do better than expected for part (or even all of the race), but he'll just as often blow his gains by overdoing it at some point. For me, BRMin is less useful and more hidden but probably has some value too.

It's early days, but used sparingly BRMax can definitely bring a touch more excitement into a race and used in conjunction with the latest wizardry from René (Error Chance) I believe GP4 may well have been taken to a new level.

I did a couple of short races yesterday using BRMax for a couple of drivers and revised EC values for two others and one of the races in particular was definitely one of the most exciting I've ever participated in - and in both races I could see the tailored 'personalities' of the CC drivers shining through without anything seeming too forced, ie unrealistic.

For what it's worth, I'm working on a set of spreadsheets which will make the creation of performance files and certain sections of the magic data files much easier, based directly on the data from all the real-world F1 races and qualifying sessions ever driven but in a flexible way that allows the user to influence the behaviour and style of particular drivers to reflect certain subjective parameters. The project was getting quite refined at one point but things have moved on so fast recently I have no choice but to go back to square one to incorporate all the new options. Hopefully it'll be much better for it. Don't hold your breath though as it'll be a while.

A final thought - with all these advances, ie the amazing tracks that just seem to get better and better, René's outstanding developments and all the fantastic mods, aren't we squarely into GP5 territory by now? Certainly it's undeniable that today's GP4 is streets ahead of the out of the box GP4 experience isn't it? Copyright issues notwithstanding I'd like to see someone put together a default installation of GP4 (GP4.5?), which could be used as the basis for all mods; bringing together all the advances and ultimately taking the game back to more of a plug and play experience for the average user. I know that's what several of the mod creators aim to do already but inevitably this results in inconsistencies between mods which detract from that goal.

I feel like I've been studying the game constantly for over two years now and while I've really enjoyed learning how to create the ideal environment for a given year I'm increasingly conscious that it's just way too time-consuming for most people and I think it would be good if we could find a way to simplify things for the non-fanatic! I sense you might feel that way too TomMk.
Re: Magic Data Discussion
Date: January 09, 2019 03:33PM
Posted by: SDI
@Noog: note that desc51/desc52 and BRMin/BRMax work like a range, like the VAR values. The CC brakes more consistently if the range is small.

Also, these values are signed. You can directly use negative values in performance files, but in the magic data they are represented as unsigned values. Fortunately, an unsigned number can be converted 1 on 1 to a signed number. The range is 0 to 65535, so the maximum is not 65536 (this value will probably translate to 0 if used). A value of 65535 translates to -1. The formula is: x > 32767 ? x - 65536 : x. That means: if it is greater than 32767 subtract 65536. You can check it in your Windows Calculator, if you set it to programming mode. Check that it's in QWORD mode. Type 65535 and click twice on QWORD so it will say WORD. The number will change to -1. If you do the same with 32768, it will change to -32768. The calculator doesn't seem to be able to convert into the other direction. The formula would be: x < 0 ? x + 65536 : x. That means: if it is small than 0 add 65536. So values near 65535 are actually very small negative numbers, near the middle of the total range.

René Smit, Independent Software Developer.
Download my GPx tools here.
Re: Magic Data Discussion
Date: January 09, 2019 04:43PM
Posted by: Noog
Quote
SDI
@Noog: note that desc51/desc52 and BRMin/BRMax work like a range, like the VAR values. The CC brakes more consistently if the range is small.

Yes, thank you. That expresses it better and explains more clearly why the effect is only noticeable some of the time.

Quote
SDI
Also, these values are signed. You can directly use negative values in performance files, but in the magic data they are represented as unsigned values. Fortunately, an unsigned number can be converted 1 on 1 to a signed number. The range is 0 to 65535, so the maximum is not 65536 (this value will probably translate to 0 if used). A value of 65535 translates to -1. The formula is: x > 32767 ? x - 65536 : x. That means: if it is greater than 32767 subtract 65536. You can check it in your Windows Calculator, if you set it to programming mode. Check that it's in QWORD mode. Type 65535 and click twice on QWORD so it will say WORD. The number will change to -1. If you do the same with 32768, it will change to -32768. The calculator doesn't seem to be able to convert into the other direction. The formula would be: x < 0 ? x + 65536 : x. That means: if it is small than 0 add 65536. So values near 65535 are actually very small negative numbers, near the middle of the total range.

Again, yes, 65535. My mistake. As for the rest, I'm no programmer unfortunately, but it's starting to make more sense than it did before. Thanks again.
Re: Magic Data Discussion
Date: January 09, 2019 04:49PM
Posted by: PaZa8523
What about these values?
What's the range?

desc126=failure chance: suspension
desc127=failure chance: loosewheel
desc128=failure chance: puncture
desc129=failure chance: engine
desc130=failure chance: transmission
desc131=failure chance: oilleak/waterleak
desc132=failure chance: throttle/brake
desc133=failure chance: electrics

I try to modify values (desc128 with "10000" and leave others with "0";) in md3 file inside S1CTXX.DAT with GP Builder, but I don't see any changes in game.
Re: Magic Data Discussion
Date: January 09, 2019 04:58PM
Posted by: SDI
PaZa8523 Schreef:
-------------------------------------------------------
> What about these values?
> What's the range?
>
> desc126=failure chance: suspension
> desc127=failure chance: loosewheel
> desc128=failure chance: puncture
> desc129=failure chance: engine
> desc130=failure chance: transmission
> desc131=failure chance: oilleak/waterleak
> desc132=failure chance: throttle/brake
> desc133=failure chance: electrics
>
> I try to modify values (desc128 with "10000" and
> leave others with "0";) in md3 file inside
> S1CTXX.DAT with GP Builder, but I don't see any
> changes in game.


I've already explained that here and here.

René Smit, Independent Software Developer.
Download my GPx tools here.
Re: Magic Data Discussion
Date: January 09, 2019 05:05PM
Posted by: SDI
Noog Schreef:
-------------------------------------------------------
> Again, yes, 65535. My mistake. As for the rest,
> I'm no programmer unfortunately, but it's starting
> to make more sense than it did before. Thanks
> again.

Here are some examples:

32767 = 32767 (the maximum value)
0 = 0
-1 = 65535
-1000 = 64536
-10000 = 55536
-30000 = 35536
-32768 = 32768 (the minimum value)

René Smit, Independent Software Developer.
Download my GPx tools here.
Re: Magic Data Discussion
Date: January 09, 2019 05:18PM
Posted by: Noog
René. (*)
Re: Magic Data Discussion
Date: January 09, 2019 05:24PM
Posted by: PaZa8523
SDI Scritto:
-------------------------------------------------------
> PaZa8523 Schreef:
> --------------------------------------------------
> -----
> > What about these values?
> > What's the range?
> >
> > desc126=failure chance: suspension
> > desc127=failure chance: loosewheel
> > desc128=failure chance: puncture
> > desc129=failure chance: engine
> > desc130=failure chance: transmission
> > desc131=failure chance: oilleak/waterleak
> > desc132=failure chance: throttle/brake
> > desc133=failure chance: electrics
> >
> > I try to modify values (desc128 with "10000"
> and
> > leave others with "0";) in md3 file inside
> > S1CTXX.DAT with GP Builder, but I don't see any
> > changes in game.
>
>
> I've already explained that here and here.


Ok.. I report your description:

> desc126..desc133
As explained already, these failure type chances are relative to each other. The sum is always 100%. The game adds 630 to each value before adding them up. Maximum sum 131080.
If a car gets a failure at all, is determined per team (what you edit in the performance file), before it determines the failure type. , before the race. The lap and track location too.



So.. You mean..

from desc126 to desc133 = 131080 points in totally

example:

desc126=16385
desc127=16385
desc128=16385
desc129=16385
desc130=16385
desc131=16385
desc132=16385
desc133=16385

or this, if i want to get retirements for engine problems..

desc126=1
desc127=1
desc128=1
desc129=131073
desc130=1
desc131=1
desc132=1
desc133=1

..and the retirements % depends from the value setted in the performance file.
Right?
Re: Magic Data Discussion
Date: January 09, 2019 06:56PM
Posted by: landex
TomMK Wrote:
-------------------------------------------------------
> > Does the bumps do any significant effect? I try
> all from 0 to 3, the car vibration feels all
> same.
>
>
> Try experimenting with the bump factor and bump
> shift values (desc138/139), use some extreme
> values and see what effects you feel.


Yes, its much better. Thanks TomMK!
Re: Magic Data Discussion
Date: January 09, 2019 09:18PM
Posted by: SDI
@PaZa8523: You have to realize each value will be increased by 630. I suggest to use this:

desc126=0
desc127=0
desc128=0
desc129=125000
desc130=0
desc131=0
desc132=0
desc133=0

The other failures still have a small chance to occur because of the 630 being added, but it's minimized.

René Smit, Independent Software Developer.
Download my GPx tools here.
Re: Magic Data Discussion
Date: January 09, 2019 10:31PM
Posted by: TomMK
For Silverstone 2013 we should use the following: ;)

0          ; desc126= failure chance : suspension
0          ; desc127= failure chance : loose wheel
125000     ; desc128= failure chance : puncture
0          ; desc129= failure chance : engine
0          ; desc130= failure chance : transmission
0          ; desc131= failure chance : oil leak / water leak
0          ; desc132= failure chance : throttle / brake
0          ; desc133= failure chance : electrics

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


Intel NUC 8i3, 8GB RAM, MS Sidewinder Wheel
Re: Magic Data Discussion
Date: January 09, 2019 11:18PM
Posted by: RHill
SDI Wrote:
-------------------------------------------------------
> Noog Schreef:
> --------------------------------------------------
> -----
> > Again, yes, 65535. My mistake. As for the rest,
> > I'm no programmer unfortunately, but it's
> starting
> > to make more sense than it did before. Thanks
> > again.
>
> Here are some examples:
>
> 32767 = 32767 (the maximum value)
> 0 = 0
> -1 = 65535
> -1000 = 64536
> -10000 = 55536
> -30000 = 35536
> -32768 = 32768 (the minimum value)

@SDI based on what you’ve said about values 51 & 52 being a range and the above comment about the values - can you tell me what the smallest range would be. So basically the latest minimum braking and latest maximum braking?
Re: Magic Data Discussion
Date: January 10, 2019 12:47AM
Posted by: PaZa8523
SDI Scritto:
-------------------------------------------------------
> @PaZa8523: You have to realize each value will be
> increased by 630. I suggest to use this:
>
> desc126=0
> desc127=0
> desc128=0
> desc129=125000
> desc130=0
> desc131=0
> desc132=0
> desc133=0
>
> The other failures still have a small chance to
> occur because of the 630 being added, but it's
> minimized.


Yes, I had forget it eheh..
Thanks. :)
Re: Magic Data Discussion
Date: January 10, 2019 12:48AM
Posted by: PaZa8523
TomMK Scritto:
-------------------------------------------------------
> For Silverstone 2013 we should use the following:
> ;)
>
>
> 0 ; desc126= failure chance : suspension
> 0 ; desc127= failure chance : loose
> wheel
> 125000 ; desc128= failure chance : puncture
> 0 ; desc129= failure chance : engine
> 0 ; desc130= failure chance :
> transmission
> 0 ; desc131= failure chance : oil leak /
> water leak
> 0 ; desc132= failure chance : throttle /
> brake
> 0 ; desc133= failure chance :
> electrics
>


ahahah (Y)
Re: Magic Data Discussion
Date: January 10, 2019 06:15PM
Posted by: roma147
Is it possible for AI to suffer with dirty air in this game?
Re: Magic Data Discussion
Date: January 10, 2019 08:04PM
Posted by: SDI
@RHill: I guess 32767 for both.

René Smit, Independent Software Developer.
Download my GPx tools here.
Re: Magic Data Discussion
Date: January 11, 2019 12:25AM
Posted by: TomMK
Quote
Noog
bringing together all the advances and ultimately taking the game back to more of a plug and play experience for the average user. I know that's what several of the mod creators aim to do already but inevitably this results in inconsistencies between mods which detract from that goal.

I feel like I've been studying the game constantly for over two years now and while I've really enjoyed learning how to create the ideal environment for a given year I'm increasingly conscious that it's just way too time-consuming for most people and I think it would be good if we could find a way to simplify things for the non-fanatic! I sense you might feel that way too TomMK.

It is my reason for being!! But yes it gets time-consuming very quickly, given the number of variables in play. The GP4 Central mods aim to be that plug-and-play experience; it's been a work-in-progress for several years now!

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


Intel NUC 8i3, 8GB RAM, MS Sidewinder Wheel
Re: Magic Data Discussion
Date: January 11, 2019 12:32AM
Posted by: TomMK
Quote
SDI
The real-time factor means that it speeds up or slows down the time. So if you would time your lap with an actual stopwatch, you'll get a different lap time than the in-game lap time. For example, if you make desc75 equal to desc74, the factor is 0.5 and the in-game lap time should be half of the real lap time (e.g. 40s in-game, 1m 20s on your stopwatch).

But.... but.... why?!?!

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


Intel NUC 8i3, 8GB RAM, MS Sidewinder Wheel
Sorry, only registered users may post in this forum.

Click here to login

Maintainer: mortal, stephan | Design: stephan, Lo2k | Moderatoren: mortal, TomMK, Noog, stephan | Downloads: Lo2k | Supported by: Atlassian Experts Berlin | Forum Rules | Policy