GerardFM24 said: Interesting topic that I will keep following. Is there also such research about staff and staffroles, Like what are the most important roles and which attribute are the best. Expand EBFM has important findings about various staff. This video shows the impact of coach attributes, which I would surmise as somewhat impactful but probably a fair bit less important than you would think.
From memory he also found that you only need 1 physio to get the full benefit, and it doesn't matter if this 1 physio has '1' physiotherapy. Hopefully I'm recalling that correctly. I think the idea is that a physio's attributes only estimate length of injury better, they can't actually reduce injury rate/length aside from their presence as a staff member.
For newgen impact, staff are mostly irrelevant. The only effect is that HoYD will influence 1-2 players coming in each intake with their personality. This possibly extends to other 'youth coaches' who supposedly have half this effect.
IMO an aspect that is emerging as important is stuff to do with tactical & team selection, because these appear to significantly influence winning - even if it's just selecting between similar players you have in your squad. So tactical knowledge, judging player ability, motivating for whoever you set the relevant responsibility for. One thing this would mean in practice is getting an assistant manager who is a great manager, rather than great coach.
I've been disassembling the "fm.exe" application for FM 24, which means I've turned the machine code back in to something resembling C so that I can look at it. I'm doing this because I want to find where shortlists/search results are stored in RAM so I can read them in my scouting tool but I might have found something else.
There's a function beginning at memory address 0x0144b40180 (at least in my Windows, Steam copy of FM 24.4.2+2081827), which appears to be grouping together player attributes and scoring them. I'll share the approximated C code here (feel free to ask Chat GPT what it means) as well as what I think it's doing. If you do feed this in to an LLM to decipher, give it this file too. That will map the offset codes (e.g. 0x23d, Pace) to the player's actual attributes.
From what I can see, this code is reading player attributes in groups, multiplying them together and creating a score for each group. It then returns the highest scoring group and the group itself.
For example, starting on line 65 of the code snippet:
- The lines beginning sVar1 = (short)((uint)(*(char *) read a different attribute from the Player entity (Acceleration and Pace in this example (0x239 and 0x23d)). - The lines uVar8 = (sVar1 >> 1) - (sVar1 >> 0xf); divide the attribute by 2, rounding down. - The next two if conditions ensure the number is between 1-20 inclusive. - The final if condition sums uVar11 (which is Pace / 2) and uVar6 (which is Acceleration / 2) and then multiplies the value by 5. If that result is > uVar2 (which is the highest rating it has seen so far), then it sets that to be the highest rating (*param_2 = uVar2) and sets the return value of the function to be the category ID (9 in this case).
Now here's the exciting part: the attributes it groups together and how it scores them.
Now I'm not saying that the game uses the same aggregation/scaling in the match engine--the only place that I've found it make a difference is the coach report (see below; this is me hacking the return value from the function so it thinks groups 9, 8 and 3 are this player's best)--but it's worth bearing in mind. I'm going to keep this line of enquiry up and I'll report back anything I learn.
Expand Although what you discovered isn't exactly the golden ticket we are looking for, it's nonetheless a significant insight for me.
Perhaps it's something obvious to a programmer, but as someone who doesn't know programming and couldn't make heads or tails of the code before, finding out what the attributes are called in the code gives me a solid foothold to work with.
I spent a while trying to find attribute combos in the code using this info. I came across a few intriguing ones, such as Reflexes interacting with CommandOfArea for some reason, but no clear formula I'm looking for. Strangely 'versatility' seems to interact with certain other attributes, but maybe I'm just misinterpreting what the code is about. Even without the formula, these attribute associations are perhaps useful clues for forming hypotheses to test about attributes.
Another thing I noticed is that there are references to four-letter names such as 'TrDp' (made-up example), after translating it into plain english with AI. If anyone else has a go at it, I know from previously trying to find the newgen mechanics in the code that these four-letter names are the shorthand they use for the actual mechanic. So a real example of this for instance is you can change the fitness heart icon back to fitness % by changing the mechanic it reads from 'PcOI' to 'PCRF' in the skin. If you go through the other game files, you can find a bunch of these four letter names, even ones that are meant to be hidden mechanics.
So I think I already found an example of say TrDp = anticipation + work rate, where if TrDp was what you were interested in finding out the formula for, you'd have your answer.
I reckon that the attribute combinations, and other things like newgen mechanics, are lurking in there waiting to be found.
GeorgeFloydOverdosed said: Although what you discovered isn't exactly the golden ticket we are looking for, it's nonetheless a significant insight for me.
Perhaps it's something obvious to a programmer, but as someone who doesn't know programming and couldn't make heads or tails of the code before, finding out what the attributes are called in the code gives me a solid foothold to work with. Expand
I'm sorry to say that all the names in my post were given by me. There's nothing in the code I shared that names attributes or the groups they belong to (although you could infer them by reading the exact scout report detail they lead to).
The names in this post came straight from the qme_stat_relevant_attribute_data file in simatch.fmf though.
LightningFlik said: I'm sorry to say that all the names in my post were given by me. There's nothing in the code I shared that names attributes or the groups they belong to (although you could infer them by reading the exact scout report detail they lead to). Expand Hm.. isn't it the case though that 0x239 = acceleration?
Based on something my LLM said, it did occur to me that perhaps 0x239 just represents a generic offset (i.e. read ahead 0x239 amount starting at param1), but I saw interactions between attributes in lines of the code that made sense it was referring to specific attributes (i.e. I saw 0x244 (Aggression) with 0x240 (Dirtiness)).
I know your #defines list isn't the code itself, but you've nonetheless identified 0x239 effectively means acceleration, no?
Yes that's right. Everything in constants.h is right, that's from my app which scouts players in memory. I'm saying the names I gave to the attribute groups were made up by me.
Also I may have found the location in code where role/position suitability is calculated, but I can't get the code to fire in the course of the game, so testing it is proving difficult. It looks like that's what it's doing though.
LightningFlik said: Yes that's right. Everything in constants.h is right, that's from my app which scouts players in memory. I'm saying the names I gave to the attribute groups were made up by me.
Also I may have found the location in code where role/position suitability is calculated, but I can't get the code to fire in the course of the game, so testing it is proving difficult. It looks like that's what it's doing though. Expand So just to clarify, it is the case that 0x239 = acceleration, right?
What led you to 0x0144b40180 anyway? I've been looking through instances of 0x239 for example for something interesting, but maybe there's a better way of going about it
Would be interested in seeing the suspected role location
Correct. The game stores various objects in memory (Person, Player, Staff, Club, Team, Nation, Competition and so on) and 0x239 is the offset from the start of any given Player object where acceleration is stored. You can trust the offsets defined in my constants file.
I opened Cheat Engine, went to the memory address of a known player (which my scouting app told me) and added a "Tell me what read from this address" breakpoint on the player's acceleration. One of the instructions was the one I quoted in my code snippet here. I noticed the function actually hit a lot of offsets and learned it was combining and multiplying them in various ways.
This is something you led me to last night, with this comment:
GeorgeFloydOverdosed said: I spent a while trying to find attribute combos in the code using this info. I came across a few intriguing ones, such as Reflexes interacting with CommandOfArea for some reason, but no clear formula I'm looking for. Expand
I wondered what you were talking about so I searched the FM binary for "Command", "CommandOfArea" and "Command_of_Area".
"Command_Of_Area" is a hard-coded string at memory location 0x145c48e51 and it is used in only one location: 0x144380f6c. I can't copy and paste the whole thing but as soon as I saw it, I was intrigued.
It looks like it's taking a bunch of attribute names, feeding them in to a function and then getting a value back from them. Reading player attributes? Surely not, they're stored in a Player object in memory and accessed through offsets, not by string.
I looked at what called that function and got one hit: 0x14231dcd7.
It's a very boring looking function but then I noticed some strange looking memory addresses on lines 16, 33 and 50. I looked closer and realised they're not memory addresses, they're the words "posi", "attr" and "weig" represented as numbers (i.e. the character codes for each letter have been concatenated to make a 4 byte number). This intrigued me further.
I went back to the previous function (the one that read in attributes and did something with them) and noticed the bottom: the game reads in string references to player positions (e.g. DL, AMRL, SW) and it takes those plus the values read in above and feeds them in to another function.
Given all this, I'm convinced it is determining some sort of relationship between positions and attributes. Problem is, I can't find when the code is executed. I've put breakpoints all around it and they never fire. Is the code unreachable and unused? Does it fire when the game first loads, before I get a chance to attach Cheat Engine to it? (I can test this by launching the game with a debugger already attached, which I will do after work). Is it legacy code? (This wouldn't necessarily surprise me, I've found some legacy stuff already (around a mechanic called Match Boost in training modules that never seems to get used)).
Thank you for all these discoveries, small question that i have, do staff have any relevant role in player development, i tend to try and have the best staff there is, but with all you all discovered im not sure if it really matters or not. Assitant managers, scouts, phisios, all that, does it really matter? Thank you
That's not 10%. To get 10% he'd need to divide goals prevented by xG: 1 / (1 + 9). Not sure which one of these he actually wanted though. Still, it's interesting so far.
Gerrard said: Expand I came here today with the intention of making an assessment of this video lol
Very interesting findings
Flair is strongly negatively correlated with possession won for midfielders. Is this because of the attribute itself altering the role, or the high flair causing a low-possession-won role to be selected? And then, does more possession won lead to more or less wins?
I think overall this can actually be triangulated with the key attribute template and EF 424 IF HP V2 P101 AC tactic to determine what tactical measures are beneficial and which are detrimental, and then refine the key attributes - to per position specificity - based on that. Perhaps it might even clue us into how the tactic can be edged out too.
We see that flair and off-the-ball have good & bad results for different positions/measures. And he finds bravery & one-on-ones for GK were significant in relation to goals conceded. So I will do some testing to see.
There are some caveats to his conclusions I think most will miss. For instance, the GK goals conceded thing, isn't actually measuring team goals conceded, and finishing produces more goals on wingers, but that doesn't mean the team scores more goals as a whole (my own testing on finishing shows that it simply take off goals from ST and give it to the winger).
But there's a lot of valid and potentially fresh information in it.
How do you feel about the premise that different positions require different attributes? I know that flies in the face of your theory of a generalised make-up (last I checked, anyway). I thought for a while that the positional requirements of attributes was overblown because FM always punishes me for expecting too much of it.
Now I'm unsure, but I've had great success promoting Warrington up the leagues using your old, old weights.
I just can't find where that code above is executed. I've decided to search for "weig" in hopes that I can find somewhere else in the code where that logic is performed. In doing so, I've found the nuttiest string references in the binary. What the actual hell is in this game?
EDIT: one more. I actually googled the strings in this one and found a medical website with the exact same strings. I'd love to talk to one of the people who worked on this game and ask exactly what directory they've accidentally included in their build pipeline on this project.
Maggh said: Thank you for all these discoveries, small question that i have, do staff have any relevant role in player development, i tend to try and have the best staff there is, but with all you all discovered im not sure if it really matters or not. Assitant managers, scouts, phisios, all that, does it really matter? Thank you Expand I would surmise overall that most staff do matter moderately, both for growth and performance. It can also matter for players being willing to sign for your club.
People are going to have different impressions, but for me I'd say staff are about 70% as impactful as I'd intuitively think they should be.
LightningFlik said: How do you feel about the premise that different positions require different attributes? I know that flies in the face of your theory of a generalised make-up (last I checked, anyway). I thought for a while that the positional requirements of attributes was overblown because FM always punishes me for expecting too much of it.
Now I'm unsure, but I've had great success promoting Warrington up the leagues using your old, old weights. Expand Before I played around with tactics, I would have made this critique of his findings, citing my attribute brute force testing, but now I am more open to the idea again of there being positional differences.
My impression now is that what is going on is that the Knap tactic favors a certain set of attributes, and this would extend to all the very similar top tactics in general (different roles or even formations, but all high pressing/intensity).
So if you play a defensive tactic, maybe then positioning would matter. Thing is, all defensive tactics lose. So effectively positioning never matters.
So it can be true at the same time that (1) only certain attributes matter for winning games, and (2) different tactics need different attributes.
Now I have tried positional variation in my attribute tests with the Knap tactic, and found there isn't any I can see (this is after being convinced for the longest time that concentration mattered for defenders but not forwards), but it's possible I am mistaken on one or two, or perhaps I didn't try the right combo (i.e. maybe I tested flair alone on ST, but not flair alone on MC).
I'll be doing some tests today based on Mustermann's findings, so we'll see if there are in fact position differences that actually increase/decrease win rate.
LightningFlik said: I just can't find where that code above is executed. I've decided to search for "weig" in hopes that I can find somewhere else in the code where that logic is performed. In doing so, I've found the nuttiest string references in the binary. What the actual hell is in this game?
Expand That's funny
I wonder what they've included that brought that stuff into it. I noticed there was some chinese characters, that links to a chinese website in the code for free template resources and whatnot - must be that they used an asset from it.
How did you get it to display the phrases as single lines like that? Maybe its cause I didn't let it fully finish processing I guess.
GeorgeFloydOverdosed said: How did you get it to display the phrases as single lines like that? Maybe its cause I didn't let it fully finish processing I guess. Expand Maybe Analysis -> One Shot -> ASCII Strings?
I know I did that at the start. Then I use Window -> Defined Strings to search.
Normal result is ~5th-7th, so perhaps a hint of a benefit to crossing in there due to the 1st which is not unprecedented but quite rare. Not quite enough to conclude crossing has any benefit though. I think a few more samples with high consistency & technique would settle this one way or the other.
No revelations here. Again, perhaps a very marginal benefit outweighed by CA cost, similar to strength or vision.
I forgot to change Man City's media expectation to 20th, hence the high rate of sackings. Doesn't invalidate the results, just means some samples are semi-wasted (9th sacked means they wont end up first, but they could have ended up 4th say).
I am also doing this in FM24, not FM26, but I doubt that that is why he finds crossing matters and whatnot.
GerardFM24 said: Interesting topic that I will keep following.
Is there also such research about staff and staffroles,
Like what are the most important roles and which attribute are the best.
EBFM has important findings about various staff. This video shows the impact of coach attributes, which I would surmise as somewhat impactful but probably a fair bit less important than you would think.
From memory he also found that you only need 1 physio to get the full benefit, and it doesn't matter if this 1 physio has '1' physiotherapy. Hopefully I'm recalling that correctly. I think the idea is that a physio's attributes only estimate length of injury better, they can't actually reduce injury rate/length aside from their presence as a staff member.
For newgen impact, staff are mostly irrelevant. The only effect is that HoYD will influence 1-2 players coming in each intake with their personality. This possibly extends to other 'youth coaches' who supposedly have half this effect.
IMO an aspect that is emerging as important is stuff to do with tactical & team selection, because these appear to significantly influence winning - even if it's just selecting between similar players you have in your squad. So tactical knowledge, judging player ability, motivating for whoever you set the relevant responsibility for. One thing this would mean in practice is getting an assistant manager who is a great manager, rather than great coach.
LightningFlik said: I want to share something of potential interest.
I've been disassembling the "fm.exe" application for FM 24, which means I've turned the machine code back in to something resembling C so that I can look at it. I'm doing this because I want to find where shortlists/search results are stored in RAM so I can read them in my scouting tool but I might have found something else.
There's a function beginning at memory address 0x0144b40180 (at least in my Windows, Steam copy of FM 24.4.2+2081827), which appears to be grouping together player attributes and scoring them. I'll share the approximated C code here (feel free to ask Chat GPT what it means) as well as what I think it's doing. If you do feed this in to an LLM to decipher, give it this file too. That will map the offset codes (e.g. 0x23d, Pace) to the player's actual attributes.
From what I can see, this code is reading player attributes in groups, multiplying them together and creating a score for each group. It then returns the highest scoring group and the group itself.
For example, starting on line 65 of the code snippet:
Spoiler sVar1 = (short)((uint)(*(char *)(param_1 + 0x239) * 0x6667 + 0xccce) >> 0x10);
uVar8 = (sVar1 >> 1) - (sVar1 >> 0xf);
if ((short)uVar8 < 2) {
uVar8 = 1;
}
uVar6 = (uint)uVar8;
if (0x13 < uVar6) {
uVar6 = 0x14;
}
sVar1 = (short)((uint)(*(char *)(param_1 + 0x23d) * 0x6667 + 0xccce) >> 0x10);
uVar8 = (sVar1 >> 1) - (sVar1 >> 0xf);
if ((short)uVar8 < 2) {
uVar8 = 1;
}
uVar11 = 0x14;
if (uVar8 < 0x14) {
uVar11 = (uint)uVar8;
}
if ((int)(short)uVar2 < (int)((uVar11 + uVar6) * 5)) {
uVar2 = (short)(uVar11 + uVar6) * 5;
*param_2 = uVar2;
uVar3 = CONCAT71((int7)((ulonglong)uVar3 >> 8),9);
}
- The lines beginning sVar1 = (short)((uint)(*(char *) read a different attribute from the Player entity (Acceleration and Pace in this example (0x239 and 0x23d)).
- The lines uVar8 = (sVar1 >> 1) - (sVar1 >> 0xf); divide the attribute by 2, rounding down.
- The next two if conditions ensure the number is between 1-20 inclusive.
- The final if condition sums uVar11 (which is Pace / 2) and uVar6 (which is Acceleration / 2) and then multiplies the value by 5. If that result is > uVar2 (which is the highest rating it has seen so far), then it sets that to be the highest rating (*param_2 = uVar2) and sets the return value of the function to be the category ID (9 in this case).
Now here's the exciting part: the attributes it groups together and how it scores them.
Group 1: Set pieces
((Corners + Free Kicks + Penalties + Long Throws) * 10) / 4
Group 2: Attacking technique
(Crossing + Finishing + Long Shots + Passing + Technique) * 2
Group 3: Attacking intelligence
((Anticipation + Vision + Decisions + Positioning) * 10) / 4
(Yes, positioning.)
Group 4: Leadership
((Bravery + Work Rate + Teamwork) * 10) / 3
Group 5: Defensive intelligence
((Tackling + Marking + Concentration + Positioning) * 10) / 4
Group 6: Technical control
(Flair + Dribbling + First Touch + Composure + Balance) * 2
Group 7: Aerial Ability
(Heading + Jumping Reach) * 5
Group 8: Physique
((Strength + Natural Fitness + Stamina + Agility) * 10) / 4
Group 9: Speed
(Acceleration + Pace) * 5
Now I'm not saying that the game uses the same aggregation/scaling in the match engine--the only place that I've found it make a difference is the coach report (see below; this is me hacking the return value from the function so it thinks groups 9, 8 and 3 are this player's best)--but it's worth bearing in mind. I'm going to keep this line of enquiry up and I'll report back anything I learn.
Although what you discovered isn't exactly the golden ticket we are looking for, it's nonetheless a significant insight for me.
Perhaps it's something obvious to a programmer, but as someone who doesn't know programming and couldn't make heads or tails of the code before, finding out what the attributes are called in the code gives me a solid foothold to work with.
I spent a while trying to find attribute combos in the code using this info. I came across a few intriguing ones, such as Reflexes interacting with CommandOfArea for some reason, but no clear formula I'm looking for. Strangely 'versatility' seems to interact with certain other attributes, but maybe I'm just misinterpreting what the code is about. Even without the formula, these attribute associations are perhaps useful clues for forming hypotheses to test about attributes.
Another thing I noticed is that there are references to four-letter names such as 'TrDp' (made-up example), after translating it into plain english with AI. If anyone else has a go at it, I know from previously trying to find the newgen mechanics in the code that these four-letter names are the shorthand they use for the actual mechanic. So a real example of this for instance is you can change the fitness heart icon back to fitness % by changing the mechanic it reads from 'PcOI' to 'PCRF' in the skin. If you go through the other game files, you can find a bunch of these four letter names, even ones that are meant to be hidden mechanics.
So I think I already found an example of say TrDp = anticipation + work rate, where if TrDp was what you were interested in finding out the formula for, you'd have your answer.
I reckon that the attribute combinations, and other things like newgen mechanics, are lurking in there waiting to be found.
GeorgeFloydOverdosed said: Although what you discovered isn't exactly the golden ticket we are looking for, it's nonetheless a significant insight for me.
Perhaps it's something obvious to a programmer, but as someone who doesn't know programming and couldn't make heads or tails of the code before, finding out what the attributes are called in the code gives me a solid foothold to work with.
I'm sorry to say that all the names in my post were given by me. There's nothing in the code I shared that names attributes or the groups they belong to (although you could infer them by reading the exact scout report detail they lead to).
The names in this post came straight from the qme_stat_relevant_attribute_data file in simatch.fmf though.
LightningFlik said: I'm sorry to say that all the names in my post were given by me. There's nothing in the code I shared that names attributes or the groups they belong to (although you could infer them by reading the exact scout report detail they lead to).
Hm.. isn't it the case though that 0x239 = acceleration?
Based on something my LLM said, it did occur to me that perhaps 0x239 just represents a generic offset (i.e. read ahead 0x239 amount starting at param1), but I saw interactions between attributes in lines of the code that made sense it was referring to specific attributes (i.e. I saw 0x244 (Aggression) with 0x240 (Dirtiness)).
I know your #defines list isn't the code itself, but you've nonetheless identified 0x239 effectively means acceleration, no?
Yes that's right. Everything in constants.h is right, that's from my app which scouts players in memory. I'm saying the names I gave to the attribute groups were made up by me.
Also I may have found the location in code where role/position suitability is calculated, but I can't get the code to fire in the course of the game, so testing it is proving difficult. It looks like that's what it's doing though.
LightningFlik said: Yes that's right. Everything in constants.h is right, that's from my app which scouts players in memory. I'm saying the names I gave to the attribute groups were made up by me.
Also I may have found the location in code where role/position suitability is calculated, but I can't get the code to fire in the course of the game, so testing it is proving difficult. It looks like that's what it's doing though.
So just to clarify, it is the case that 0x239 = acceleration, right?
What led you to 0x0144b40180 anyway?
I've been looking through instances of 0x239 for example for something interesting, but maybe there's a better way of going about it
Would be interested in seeing the suspected role location
GeorgeFloydOverdosed said: So just to clarify, it is the case that 0x239 = acceleration, right?
Correct. The game stores various objects in memory (Person, Player, Staff, Club, Team, Nation, Competition and so on) and 0x239 is the offset from the start of any given Player object where acceleration is stored. You can trust the offsets defined in my constants file.
GeorgeFloydOverdosed said: What led you to 0x0144b40180 anyway
I opened Cheat Engine, went to the memory address of a known player (which my scouting app told me) and added a "Tell me what read from this address" breakpoint on the player's acceleration. One of the instructions was the one I quoted in my code snippet here. I noticed the function actually hit a lot of offsets and learned it was combining and multiplying them in various ways.
GeorgeFloydOverdosed said: Would be interested in seeing the suspected role location
This is something you led me to last night, with this comment:
GeorgeFloydOverdosed said: I spent a while trying to find attribute combos in the code using this info. I came across a few intriguing ones, such as Reflexes interacting with CommandOfArea for some reason, but no clear formula I'm looking for.
I wondered what you were talking about so I searched the FM binary for "Command", "CommandOfArea" and "Command_of_Area".
"Command_Of_Area" is a hard-coded string at memory location 0x145c48e51 and it is used in only one location: 0x144380f6c. I can't copy and paste the whole thing but as soon as I saw it, I was intrigued.
It looks like it's taking a bunch of attribute names, feeding them in to a function and then getting a value back from them. Reading player attributes? Surely not, they're stored in a Player object in memory and accessed through offsets, not by string.
I looked at what called that function and got one hit: 0x14231dcd7.
It's a very boring looking function but then I noticed some strange looking memory addresses on lines 16, 33 and 50. I looked closer and realised they're not memory addresses, they're the words "posi", "attr" and "weig" represented as numbers (i.e. the character codes for each letter have been concatenated to make a 4 byte number). This intrigued me further.
I went back to the previous function (the one that read in attributes and did something with them) and noticed the bottom: the game reads in string references to player positions (e.g. DL, AMRL, SW) and it takes those plus the values read in above and feeds them in to another function.
Given all this, I'm convinced it is determining some sort of relationship between positions and attributes. Problem is, I can't find when the code is executed. I've put breakpoints all around it and they never fire. Is the code unreachable and unused? Does it fire when the game first loads, before I get a chance to attach Cheat Engine to it? (I can test this by launching the game with a debugger already attached, which I will do after work). Is it legacy code? (This wouldn't necessarily surprise me, I've found some legacy stuff already (around a mechanic called Match Boost in training modules that never seems to get used)).
Thank you for all these discoveries, small question that i have, do staff have any relevant role in player development, i tend to try and have the best staff there is, but with all you all discovered im not sure if it really matters or not. Assitant managers, scouts, phisios, all that, does it really matter? Thank you
I assume it makes no difference to the results but I'm pretty sure that custom goalkeeper metric is wrong.
It says "+10% means the keeper conceded 10% fewer than expected."
If I faced 10 goals and only conceded 9 then I've conceded 10% fewer than expected, In this formula though...
(1 expected goal prevented + 9 conceded) / 9 conceded
10 / 9
11.11%
That's not 10%. To get 10% he'd need to divide goals prevented by xG: 1 / (1 + 9). Not sure which one of these he actually wanted though. Still, it's interesting so far.
Gerrard said:
I came here today with the intention of making an assessment of this video lol
Very interesting findings
Flair is strongly negatively correlated with possession won for midfielders. Is this because of the attribute itself altering the role, or the high flair causing a low-possession-won role to be selected? And then, does more possession won lead to more or less wins?
I think overall this can actually be triangulated with the key attribute template and EF 424 IF HP V2 P101 AC tactic to determine what tactical measures are beneficial and which are detrimental, and then refine the key attributes - to per position specificity - based on that. Perhaps it might even clue us into how the tactic can be edged out too.
We see that flair and off-the-ball have good & bad results for different positions/measures. And he finds bravery & one-on-ones for GK were significant in relation to goals conceded. So I will do some testing to see.
There are some caveats to his conclusions I think most will miss. For instance, the GK goals conceded thing, isn't actually measuring team goals conceded, and finishing produces more goals on wingers, but that doesn't mean the team scores more goals as a whole (my own testing on finishing shows that it simply take off goals from ST and give it to the winger).
But there's a lot of valid and potentially fresh information in it.
GeorgeFloydOverdosed said: Very interesting findings
How do you feel about the premise that different positions require different attributes? I know that flies in the face of your theory of a generalised make-up (last I checked, anyway). I thought for a while that the positional requirements of attributes was overblown because FM always punishes me for expecting too much of it.
Now I'm unsure, but I've had great success promoting Warrington up the leagues using your old, old weights.
I just can't find where that code above is executed. I've decided to search for "weig" in hopes that I can find somewhere else in the code where that logic is performed. In doing so, I've found the nuttiest string references in the binary. What the actual hell is in this game?
EDIT: one more. I actually googled the strings in this one and found a medical website with the exact same strings. I'd love to talk to one of the people who worked on this game and ask exactly what directory they've accidentally included in their build pipeline on this project.
Medical website
Maggh said: Thank you for all these discoveries, small question that i have, do staff have any relevant role in player development, i tend to try and have the best staff there is, but with all you all discovered im not sure if it really matters or not. Assitant managers, scouts, phisios, all that, does it really matter? Thank you
I would surmise overall that most staff do matter moderately, both for growth and performance. It can also matter for players being willing to sign for your club.
People are going to have different impressions, but for me I'd say staff are about 70% as impactful as I'd intuitively think they should be.
LightningFlik said: How do you feel about the premise that different positions require different attributes? I know that flies in the face of your theory of a generalised make-up (last I checked, anyway). I thought for a while that the positional requirements of attributes was overblown because FM always punishes me for expecting too much of it.
Now I'm unsure, but I've had great success promoting Warrington up the leagues using your old, old weights.
Before I played around with tactics, I would have made this critique of his findings, citing my attribute brute force testing, but now I am more open to the idea again of there being positional differences.
My impression now is that what is going on is that the Knap tactic favors a certain set of attributes, and this would extend to all the very similar top tactics in general (different roles or even formations, but all high pressing/intensity).
So if you play a defensive tactic, maybe then positioning would matter. Thing is, all defensive tactics lose. So effectively positioning never matters.
So it can be true at the same time that (1) only certain attributes matter for winning games, and (2) different tactics need different attributes.
Now I have tried positional variation in my attribute tests with the Knap tactic, and found there isn't any I can see (this is after being convinced for the longest time that concentration mattered for defenders but not forwards), but it's possible I am mistaken on one or two, or perhaps I didn't try the right combo (i.e. maybe I tested flair alone on ST, but not flair alone on MC).
I'll be doing some tests today based on Mustermann's findings, so we'll see if there are in fact position differences that actually increase/decrease win rate.
LightningFlik said: I just can't find where that code above is executed. I've decided to search for "weig" in hopes that I can find somewhere else in the code where that logic is performed. In doing so, I've found the nuttiest string references in the binary. What the actual hell is in this game?
That's funny
I wonder what they've included that brought that stuff into it. I noticed there was some chinese characters, that links to a chinese website in the code for free template resources and whatnot - must be that they used an asset from it.
How did you get it to display the phrases as single lines like that? Maybe its cause I didn't let it fully finish processing I guess.
GeorgeFloydOverdosed said: How did you get it to display the phrases as single lines like that? Maybe its cause I didn't let it fully finish processing I guess.
Maybe Analysis -> One Shot -> ASCII Strings?
I know I did that at the start. Then I use Window -> Defined Strings to search.
I first tried a bunch of adjustments together based on Mustermann's findings, and what seems to suit the knap tactic:
fb = tackling (cross success %)
fb = crossing, off the ball (high intensity sprints)
dm = low flair (posession won)
dm = off the ball, low marking (pressures attempted)
winger = low decisions, low off the ball (dribbles)
winger = crossing, teamwork, low heading (pressures completed)
st = off the ball, low technique (xG overperformance)
'Low' attributes were reduced to 1, while the others were increased to 20. CA was generally higher, with the highest gain being +20 CA on fullbacks.
Results: 7th, 7th
So no performance difference
I then tried just crossing 16 on fullbacks & wingers.
Results: 9th (sacked), 1st, 3rd, 7th, 6th (sacked), 8th (sacked) = 5.666 average
Normal result is ~5th-7th, so perhaps a hint of a benefit to crossing in there due to the 1st which is not unprecedented but quite rare. Not quite enough to conclude crossing has any benefit though. I think a few more samples with high consistency & technique would settle this one way or the other.
Next, bravery 20 for DCs.
Results: 6th (sacked), 3rd, 5th, 9th (sacked), 5th = 5.6 position
No revelations here. Again, perhaps a very marginal benefit outweighed by CA cost, similar to strength or vision.
I forgot to change Man City's media expectation to 20th, hence the high rate of sackings. Doesn't invalidate the results, just means some samples are semi-wasted (9th sacked means they wont end up first, but they could have ended up 4th say).
I am also doing this in FM24, not FM26, but I doubt that that is why he finds crossing matters and whatnot.
Aggression 11 > 1:
11th (sacked), 8th (sacked), 6th, 8th (sacked), 12th (sacked) = 9 position