Evoweb Gameplay Lab, FIFA 20 (Frostbite FIFAs?)

Everything I've done in this script is basically close to the limit of my own ability with CE, I'm just comfortable with doing all this after some practice with learning my way around all the different menus and windows (basic searches, the memory viewer, autoassembler) so I'm pretty sure the official wiki will be enough. Maybe I can explain something in a more detailed way, perhaps with step by step instructions, as I create a new script to add a new file/parameter?
Please ???!!!
 
Please ???!!!

It's really easy, I'll try to use only 2 screenshots, lol

I'll test the supportSpeedModifier next from the gp_positioning_supportspeed file, because well, it sounds like AI teammates supporting you. Preferably in defence. Or it could be something about them offering a pass option, who knows if we don't try!

1. Start with a simple string search for the filename (+ full path, I copy the base path from a previous entry) and we should find a single result, in this case in address 711EB5B0.

2. Right click to select "browse memory" to open the memory viewer. This will be the base address but it will change every time we run the game, so instead of adding it to the table, we'll add the script at this point from the Tools -> Autoassemble menu option. Just copy a script from a previous <script> entry, and just change the variables. Select & copy the series of bytes starting with "46 69 ..." and paste them in the first line, replacing the previous entry. And just rename the other variables from the previous script (so AOB4 becomes AOB5), and "gp_positioning_supportspeed" will be the new variable that will hold the base address and we'll use it later.

3. Don't click on execute, choose File -> Assign to current cheat table, and it will be added to the bottom of the list as a new entry and you can activate it from there. That was half the work, adding a new file/script.

Capture00.GIF

Adding the values!
4. Still in the Memory Viewer window right click and select display type -> Float
5. Right click again and select "show relative addresses". Why? Because the filename will become the base address and everything else will be numbered relative to that. In short, I will not have to calculate the offsets for the values in my head or with a calculator!

6. Scroll back a bit and I find the value I want "1982.20". How do I know it's the one I want? Because I cheated before starting and entered this value in Frosty before launching the game. The default value was "1", how am I supposed to know which "1" exactly? 😆
(If it's still hard to spot your values, you can even try a search at this point by limiting your memory scan options close to the filename location).

7. So right click and select "add this address to the list", enter the name of the variable in the description field and select type "float", but delete the address and paste in our gp_positioning_supportspeed variable from before! Appending "-360" at the end, that's our correct offset! (gp_positioning_supportspeed contains the base address where the filename is stored, and by the way I've also gone ahead and added that as the second entry in the cheat table as you can see).

Capture01.GIF

Just name the new entries anyway you like, drag and drop them so they automatically become "children" entries to this new "parent" script, and you can even right click on the script entry and select "group config" -> "manual/expand collapse", so you can hide/display them with the mouse.
 
Last edited:
Great tutorial, I managed to do it at my first attempt!


I just struggled a bit at the part 7 when trying to find the correct offset (I mean the distance from the reference address), the one I was looking for was at the line -48 and in the third column 7C. It took me some tome to realize the position was -3C.
To be fair, starting with your CT file makes the thing much much easier.
What is quite cool is that variables from a same file are close from each other so it doesn't take too long to add them as long as their float value are unique.

About the video above, it is quite scary to see that just changing the radius of the ball (ok quite dramatically) has such an effect on the ball phyisics.
 
Last edited:
Also, if anyone is tempted to install Cheat Engine for the first time, make sure to turn off your internet connection before starting the installation process and all along the installation process otherwise you will have good chances to install adware, malaware on your PC!

Note that an up to date version is not required.
 
Last edited:
@manmachine It seems like some path are there more than 1 time (2 times at least). With the file I shared above the script always take the first adress which isn't the correct one. I didn't notice it the first time I launched the search.
I searched for: Fifa/Attribulator/Gameplay/groups/gp_physics/gp_physics_soccerball_runtime

I am almost certain the first time I ran the search in CE I had only one result :THINK:
 
Last edited:
@manmachine It seems like some path are there more than 1 time (2 times at least). With the file I shared above the script always take the first adress which isn't the correct one. I didn't notice it the first time I launched the search.
I searched for: Fifa/Attribulator/Gameplay/groups/gp_physics/gp_physics_soccerball_runtime

I am almost certain the first time I ran the search in CE I had only one result :THINK:

These things can happen with this aobscan method. That's why I wanted to test it more yesterday.
There are 3 solutions that i can think of. The first one is me coming up with a completely different way/script of doing it, but that may take days so let's move on to the other 2:

1. Change a single line and use the aobScanRegion function instead.
See: https://wiki.cheatengine.org/index.php?title=Auto_Assembler:aobScanRegion

Code:
[ENABLE]
//code from here to '[DISABLE]' will be used to enable the cheat
//aobscan(AOB1,46 69 66 61 2F 41 74 74 72 69 62 75 6C 61 74 6F 72 2F 47 61 6D 65 70 6C 61 79 2F 67 72 6F 75 70 73 2F 67 70 5F 70 68 79 73 69 63 73 2F 67 70 5F 70 68 79 73 69 63 73 5F 73 6F 63 63 65 72 62 61 6C 6C 5F 72 75 6E 74 69 6D 65)
aobscanRegion(AOB1, 60000000, FFFFFFFF, 46 69 66 61 2F 41 74 74 72 69 62 75 6C 61 74 6F 72 2F 47 61 6D 65 70 6C 61 79 2F 67 72 6F 75 70 73 2F 67 70 5F 70 68 79 73 69 63 73 2F 67 70 5F 70 68 79 73 69 63 73 5F 73 6F 63 63 65 72 62 61 6C 6C 5F 72 75 6E 74 69 6D 65)

I just commented out the aobscan line. With aobscanRegion you can define a start and end address for your search excluding any other results in other parts of the memory. Adjust the starting and ending addresses (60000000 - FFFFFFFF) based on where you notice these files are usually loaded on your pc. It's easy but it reduces the chances of this working on other people's pcs so only do it for this script (ball physics) if the other ones are working correctly.

2. Go to the memory viewer at the correct address where the filename is kept and grab more bytes for your search string. Maybe add the line before the filename to your search or the one after, or both. Until you are getting a single unique result back. Can be more tricky.

Capture00.GIF

- I've added the previous line which gives me a single unique result when searching the memory but it creates a couple of complications. What if those values in the previous line change? I replace these with question marks "??" (wildcard that says there should be a value at this position, but we don't care about the value, only about the pattern).

- The new base address will no longer be at the letter "F" from "Fifa", so our offsets will no longer work. I will just add "18" to the variable holding the base address. That's the number of bytes we've added to our search string. The script now looks like this:

Code:
[ENABLE]
//code from here to '[DISABLE]' will be used to enable the cheat
aobscan(AOB1,?? ?? ?? ?? 00 00 00 00 ?? ?? ?? ?? 00 00 00 00 00 00 00 00 00 00 00 00 46 69 66 61 2F 41 74 74 72 69 62 75 6C 61 74 6F 72 2F 47 61 6D 65 70 6C 61 79 2F 67 72 6F 75 70 73 2F 67 70 5F 70 68 79 73 69 63 73 2F 67 70 5F 70 68 79 73 69 63 73 5F 73 6F 63 63 65 72 62 61 6C 6C 5F 72 75 6E 74 69 6D 65)

define(gp_physics_soccerball, AOB1+18)
registersymbol(gp_physics_soccerball)

(...no other changes)
 
Last edited:
Thanks @manmachine ! I ve tried to reproduce what was making the search of the path returning 1 or 2 adsresses but I am getting no clear pattern. Also sometime the wrong address get depopulated and sometime not.

I will surely go with the 2nd solution (the third one) as it makes the script sharable with others. Something I don't get is why +18? When I count it, I see 24 pairs added before our tartget. That's because of the -18 at the start of the line?
 
Last edited:
What do you guys think is the worst matchup in this game? That is, a combination of teams / tactics / difficulty level / settings that make this game feel terrible to play? I know that you can have a decent game of football if you pick 2 low tier teams. But i'd like to test a worst case scenario when tweaking things.

In the beginning, after every patch I'd test the gameplay, playing against Man City on legendary for example. Their high press was terrible, the midfield was non existent, the player ratings too high, it was just non stop running up and down the wings. After a few minutes I could be certain and say "yeah this is still crap, Iet's check again after the next patch". But if you can think of something just as bad or even worse, shoot!
 
Last edited:
What do you guys think is the worst matchup in this game? That is, a combination of teams / tactics / difficulty level / settings that make this game feel terrible to play? I know that you can have a decent game of football if you pick 2 low tier teams. But i'd like to test a worst case scenario when tweaking things.

In the beginning, after every patch I'd test the gameplay, playing against Man City on legendary for example. Their high press was terrible, the midfield was non existent, the player ratings too high, it was just non stop running up and down the wings. After a few minutes I could be certain and say "yeah this is still crap, Iet's check again after the next patch". But if you can think of something just as bad or even worse, shoot!

I didn't play this game enought to give you a precise feddback, but I would say that the teams that have 3 attacking players (ST+2SW or ST+2SF, ect) are extremely exposed when they have to defend. It is like in PES now, they won't go back defending quickly enought/ at all. It means this type of teams are defending with 7 players which isn't enought. Bayer Leverkusen is a good exemple of that.
 
Last edited:
I didn't play this game enought to give you a precise feddback, but I would say that the teams that have 3 attacking players (ST+2SW or ST+2SF, ect) are extremely exposed when they have to defend. It is like in PES now, they won't go back defending quickly enought/ at all. It means this type of teams are defending with 7 players which isn't enought. Bayer Leverkusen is a good exemple of that.

Even the midfielders can be a problem + the tactics option for "number of players to get in the box". Fifa is now about passing between your cdms on the edge of the box for 30 minutes game time until something happens, and when what happens is a change of possession it's the other team running like mad against your backline with no midfielders to delay/stop them. No idea yet if such tactical options can be somewhat corrected in the gameplay files!
 
@manmachine the solution 2 fixed my problem, but now I am running in another issue.
Intrestingly/sadly if I launch the game with Frosty editror with an unedited project, the script can find the AOB and the correct offset, BUT If I launch the game with Frosty and using an edited project with the scocerball inertia set to 0.666999 instead of the default 0.666 the AOB can't be find. Also during my testing yestrday with the shorter AOB I noticed that the offeset where correct when lauching the gme with frosty and the project I used to make the script BUT where all mesed up when I loaded frosty with a default project.

I guess my 0.666999 is longer than 0.666 and makes the thing move around in an unwanted manner.
Is there any rule of thumb about how one can edit the values to avoid this problem?
 
@manmachine the solution 2 fixed my problem, but now I am running in another issue.
Intrestingly/sadly if I launch the game with Frosty editror with an unedited project, the script can find the AOB and the correct offset, BUT If I launch the game with Frosty and using an edited project with the scocerball inertia set to 0.666999 instead of the default 0.666 the AOB can't be find. Also during my testing yestrday with the shorter AOB I noticed that the offeset where correct when lauching the gme with frosty and the project I used to make the script BUT where all mesed up when I loaded frosty with a default project.

I guess my 0.666999 is longer than 0.666 and makes the thing move around in an unwanted manner.
Is there any rule of thumb about how one can edit the values to avoid this problem?

I think i've seen similar errors with the offsets and I correct them as I see them. Having the default game value in parenthesis helps me as I quickly see if something seems wrong when I activate the scripts. That's my guess as well, maybe changing a value from 1 to 5555 so that I can find it in memory means that it now needs an extra byte of storage or something and things can swift around a bit when I go back to the initial value. So as long as we make "sane" changes to the values it should be ok. Something to watch out for.

I added a file not long ago and when I reverted to the original values in frosty the values had swifted in memory by exactly 4 bytes, and I had to add +4 to all the offsets! (all values are still in the same order so it's not hard to correct them, phew). So I guess my lesson is that I need to enter a value that is unique (in that particular file I want to add at least) but not something wild like 999 billion :)
 
Last edited:
@papinho81 Happened to me again in a new file I added. Everything shifted by 4 bytes when I reverted to the default game values (3.5 is the correct default value for all vars). Their order in memory is the same, so I just quickly paste +4 to all the addresses and it should be stable from now on. I hope!

Capture00.GIF
 
Last edited:
@papinho81 Happened to me again in a new file I added. Everything swifted by 4 bytes when I reverted to the default game values (3.5 is the correct default value for all vars). Their order in memory is the same, so I just quickly paste +4 to all the addresses and it should be stable from now on. I hope!

View attachment 44328

Could a rule of thumb be that when trying to make a value unique in frosty, the new value should have the same bit length than the default one? So every thing stay at the same place.
 
Could a rule of thumb be that when trying to make a value unique in frosty, the new value should have the same bit length than the default one? So every thing stay at the same place.

Wish I knew, I suppose we'll find out. I've added files that work just fine since the moment I added them without this issue. I just don't remember what values I used or maybe it was files with a single or few unique values already so i didn't have to change anything.
 
You know what, the values from the base file you shared are always correct no matter what project Iam using with frosty. I didn't edit those particular files in frosty though.
 
You know what, the values from the base file you shared are always correct no matter what project Iam using with frosty. I didn't edit those particular files in frosty though.

New theory. It maybe depends on the file. I just imported a new one with 13 variables, I reverted the file in frosty, launched the game again and all 13 values and offsets are still correct. That was a relief because it's getting late. I'm thinking fifa reads the files in two different ways, as normal if a file is not modded but via a different path when it's modded and maybe this can happen with some files but not all.

@papinho81 Edit: Yep, found it I think. It's a frosty issue, it doesn't have anything to do with the values we're using. I changed a single value from "3.5" to "3.6" in the file that gave me trouble earlier and frosty re-introduced an additional 4 bytes in memory, somewhere. So it can happen with *some* files IF they're loaded via frosty (your changes don't matter).

(I suppose it's not fair to say it's a frosty issue, it's an issue with how the game reads the same file from two different locations whether it's modded with frosty or not. For some files this introduces a 4-byte discrepancy, for these files we can simply decide that we're going to do our testing in CE only and not change them in frosty again (or just don't launch the game from frosty) so the offsets should be stable).
 
Last edited:
New theory. It maybe depends on the file. I just imported a new one with 13 variables, I reverted the file on frosty, launched the game again and all 13 values and offsets are still correct. That was a relief because it's getting late. I'm thinking fifa reads the files in two different ways, as normal if a file is not modded but via a different path when it's modded and maybe this can happen with some files but not all.

Edit: Yep, found it I think. It's a frosty issue, it doesn't have anything to do with the values we're using. I changed a single value from "3.5" to "3.6" in the file that gave me trouble earlier and frosty re-introduced an additional 4 bytes in memory, somewhere. So it can happen with some files IF they're loaded via frosty (your changes don't matter), while it doesn't happen with other files at all.

The thing is even if I start the game through origin, sometimes I get one sometimes two results for the path. Yesterday I even restarted my PC thinking they were something stored in the memory, but I also got the two results starting from origin.



EDIT: Your edit part is 100% correct. I just tried to launch the game through origin and the bits before the path aren't the same than with frosty, which make the script not working. Also all the offest have moved by 10 bytes.

That's gonna be tricky to make scripts for some files with reptitive values...
 
Last edited:
The thing is even if I start the game through origin, sometimes I get one sometimes two results for the path. Yesterday I even restarted my PC thinking they were something stored in the memory, but I also got the two results starting from origin.



EDIT: Your edit part is 100% correct. I just tried to launch the game through origin and the bits before the path aren't the same than with frosty, which make the script not working. Also all the offest have moved by 10 bytes.

That's gonna be tricky to make scripts for some files with reptitive values...

Maybe I can account for both cases in the script. Which file is changing by 10 bytes? I've only encountered 4-byte discrepancies so far.
 
Maybe I can account for both cases in the script. Which file is changing by 10 bytes? I've only encountered 4-byte discrepancies so far.
The soccerball one. I had to change my offsets from 3C to 2C for example. Is that 10 bytes?
If the way frosty alter the file is common between users, that could be great!
 
The soccerball one. I had to change my offsets from 3C to 2C for example. Is that 10 bytes?
If the way frosty alter the file is common between users, that could be great!

Wow, I can see the difference when the file is loaded from the default location VS frosty. In this case the aobscan also fails in one case because we're including more bytes for our signature. I hate this file now. The good news is that I made scripts for more files and they work just fine no matter where they are loaded from. But I'll try to think of a easy solution for the ones that exhibit this problem, even if it's a quick hack with a drop down menu entry where you manually select a +/-10 offset. I'm sure it can also be done with script code but I'm also learning as I go with CE.
 
Last edited:
Wow, I can see the difference when the file is loaded from the default location VS frosty. In this case the aobscan also fails in one case because we're including more bytes for our signature. I hate this file now. The good news is that I made scripts for more files and they work just fine no matter where they are loaded from. But I'll try to think of a easy solution for the ones that exhibit this problem, even if it's a quick hack with a drop down menu entry where you manually select a +/-10 offset. I'm sure it can also be done with script code but I'm also learning as I go with CE.

10 bytes in hex so 16 in decimal?
So I did it correctly on my first attempt! I just chose the worst possible file to do it!

So you are getting the same offsets using frosty with that particular file. So they seem consistency between users.

I was thinking about helping you making those scripts, but may be it is better if you do it on your own for consistency sake. What do you think?

Edit: I am in So mode :)
 
Last edited:
10 bytes in hex so 16 in decimal?
So I did it correctly on my first attempt! I just chose the worst possible file to do it!

So you are getting the same offsets using frosty with that particular file. So they seem consistency between users.

I was thinking about helping you making those scripts, but may be it is better if you do it on your own for consistency sake. What do you think?

Edit: I am in So mode :)

I can see 12 extra "00" bytes when the file is not loaded from frosty, then there's a float that takes up another 4 bytes in memory, so I suppose that's 16 bytes. The offsets are in hex so -/+ 10 in hex = 16 bytes. May I suggest switching to using the "aobscanRegion" function (a few posts above), instead of using more bytes for the signature, as a temporary solution? At least this will make sure the aobscan works correctly, on our pcs. This is the worst case/file I suppose because we were finding the filename twice in memory. Then it's just about finding the most convenient way to quickly add/subtract 10 from the offsets.
 
I can see 12 extra "00" bytes when the file is not loaded from frosty, then there's a float that takes up another 4 bytes in memory, so I suppose that's 16 bytes. The offsets are in hex so -/+ 10 in hex = 16 bytes. May I suggest switching to using the "aobscanRegion" function (a few posts above), instead of using more bytes for the signature, as a temporary solution? At least this will make sure the aobscan works correctly, on our pcs. This is the worst case/file I suppose because we were finding the filename twice in memory. Then it's just about finding the most convenient way to quickly add/subtract 10 from the offsets.

We are a bit derailling the thread from its original purpose, but the potential of this tool is so great to fasten the discovery process that it worth it.

Just a suggestion here. The second result is always the correct one, could we write a script that when there is two results for the signature the second one should be kept but if only one goes with the first one.
I ve red that the aobscan from the dissambler always setle on the first result but other functions such as AOBScan allows accessing any results (https://www.cheatengine.org/forum/viewtopic.php?p=5585381&sid=6e8101d6d87ec4fd029bca6c72f7d043).

I am not familiar with this coding language but it doesn't look too complicate. I could try to come with something of that falvour. Also for the offset we could also use the if conditon. If (haha..) I am correct, without frosty there is always non 00 bytes just before the signature while frosty adds 4 x 00 before the signature.
 
Just to come back to this quickly:

The single value change is the following:

- gp_actor_movement_runtime
- ATTR_WalkSpeed:
Default value=0.1, mod value=0.18
I've just turned this mod off for a game, and it's a hell of a difference. I have much more freedom without it - because the defenders just can't keep up with any attacker, the balance is totally off.

With your mod value (0.18), I had to turn the in-game marking slider down to 45 in order to be able to breathe (otherwise, pressure was CONSTANT no matter the opponent or their style), and even then it was a little too much to be realistic.

I've turned it down to 0.15 and suddenly I had to turn marking up to 50 in order to be pressed - but it feels like a good balance. Possibly needs to go up a little more - Bayern just went 4-0 up against me at half-time (I'm Köln) and it feels a little too difficult to defend again... I'll try 0.16 later!

ALSO... Do you play with any modded values to slow the ball down (or AI passing)? I've modded this myself but I've gone too far with it (too slow compared to reality) - I find it really difficult to get the balance right. Passing play is fast in modern football, but just not permanently fast like it is in FIFA (especially in non-attacking scenarios)...
 
Just to come back to this quickly:


I've just turned this mod off for a game, and it's a hell of a difference. I have much more freedom without it - because the defenders just can't keep up with any attacker, the balance is totally off.

With your mod value (0.18), I had to turn the in-game marking slider down to 45 in order to be able to breathe (otherwise, pressure was CONSTANT no matter the opponent or their style), and even then it was a little too much to be realistic.

I've turned it down to 0.15 and suddenly I had to turn marking up to 50 in order to be pressed - but it feels like a good balance. Possibly needs to go up a little more - Bayern just went 4-0 up against me at half-time (I'm Köln) and it feels a little too difficult to defend again... I'll try 0.16 later!

I ve been losing almost all my game while usig it and on default sliders on WC difficulty. I only managed to score on PKs. 0.18 is may be too much as you say :) . But it is good to know we can make this game more defense oriented than it is by default.
 
ALSO... Do you play with any modded values to slow the ball down (or AI passing)? I've modded this myself but I've gone too far with it (too slow compared to reality) - I find it really difficult to get the balance right. Passing play is fast in modern football, but just not permanently fast like it is in FIFA (especially in non-attacking scenarios)...

I haven't tried it yet myself. I personnaly find the pass to be ok in term of speed, when driven passes are put appart. What I don't like is the pace at which the cpu can string passes together. More particularly when it happens close to my box.
Also, I find ground passes lack a bit of zip in general and they decelerate too quickly to my taste. I would like to see the ball rolling a bit longer than it does by default.

What did you change to edit your pass speed?
 
Last edited:
What did you change to edit your pass speed?
All I've done is play around with the values you mention at the start of this thread - increase weight a little bit, but MOST IMPORTANTLY increase field friction (and ball friction) to slow everything down. Which leads to wonderful midfield play IMO, but then when you're attacking you can't get the ball moving quickly enough. The range of pass speed is so small, it's all very similar.
 
What I am finding is that the values are so impactful. Hope these are 32 bit doubles values instead of 16 bits floats to get the balance I want.
 
Back
Top Bottom