Hi! I noticed an issue with FMSS in multiplayer saves. When I load my save, FMSS seems to identify my friend as the active human manager instead of me. Because of that, “My Club” points to his club, so I can’t properly filter players from my own club.
Would it be possible to make FMSS detect the correct human manager in multiplayer saves, or maybe add an option to manually select which club should be considered “My Club”?
GeorgeFloydOverdosed said: Finishing, strength, and vision were technically in the previous weights. I dropped them from the file because the attributes that are adequate you are bound to get at the required levels most of the time anyway:
Strength - 8 Vision - 7 Finishing - 7
I played around a fair bit with strength in particular in these new weights. I thought maybe it's around 10-20, but turned not to be the case. Vision is 20 on Messi which was food for thought, but it didn't seem to affect ranking alignment for the better.
Actually teamwork is the one I most wonder about.. players like Maeda have high teamwork, and there's some mathematical study on FM24 on github that a guy did for university work that found teamwork was a key correlate of performance.. but I read through it, and overall I think its just full of mistaken findings. My own testing and HarvestGreen's found teamwork doesn't matter, so at the moment I don't see a valid reason to include it.
Loyalty I included as '1' at the last moment pretty much symbolically. It would have some very minor to minor effect via morale, so i felt justified giving it a little '1'. But obviously loyalty deserves some weight for gameplay reasons. Expand
Just one small thing I noticed: you said you included Loyalty as “1” at the last moment, but in the weights you posted, Loyalty is 0.2. Is 0.2 the intended final value, or was Loyalty supposed to be 1?
Also, given what you said about Strength, Vision, Finishing, Teamwork and Loyalty, would you say these are attributes we should actually pay attention to when evaluating a player, or are they basically not worth considering unless the value is particularly low/high?
I’m especially wondering about Teamwork since you still seem a bit uncertain about it.
And one last thing: have you also updated the goalkeeper weights, or are these still the current ones?
GeorgeFloydOverdosed said: The main thing would be the non-linearity of attributes, which the testing did show, but can't be reflected in linear weightings.
HarvestGreen did do some theorizing on attribute interactions, and I've dug up quotes from the Collyer brothers and in-game tips and whatnot which describe attribute interactions as well. I found that those latter things turn out to be generally untrue, or at least outdated.
I reckon there are attribute interactions though, and HarvestGreen's ideas on it are interesting.. just lack the solid data on it at the moment though.
I don't really have solid data to back it, but I'm personally convinced that aggression x dirtiness is an interaction, it just seems logical and seemed to solve something insoluble with the ratings at one point too.
This is partly why I decided to release it as is now with mostly linear weights, because one could go down the rabbit role of trying out all these different attribute combos and either getting nowhere or being mislead into seeing something that isn't there, while also spending a lot of time doing so. It remains difficult to test attribute combinations, but I'm sure there's some method to bear it out properly.
Probably a formatting issue
The FMSS weights I gave before simply reflect the minimum set of attribute values to attain 5th in the Premier League. They represent the best 'bang-for-buck' relative ratio of attributes.
I guess the question that the objective ranking raises in relation to that is, if work rate supposedly caps out at 13, why is it so critical for Maeda, and important in general? And if dribbling isn't so essential, is it really necessary to include it high - even if it does actually have significant benefits. So it does shine a new light on certain things. Personally I strongly favor what is true in realistic testing (the player rankings derived from the team positions), rather than what the isolated or constrained testing shows (including my own). Expand
I also noticed that you added 5 attributes that weren’t in the previous set: Strength, Finishing, Ambition, Loyalty and Vision.
Was that intentional as part of the new weighting method?
GeorgeFloydOverdosed said: Yes, that is precisely the correct summary of it, and I daresay a better explanation than I did.
I'm glad you immediately understand, because I think it's easy to misinterpret this latest thing I'm doing with the weights.
I started with the presumption that finishing is almost completely unnecessary, but ChatGPT independently came to the conclusion that finishing should be removed too when I fed it all the player's attributes and asked it to come up a set of weights to fit the rankings.
It was surprising how strongly weighted anticipation and work rate seems to be. Maeda is still down a bit, so work rate could in fact do with being a bit higher perhaps. It's strange to me, because I know that (and you can see HarvestGreen's data to verify this) that work rate almost caps out at 13. But that is when work rate has been tested in isolation or partial isolation. Perhaps there is something like 'determination x work rate x stamina' going on. I couldn't find a way of getting around weighting work rate highly.
Anticipation in my observations did continue to scale, but had diminishing returns. But putting that aside for now, it makes sense that it would be a key attribute because ostensibly it's the movement ('off the ball' as speed?) to the area before possessing the ball. So it sounds like it cuts down on the pace/acc requirement to me, because once they have the ball, they have less distance to travel. Concentration would be a similar kind of effect, where low concentration leads to a delay in getting into position to receive or stop a ball (the latter offset by 'positioning' perhaps).
Consistency, Important Matches, and Natural fitness has not been incorporated with much accuracy. They are kind of afterthoughts, as I know they will matter somewhat, but not sure to what degree. I've used HarvestGreen's data to set them, and so long as they're not interfering with the ranking, I generally leave them alone. Same with pressure, professionalism, etc.
Dribbling I've been in two minds about. Most of the time I had it set pretty high at ~40, sometimes as high as 60. I ended up reducing it to 15. ChatGPT actually said early on to do this too. Both were equally functional. From testing, we know dribbling is a very strong attribute that scales well.. I suspect it's not needed much to match the rankings, because hardly any players have high dribbling anyway. It's the hardest attribute to get high in the game I believe.
Yes, that is how they have to be written for FMSuperScout, otherwise the program won't work. That is how labels the attributes internally.
I would add the comma. Expand
That makes a lot of sense, especially the distinction between an attribute being strong in isolation and actually being necessary to reproduce the player rankings.
The WorkRate interaction theory is probably the most interesting part to me. If something like Determination × WorkRate × Stamina is happening, it could explain why isolated attribute testing and the ranking weights seem to tell slightly different stories.
Same for Dribbling — it can still be a very strong attribute without needing a high weight here if the players in the ranking simply don't have enough variance in it.
I think that's probably the most important thing for people to understand with these weights: they aren't necessarily a pure "attribute strength" ranking, they're the weights that best reproduce the objective player rankings.
Also, I noticed there are some strange extra spaces between a few attributes in the list. Is that intentional, or just a formatting issue?
One other thing I'm wondering: is it possible that some of your original FMSS weights were simply set too low at the beginning, which would also partly explain why a few attributes have increased so dramatically now?
Do you think these huge increases are entirely a consequence of the different methodology, or could your original FMSS weights also have been underestimating some of these attributes from the start?
I'm not a programmer, so I don't know how to implement the injury proneness & dirtiness weights. I thought, maybe I'll just add them as simple negatives, like for the GS weights, and adjust it until it matches the rankings, but then I realized it doesn't do FM24 db, only FM26.
Replace the weights in the app.js file with those (search for 'FM-Arena' ).
For adding injury proneness & dirtiness, which are in fact crucial (but I guess you could also just check players manually to have low inj and dirt values), we're going to need someone like Panneton0 or perhaps the creator of FMSuperScout itself to help out. Could probably do it myself, but can't be bothered doing an hour of research honestly. Expand
I compared the new weights with the previous ones, and some of the changes are huge:
The biggest question for me is: why such massive changes?
From what I understand, the old weights were based on finding the cheapest/minimum attribute balance capable of achieving around 5th in the Premier League, whereas the new weights are being fitted to a much larger set of objective player rankings.
So it makes sense that the result could be very different: instead of asking “what minimum combination of attributes gets results?”, you're now asking “which attributes best explain the actual ranking of players?”
Still, the scale of the change is fascinating.
The new model seems to put an enormous premium on Pace, Acceleration, Stamina, Work Rate and Anticipation, while attributes such as Dribbling, Consistency, Important Matches or Natural Fitness become much less influential.
And then you have Finishing at only 0.4, which is pretty wild too.
Curious to hear what people think, especially about Stamina becoming #1 and the huge gap that now exists between the top attributes and everything else.
PS: Quick question: why are attributes like WorkRate, ImportantMatches, and NaturalFitness written without spaces? Is that just the naming format, and do they need to be written exactly like that in app.js as well? Also, should I add a comma after the final value, Consistency: 2.82, or should the last entry be left without one?
GeorgeFloydOverdosed said: Yeah, I left it out because I have to work out how to best translate it from the FMST26 weights first. I'll do that now. Expand
- Designed to align with the objective results of real players within the English Premier League - GK not yet done, weights from Premier League 1.0 are used which are decent - Do not read too much into the specific values for each attribute, I used HarvestGreen's and my own data as a basis to start with, but it's largely just plugging in numbers until I get the output I'm looking for, which is alignment with the rankings. Individual attribute weights will be inaccurate or even superfluous, but it's what they sum up to that matters. - GS file is a bit less accurate than the FMST26 weights. Highly recommend FMST26 over GS if possible.
I could keep working on this for forever and a day, but I feel like it's good enough right now for a first version.
You can make your own adjustments, add in non-linear formulas, etc. to line up with the rankings better if you like, since the ranking data is really what's solid. Expand
GeorgeFloydOverdosed said: Yes, those are the most recent. It's simply my findings for the balance of attributes that achieves 5th in the Premier League at minimal cost/requirements.
But now I have a bunch of objective player rankings to work with, so I'm currently working a set of weights that lines up with this objective ranking list. And I'm close to done on the first go at this. Expand
Oh, that sounds really interesting. I’d definitely be curious to see how different the new weights end up being compared to the current ones once you’re done. Especially if they’re now being calibrated against an objective player ranking rather than purely the “5th in the PL at minimal cost” benchmark. Please share them when you’re happy with the first version!
GeorgeFloydOverdosed said: I haven't used either enough to form an opinion on it. I'll be using FMST26 simply because it supports FM24, but FMSuperScout doesn't. Expand
and btw, may i ask if you still refer to your ratings, or did you changed/tweaked them?
83% | Giovanni Di Lorenzo - 3rd, 3rd, 2nd, 9th, 2nd, 5th, 5th = 4.143 position 66% | Kingsley Schindler - 4th, 11th, 6th, 11th = 8 position
It's worth mentioning again that all players were set to 20 ST and nothing else. This will affect a few players slightly.
* I forgot to duplicate Salah first before moving him, so there was no Salah for the opposition. Could redo, but shouldn't make much difference. Expand
mavali said: The real in-game date is findable in theory, but in practice it is a serious reverse-engineering job: to a memory scanner every contract, birthday and fixture looks like a date, and the right address shifts with every FM patch. So it would be a lot of work that breaks on every update, to fix a label that is only a few days off.
Instead the plugin lets every loaded team vote with its next-match date and takes the consensus: always close, works in every save, survives patches. If the gap is bigger than a few days, your dump is just old: press F9 again. Expand
Thanks for the explanation, that actually makes a lot of sense. I completely understand why you're using the next-match consensus instead of trying to locate the real in-game date in memory.
In my case though, the difference is sometimes more than just a few days—it's occasionally a few months behind the actual in-game date.
Also, pressing F9 behaves exactly like clicking New Data for me. It reloads the data successfully, but it doesn't bring the loaded date any closer to my current in-game date. It just reloads the same snapshot/date again.
That said, I'm really not complaining. I'm already happy that everything is working again after the recent fixes. I just thought I'd mention it in case it's useful, and maybe it's something that can become more accurate in future versions. Either way, I'm really enjoying FMSS and I'm looking forward to seeing how it continues to improve.
So far, I haven't had any issues with FMSS—fingers crossed! 🤞 I do have one question though. Why is it that when I load the data, like in this example, it always loads a date that's a little earlier than the actual in-game date I'm currently on? I've attached some screenshots to show what I mean.
First: 1.4.2 is out. It fixes the startIndex crash some of you hit, makes scans fast again (the 1.4.1 snapshot is now only an automatic retry when a live scan misses too much memory), lowers the plugin's own memory use, and adds a check-for-updates button. Problem reports now include scan telemetry automatically. @bf3metro metro this release is aimed squarely at your Win32 1450 and 17% errors: they come from Windows running low on memory with a 157k-player save loaded, which is also why a reboot helped. Update and let me know.
@Purity ty thank you, great list and clearly a lot of care went into it. I went through everything and two of your ideas are coming in the next release: a GK meta score (weights from harvestgreen22's keeper attribute retest, so measured numbers rather than invented ones) and a PA meta column with its own filter. For the other features: pull requests on GitHub are very welcome, one per feature keeps them reviewable and your credit visible.
@Panneton0 noted, and thanks for the offer to test.
I saw your message on GitHub. Unfortunately, I can’t test the new version yet because I’m at work, but I’ll install and test it as soon as I get home.
First of all, thank you for taking the time to investigate the issue so thoroughly. I really appreciated reading your explanation because it makes a lot of sense, especially considering the random behaviour I was experiencing. Sometimes it would work after a reboot, sometimes only the first scan would work, then it would suddenly fail for no apparent reason. Your explanation fits that behaviour perfectly.
It’s also clear that you didn’t just patch the symptom—you took the time to identify the root cause and improve the plugin as a whole. I really like the changes you’ve made in 1.4.2. Reducing memory pressure, improving the diagnostics, and making the scanning process more robust overall is exactly the kind of work that gives users confidence in a project.
I’m really hoping this update fixes the issue and that I won’t see those errors anymore. But even if I do, I still wanted to take a moment to thank you.
I really appreciate how much time you’ve spent investigating my reports, explaining the root cause in detail, and helping users who run into problems like mine. You’re incredibly responsive and willing to help, and that’s something I don’t take for granted. To be honest, I’ve rarely seen this level of support from a developer, not even from the Football Manager developers themselves.
I’m also really looking forward to seeing what comes next. FMSS already has a lot of potential, and seeing the amount of care and effort you put into improving it makes me genuinely excited for future versions and the new features you’ll add over time. I honestly believe FMSS has a very bright future ahead of it.
I also noticed that you accept donations. Once I’ve had the chance to test 1.4.2, I’d be more than happy to make one as a small thank-you for all the work and support you’ve provided.
Thanks again, and I’ll let you know how the testing goes!
Unfortunately I'm still getting the same error after updating to 1.4.1.
The plugin is definitely updated, but scans still fail with:
Read failed: The scan could not read 17% of FM's memory.
The save was fully loaded and I waited before starting the scan.
I checked the BepInEx log and I think I found the reason. It looks like the snapshot isn't being created successfully:
No snapshot available (MemoryCaptureSnapshot failed (Win32 1450: Insufficient system resources exist to complete the requested service)). Falling back to live memory scan (as before v1.4.2).
So it looks like the plugin falls back to the old live scanner, and I end up with the exact same "17% of FM's memory" error as before.
I've attached the console output. Is there anything I can do to help diagnose why the snapshot creation fails with Win32 error 1450?
Expand
I have another update.
After rebooting my PC, the scan completed successfully without changing anything else.
This time the log says:
Scan reads from a frozen memory snapshot (VA clone).
and the scan completed successfully.
However, the behaviour is still very inconsistent and seems completely random.
Sometimes the snapshot creation fails with Win32 1450, causing the plugin to fall back to the live scanner, which then fails with the 17% memory error.
Other times the snapshot is created successfully and everything works perfectly.
I also noticed another pattern that might help:
Sometimes the scan doesn't work at all. Sometimes the very first scan after launching FM works. But after I continue playing, advance a few in-game days and try New Data again, it often fails with the memory read error. Occasionally it works again without me changing anything.
It doesn't seem to depend on the save itself, as I'm using the exact same save and settings every time. Likewise, it doesn't seem to be tied to any specific action. The success or failure appears completely random, even under what appear to be identical conditions.
Hopefully this additional information helps narrow the issue down. Let me know if there's anything else you'd like me to test or any additional logs that would be useful.
Unfortunately I'm still getting the same error after updating to 1.4.1.
The plugin is definitely updated, but scans still fail with:
Read failed: The scan could not read 17% of FM's memory.
The save was fully loaded and I waited before starting the scan.
I checked the BepInEx log and I think I found the reason. It looks like the snapshot isn't being created successfully:
No snapshot available (MemoryCaptureSnapshot failed (Win32 1450: Insufficient system resources exist to complete the requested service)). Falling back to live memory scan (as before v1.4.2).
So it looks like the plugin falls back to the old live scanner, and I end up with the exact same "17% of FM's memory" error as before.
I've attached the console output. Is there anything I can do to help diagnose why the snapshot creation fails with Win32 error 1450?
The steam_appid.txt fix definitely solved the loading issue, as the plugin now loads consistently. However, I ran into a different problem afterwards. The plugin starts scanning correctly, but the scan fails because it can only read around 85–88% of FM's memory, even though the save has already finished loading. I tried again after waiting, but I still get:
"Read failed: The scan could not read 15% of FM's memory. Your existing data was kept."
Quick check: open BepInEx\LogOutput.log in your FM folder. It is rewritten every time the mod layer actually runs. If it is from an older session than the one you just played, the plugin was not in your game.
@Lapidus good thinking, but no shifting memory addresses: the plugin simply was not in the relaunched process, so a reconnect button would have had nothing to talk to. @Wigo this may well be yours too, try the same file, otherwise the "FM will not start" section in the troubleshooting guide.
QUESTIONS AND REQUESTS
@OpticFawn honest answer: unlikely. The plugin leans on Windows-specific plumbing (BepInEx injection, reading process memory), so macOS means rewriting the whole game-side half.
@Kamas1 META_W is the weight per attribute, straight from FM-Arena's attribute testing table. The meta score is the weighted average of a player's visible attributes on the familiar 1-20 scale. Attributes with no measured positive effect are not in the table, and keepers are excluded because the testing could not measure keeper attributes. Which also answers @Panneton0: a GK meta would be an invented number next to measured ones, keepers get role ratings instead.
@Forsti37 your FM24 tool sounds impressive, hope you find a way to release it. That EULA tightrope is exactly why this one is open source, reads memory locally and never touches game files.
I am collecting all feature requests from this thread: USD currency (@johnconnerson), a meta-at-PA column in the table (@kami911, nice work, pull requests welcome), position weighting (@Panneton0), alternative hidden-attribute weightings (@GeorgeFloydOverdosed, if you have data behind your numbers, open a GitHub issue). Some of these will likely make it into an upcoming release.
Thanks to everyone who filed GitHub issues with logs attached. The steam_appid fix exists because one user kept testing until it fell over, so keep the detailed reports coming. Expand
Thank you so much for taking the time to investigate this so thoroughly. I really appreciate the effort you put into tracking the issue down and explaining exactly what was happening.
For now, it actually seems to be working! I created the steam_appid.txt file exactly as you described, and after several launches FMSuperScout has loaded successfully every time so far. Hopefully this was indeed the root cause.
Your explanation also makes perfect sense and matches everything I had been experiencing. The behaviour was always completely random: sometimes it worked, sometimes it didn't, without me changing anything. There were even days where it suddenly started working again after previously refusing to load, which made it almost impossible to understand what was going on. Knowing that FM26 can restart itself and that Doorstop then misses the relaunched process explains that inconsistency really well.
I'll keep testing it over the next few days with multiple launches and different saves to make sure the issue is truly gone. If it happens again, I'll make sure to grab the BepInEx\LogOutput.log from the failed session before restarting FM and I'll post it here.
Thanks again for the excellent support and for taking my report seriously. I really appreciate you sticking with this until you found a likely cause. Hopefully this fix will help anyone else who runs into the same problem.
Lapidus said: My wild guess would be the tool somehow fails to recognize when a new save loaded and adjusts itself to the new memory addresses.
Probably, the tool needs an additional features that help to combat that issue, for example, there should be a button that you must click every time you load a new save so the tool to check and correct the memory addresses. Expand
That's actually an interesting theory, and I think a manual reconnect/reinitialize button could definitely help.
The strange thing in my case is that it doesn't even seem related to switching saves.
The whole issue is completely random. Sometimes FMSS works perfectly, then I simply close FM26 normally, come back a few hours later (or the next day), launch exactly the same save, and it suddenly stops working.
When it happens, F9 does absolutely nothing, and clicking New Data always says:
"FM26 is not picking up the request. Is your save loaded?"
Then, after restarting FM26 a few times (or sometimes without doing anything different at all), it may suddenly start working again.
That's what makes it so frustrating. There is absolutely no pattern. I never know:
when it will work, when it will stop working, why it starts working again, or whether anything I tried actually fixed it or if it was just pure luck.
I've already tried pretty much everything: reinstalling FMSS, reinstalling BepInEx, verifying the game files, deleting the FMSS AppData folder, deleting the generated files, checking Windows Defender... nothing consistently fixes it.
So I honestly don't know if it's a memory address issue, a communication issue between FMSS and the plugin, or something else entirely. Your idea could definitely be part of it though.
I'm still having the same issue with FMSuperScout 1.3.1 on the latest FM26 Steam version.
Symptoms:
FMSuperScout works normally for one or more sessions. After closing FM26 and launching it again later (sometimes the next day), FMSS randomly stops working. Pressing F9 does nothing.
Clicking New Data always shows:
"FM26 is not picking up the request. Is your save loaded?"
Sometimes it starts working again completely at random without any obvious reason.
What I've already tried:
Clean reinstall of FMSS. Clean reinstall of BepInEx 6 (IL2CPP x64). Verified FM26 files through Steam. Deleted %LOCALAPPDATA%\FMSuperScout. Deleted request.flag, dump.json, status.json. Disabled Windows Defender Controlled Folder Access. No antivirus besides Windows Defender. Latest FM26, latest FMSS. Same behavior across different saves.
BepInEx log:
BepInEx loads successfully.
The plugin is loaded:
Loading [FMSuperScout 0.1.40] No startup errors.
Sometimes I also see:
Verlopen/onleesbaar data-verzoek genegeerd
(expired/unreadable request ignored).
Since the plugin is loaded correctly but FMSS later reports "FM26 is not picking up the request", could there be a known issue where HotkeyBehaviour or the request listener stops processing requests after restarting FM26?
If there is a debug build or additional logging I can enable, I'm happy to test it.
Hi! I noticed an issue with FMSS in multiplayer saves.
When I load my save, FMSS seems to identify my friend as the active human manager instead of me. Because of that, “My Club” points to his club, so I can’t properly filter players from my own club.
Would it be possible to make FMSS detect the correct human manager in multiplayer saves, or maybe add an option to manually select which club should be considered “My Club”?
Strength - 8
Vision - 7
Finishing - 7
I played around a fair bit with strength in particular in these new weights. I thought maybe it's around 10-20, but turned not to be the case. Vision is 20 on Messi which was food for thought, but it didn't seem to affect ranking alignment for the better.
Actually teamwork is the one I most wonder about.. players like Maeda have high teamwork, and there's some mathematical study on FM24 on github that a guy did for university work that found teamwork was a key correlate of performance.. but I read through it, and overall I think its just full of mistaken findings. My own testing and HarvestGreen's found teamwork doesn't matter, so at the moment I don't see a valid reason to include it.
Loyalty I included as '1' at the last moment pretty much symbolically. It would have some very minor to minor effect via morale, so i felt justified giving it a little '1'. But obviously loyalty deserves some weight for gameplay reasons.
Just one small thing I noticed: you said you included Loyalty as “1” at the last moment, but in the weights you posted, Loyalty is 0.2. Is 0.2 the intended final value, or was Loyalty supposed to be 1?
Also, given what you said about Strength, Vision, Finishing, Teamwork and Loyalty, would you say these are attributes we should actually pay attention to when evaluating a player, or are they basically not worth considering unless the value is particularly low/high?
I’m especially wondering about Teamwork since you still seem a bit uncertain about it.
And one last thing: have you also updated the goalkeeper weights, or are these still the current ones?
Reflexes: 12.8, Agility: 8.0, Acceleration: 4.7, Pressure: 4.1, Pace: 3.5, AerialReach: 3.4
PS: What is the correct way to write it?
HarvestGreen did do some theorizing on attribute interactions, and I've dug up quotes from the Collyer brothers and in-game tips and whatnot which describe attribute interactions as well. I found that those latter things turn out to be generally untrue, or at least outdated.
I reckon there are attribute interactions though, and HarvestGreen's ideas on it are interesting.. just lack the solid data on it at the moment though.
I don't really have solid data to back it, but I'm personally convinced that aggression x dirtiness is an interaction, it just seems logical and seemed to solve something insoluble with the ratings at one point too.
This is partly why I decided to release it as is now with mostly linear weights, because one could go down the rabbit role of trying out all these different attribute combos and either getting nowhere or being mislead into seeing something that isn't there, while also spending a lot of time doing so. It remains difficult to test attribute combinations, but I'm sure there's some method to bear it out properly.
Probably a formatting issue
The FMSS weights I gave before simply reflect the minimum set of attribute values to attain 5th in the Premier League. They represent the best 'bang-for-buck' relative ratio of attributes.
I guess the question that the objective ranking raises in relation to that is, if work rate supposedly caps out at 13, why is it so critical for Maeda, and important in general? And if dribbling isn't so essential, is it really necessary to include it high - even if it does actually have significant benefits. So it does shine a new light on certain things. Personally I strongly favor what is true in realistic testing (the player rankings derived from the team positions), rather than what the isolated or constrained testing shows (including my own).
I also noticed that you added 5 attributes that weren’t in the previous set: Strength, Finishing, Ambition, Loyalty and Vision.
Was that intentional as part of the new weighting method?
I'm glad you immediately understand, because I think it's easy to misinterpret this latest thing I'm doing with the weights.
I started with the presumption that finishing is almost completely unnecessary, but ChatGPT independently came to the conclusion that finishing should be removed too when I fed it all the player's attributes and asked it to come up a set of weights to fit the rankings.
It was surprising how strongly weighted anticipation and work rate seems to be. Maeda is still down a bit, so work rate could in fact do with being a bit higher perhaps. It's strange to me, because I know that (and you can see HarvestGreen's data to verify this) that work rate almost caps out at 13. But that is when work rate has been tested in isolation or partial isolation. Perhaps there is something like 'determination x work rate x stamina' going on. I couldn't find a way of getting around weighting work rate highly.
Anticipation in my observations did continue to scale, but had diminishing returns. But putting that aside for now, it makes sense that it would be a key attribute because ostensibly it's the movement ('off the ball' as speed?) to the area before possessing the ball. So it sounds like it cuts down on the pace/acc requirement to me, because once they have the ball, they have less distance to travel. Concentration would be a similar kind of effect, where low concentration leads to a delay in getting into position to receive or stop a ball (the latter offset by 'positioning' perhaps).
Consistency, Important Matches, and Natural fitness has not been incorporated with much accuracy. They are kind of afterthoughts, as I know they will matter somewhat, but not sure to what degree. I've used HarvestGreen's data to set them, and so long as they're not interfering with the ranking, I generally leave them alone. Same with pressure, professionalism, etc.
Dribbling I've been in two minds about. Most of the time I had it set pretty high at ~40, sometimes as high as 60. I ended up reducing it to 15. ChatGPT actually said early on to do this too. Both were equally functional. From testing, we know dribbling is a very strong attribute that scales well.. I suspect it's not needed much to match the rankings, because hardly any players have high dribbling anyway. It's the hardest attribute to get high in the game I believe.
Yes, that is how they have to be written for FMSuperScout, otherwise the program won't work. That is how labels the attributes internally.
I would add the comma.
That makes a lot of sense, especially the distinction between an attribute being strong in isolation and actually being necessary to reproduce the player rankings.
The WorkRate interaction theory is probably the most interesting part to me. If something like Determination × WorkRate × Stamina is happening, it could explain why isolated attribute testing and the ranking weights seem to tell slightly different stories.
Same for Dribbling — it can still be a very strong attribute without needing a high weight here if the players in the ranking simply don't have enough variance in it.
I think that's probably the most important thing for people to understand with these weights: they aren't necessarily a pure "attribute strength" ranking, they're the weights that best reproduce the objective player rankings.
Also, I noticed there are some strange extra spaces between a few attributes in the list. Is that intentional, or just a formatting issue?
One other thing I'm wondering: is it possible that some of your original FMSS weights were simply set too low at the beginning, which would also partly explain why a few attributes have increased so dramatically now?
For example:
Stamina: +13.58
Pace: +11.36
Acceleration: +11.24
WorkRate: +8.20
Anticipation: +6.44
Concentration: +4.26
JumpingReach: +4.04
Do you think these huge increases are entirely a consequence of the different methodology, or could your original FMSS weights also have been underestimating some of these attributes from the start?
I'm not a programmer, so I don't know how to implement the injury proneness & dirtiness weights. I thought, maybe I'll just add them as simple negatives, like for the GS weights, and adjust it until it matches the rankings, but then I realized it doesn't do FM24 db, only FM26.
Here's the weights at least that will work:
Pace: 17.36, Acceleration: 17.24, JumpingReach: 9.24, Dribbling: 2.92, Pressure: 3.34, Balance: 2.7, Concentration: 9.46, Anticipation: 11.64, Determination: 6, Agility: 3.4, Stamina: 18.78, Strength: 0.2, Composure: 5.12, WorkRate: 12.6, Finishing: 0.4, Aggression: 1.26, Professionalism: 3, Ambition: 0.4, Loyalty: 0.2, Vision: 0.1, ImportantMatches: 2.04, NaturalFitness: 1.58, Consistency: 2.82
Replace the weights in the app.js file with those (search for 'FM-Arena' ).
For adding injury proneness & dirtiness, which are in fact crucial (but I guess you could also just check players manually to have low inj and dirt values), we're going to need someone like Panneton0 or perhaps the creator of FMSuperScout itself to help out. Could probably do it myself, but can't be bothered doing an hour of research honestly.
I compared the new weights with the previous ones, and some of the changes are huge:
Stamina: 5.2 → 18.78 (+13.58)
Pace: 6 → 17.36 (+11.36)
Acceleration: 6 → 17.24 (+11.24)
Work Rate: 4.4 → 12.6 (+8.2)
Anticipation: 5.2 → 11.64 (+6.44)
Concentration: 5.2 → 9.46 (+4.26)
Jumping Reach: 5.2 → 9.24 (+4.04)
While on the other side:
Natural Fitness: 4.8 → 1.58 (-3.22)
Important Matches: 5.2 → 2.04 (-3.16)
Aggression: 4.4 → 1.26 (-3.14)
Consistency: 5.2 → 2.82 (-2.38)
Dribbling: 5.2 → 2.92 (-2.28)
Professionalism: 5.2 → 3 (-2.2)
The biggest question for me is: why such massive changes?
From what I understand, the old weights were based on finding the cheapest/minimum attribute balance capable of achieving around 5th in the Premier League, whereas the new weights are being fitted to a much larger set of objective player rankings.
So it makes sense that the result could be very different: instead of asking “what minimum combination of attributes gets results?”, you're now asking “which attributes best explain the actual ranking of players?”
Still, the scale of the change is fascinating.
The new model seems to put an enormous premium on Pace, Acceleration, Stamina, Work Rate and Anticipation, while attributes such as Dribbling, Consistency, Important Matches or Natural Fitness become much less influential.
And then you have Finishing at only 0.4, which is pretty wild too.
Curious to hear what people think, especially about Stamina becoming #1 and the huge gap that now exists between the top attributes and everything else.
PS: Quick question: why are attributes like WorkRate, ImportantMatches, and NaturalFitness written without spaces? Is that just the naming format, and do they need to be written exactly like that in app.js as well? Also, should I add a comma after the final value, Consistency: 2.82, or should the last entry be left without one?
Legend!
Use FMST26 (works for FM24 & FM26) and copy paste this into statistics > custom metrics (advanced):
(acceleration * 86.8 + pace * 86.2 + jumping_reach * 46.2 + pressure * 16.7 + dribbling * 14.6 + work_rate * 63.0 + agility * 17.0 + anticipation * 58.2 + composure * 25.6 + stamina * 93.9 + consistency * 14.1 + determination * 30.0 + balance * 13.5 + strength * 1.0 + concentration * 47.3 + finishing * 2.0 + important_matches * 10.2 + natural_fitness * 7.9 + professionalism * 15.0 + ambition * 2.0 + loyalty * 1.0 + aggression * 6.3 + vision * 0.5 + left_foot * 6 + right_foot * 5 - (injury_proneness * (50 / (natural_fitness * 0.85))) - (dirtiness * 32 * (aggression * 0.1))) / 118
Genie Scout file:
https://files.catbox.moe/z7hsqg.grf
Notes:
- Designed to align with the objective results of real players within the English Premier League
- GK not yet done, weights from Premier League 1.0 are used which are decent
- Do not read too much into the specific values for each attribute, I used HarvestGreen's and my own data as a basis to start with, but it's largely just plugging in numbers until I get the output I'm looking for, which is alignment with the rankings. Individual attribute weights will be inaccurate or even superfluous, but it's what they sum up to that matters.
- GS file is a bit less accurate than the FMST26 weights. Highly recommend FMST26 over GS if possible.
I could keep working on this for forever and a day, but I feel like it's good enough right now for a first version.
You can make your own adjustments, add in non-linear formulas, etc. to line up with the rankings better if you like, since the ranking data is really what's solid.
any release for FMSS?
But now I have a bunch of objective player rankings to work with, so I'm currently working a set of weights that lines up with this objective ranking list. And I'm close to done on the first go at this.
Oh, that sounds really interesting. I’d definitely be curious to see how different the new weights end up being compared to the current ones once you’re done. Especially if they’re now being calibrated against an objective player ranking rather than purely the “5th in the PL at minimal cost” benchmark. Please share them when you’re happy with the first version!
and btw, may i ask if you still refer to your ratings, or did you changed/tweaked them?
Pace: 6, Acceleration: 6, JumpingReach: 5.2, Dribbling: 5.2, Balance: 4.8, Concentration: 5.2, Anticipation: 5.2, Determination: 5.6, Agility: 4, Stamina: 5.2, Composure: 4.4, WorkRate: 4.4, Aggression: 4.4, ImportantMatches: 5.2, NaturalFitness: 4.8, Consistency: 5.2, Pressure: 5.2, Professionalism: 5.2,
ST
90% | Erling Haaland - 1st, 1st, 4th, 1st, 2nd, 1st = 1.666 position
87% | Kylian Mbappe - 2nd, 3rd, 3rd, 3rd, 5th, 2nd, 1st, 1st = 2.5 position
87% | Mohamed Salah* - 1st, 3rd, 5th, 3rd, 3rd, 2nd, 1st = 2.571 position
84% | Heung-Min Son - 3rd, 2nd, 2nd, 2nd, 2nd, 6th, 4th = 3 position
82% | Daizen Maeda - 2nd, 3rd, 4th, 4th, 2nd, 3rd, 3rd = 3 position
81% | Kyogo Furuhashi - 4th, 2nd, 3rd, 5th, 3rd, 2nd, 2nd = 3 position
82% | Vinicius Junior - 5th, 4th, 1st, 3rd = 3.25 position
83% | Harry Kane - 5th, 2nd, 3rd, 3rd, 1st, 7th = 3.5 position
84% | Robert Lewandowski - 2nd, 2nd, 2nd, 3rd, 5th, 2nd, 8th, 5th, 3rd = 3.555 position
79% | Dusan Vlahovic - 1st, 4th, 4th, 5th, 1st, 6th, 4th, 4th = 3.625
83% | Lautaro Martinez - 7th, 3rd, 1st, 5th, 2nd, 5th, 2nd, 5th = 3.75 position
81% | Victor Osimhen - 3rd, 3rd, 7th, 3rd, 3rd, 4th, 3rd, 4th = 3.833 position
78% | Lionel Messi - 4th, 2nd, 1st, 5th, 9th, 3rd = 4 position
81% | Viktor Gyokeres - 6th, 4th, 3rd, 4th, 5th, 5th, 2nd, 5th, 2nd = 4 position
74% | Donyell Malen - 2nd, 2nd, 7th, 5th, 5th, 7th = 4.666 position
73% | Robert Glatzel - 5th, 7th, 6th, 3rd, 12th, 6th, 2nd, 6th, 8th = 6.111 position
69% | Paulo Dybala - 5th, 5th, 6th, 10th, 3rd, 12th, 6th, 5th, 6th, 6th = 6.4 position
64% | Adam Le Fondre - 8th, 11th (sacked), 5th, 7th (sacked), 6th (sacked), 8th (sacked) = 7.5 position
63% | Luis Suarez - 7th, 9th, 10th, 8th, 8th = 8.4 position
DR
83% | Giovanni Di Lorenzo - 3rd, 3rd, 2nd, 9th, 2nd, 5th, 5th = 4.143 position
66% | Kingsley Schindler - 4th, 11th, 6th, 11th = 8 position
It's worth mentioning again that all players were set to 20 ST and nothing else. This will affect a few players slightly.
* I forgot to duplicate Salah first before moving him, so there was no Salah for the opposition. Could redo, but shouldn't make much difference.
what's better in your opinion? FMST26 or FMSS?
Instead the plugin lets every loaded team vote with its next-match date and takes the consensus: always close, works in every save, survives patches. If the gap is bigger than a few days, your dump is just old: press F9 again.
Thanks for the explanation, that actually makes a lot of sense. I completely understand why you're using the next-match consensus instead of trying to locate the real in-game date in memory.
In my case though, the difference is sometimes more than just a few days—it's occasionally a few months behind the actual in-game date.
Also, pressing F9 behaves exactly like clicking New Data for me. It reloads the data successfully, but it doesn't bring the loaded date any closer to my current in-game date. It just reloads the same snapshot/date again.
That said, I'm really not complaining. I'm already happy that everything is working again after the recent fixes. I just thought I'd mention it in case it's useful, and maybe it's something that can become more accurate in future versions. Either way, I'm really enjoying FMSS and I'm looking forward to seeing how it continues to improve.
So far, I haven't had any issues with FMSS—fingers crossed! 🤞
I do have one question though. Why is it that when I load the data, like in this example, it always loads a date that's a little earlier than the actual in-game date I'm currently on? I've attached some screenshots to show what I mean.
First: 1.4.2 is out. It fixes the startIndex crash some of you hit, makes scans fast again (the 1.4.1 snapshot is now only an automatic retry when a live scan misses too much memory), lowers the plugin's own memory use, and adds a check-for-updates button. Problem reports now include scan telemetry automatically. @bf3metro metro this release is aimed squarely at your Win32 1450 and 17% errors: they come from Windows running low on memory with a 157k-player save loaded, which is also why a reboot helped. Update and let me know.
@Purity ty thank you, great list and clearly a lot of care went into it. I went through everything and two of your ideas are coming in the next release: a GK meta score (weights from harvestgreen22's keeper attribute retest, so measured numbers rather than invented ones) and a PA meta column with its own filter. For the other features: pull requests on GitHub are very welcome, one per feature keeps them reviewable and your credit visible.
@Panneton0 noted, and thanks for the offer to test.
DOWNLOAD!
Hi, @mavali!
I saw your message on GitHub. Unfortunately, I can’t test the new version yet because I’m at work, but I’ll install and test it as soon as I get home.
First of all, thank you for taking the time to investigate the issue so thoroughly. I really appreciated reading your explanation because it makes a lot of sense, especially considering the random behaviour I was experiencing. Sometimes it would work after a reboot, sometimes only the first scan would work, then it would suddenly fail for no apparent reason. Your explanation fits that behaviour perfectly.
It’s also clear that you didn’t just patch the symptom—you took the time to identify the root cause and improve the plugin as a whole. I really like the changes you’ve made in 1.4.2. Reducing memory pressure, improving the diagnostics, and making the scanning process more robust overall is exactly the kind of work that gives users confidence in a project.
I’m really hoping this update fixes the issue and that I won’t see those errors anymore. But even if I do, I still wanted to take a moment to thank you.
I really appreciate how much time you’ve spent investigating my reports, explaining the root cause in detail, and helping users who run into problems like mine. You’re incredibly responsive and willing to help, and that’s something I don’t take for granted. To be honest, I’ve rarely seen this level of support from a developer, not even from the Football Manager developers themselves.
I’m also really looking forward to seeing what comes next. FMSS already has a lot of potential, and seeing the amount of care and effort you put into improving it makes me genuinely excited for future versions and the new features you’ll add over time. I honestly believe FMSS has a very bright future ahead of it.
I also noticed that you accept donations. Once I’ve had the chance to test 1.4.2, I’d be more than happy to make one as a small thank-you for all the work and support you’ve provided.
Thanks again, and I’ll let you know how the testing goes!
Unfortunately I'm still getting the same error after updating to 1.4.1.
The plugin is definitely updated, but scans still fail with:
Read failed: The scan could not read 17% of FM's memory.
The save was fully loaded and I waited before starting the scan.
I checked the BepInEx log and I think I found the reason. It looks like the snapshot isn't being created successfully:
No snapshot available (MemoryCaptureSnapshot failed (Win32 1450: Insufficient system resources exist to complete the requested service)).
Falling back to live memory scan (as before v1.4.2).
So it looks like the plugin falls back to the old live scanner, and I end up with the exact same "17% of FM's memory" error as before.
I've attached the console output. Is there anything I can do to help diagnose why the snapshot creation fails with Win32 error 1450?
I have another update.
After rebooting my PC, the scan completed successfully without changing anything else.
This time the log says:
Scan reads from a frozen memory snapshot (VA clone).
and the scan completed successfully.
However, the behaviour is still very inconsistent and seems completely random.
Sometimes the snapshot creation fails with Win32 1450, causing the plugin to fall back to the live scanner, which then fails with the 17% memory error.
Other times the snapshot is created successfully and everything works perfectly.
I also noticed another pattern that might help:
Sometimes the scan doesn't work at all.
Sometimes the very first scan after launching FM works.
But after I continue playing, advance a few in-game days and try New Data again, it often fails with the memory read error.
Occasionally it works again without me changing anything.
It doesn't seem to depend on the save itself, as I'm using the exact same save and settings every time. Likewise, it doesn't seem to be tied to any specific action. The success or failure appears completely random, even under what appear to be identical conditions.
Hopefully this additional information helps narrow the issue down. Let me know if there's anything else you'd like me to test or any additional logs that would be useful.
Unfortunately I'm still getting the same error after updating to 1.4.1.
The plugin is definitely updated, but scans still fail with:
Read failed: The scan could not read 17% of FM's memory.
The save was fully loaded and I waited before starting the scan.
I checked the BepInEx log and I think I found the reason. It looks like the snapshot isn't being created successfully:
No snapshot available (MemoryCaptureSnapshot failed (Win32 1450: Insufficient system resources exist to complete the requested service)).
Falling back to live memory scan (as before v1.4.2).
So it looks like the plugin falls back to the old live scanner, and I end up with the exact same "17% of FM's memory" error as before.
I've attached the console output. Is there anything I can do to help diagnose why the snapshot creation fails with Win32 error 1450?
new bug.
The steam_appid.txt fix definitely solved the loading issue, as the plugin now loads consistently. However, I ran into a different problem afterwards. The plugin starts scanning correctly, but the scan fails because it can only read around 85–88% of FM's memory, even though the save has already finished loading. I tried again after waiting, but I still get:
"Read failed: The scan could not read 15% of FM's memory. Your existing data was kept."
new bug.
THE "FM26 IS NOT PICKING UP THE REQUEST" PROBLEM (@bf3metro and others)
Found the cause, and it is not random after all. FM26 sometimes closes and relaunches itself during startup (known FM bug, it is on SI's own tracker: https://community.sports-interactive.com/bugtracker/1644_football-manager-26-bugs-tracker/1873_crash-technical-issues/2180_advanced-access-betas-crash-technical-issues/game-crashes-during-initial-launch-via-epic-games-store-and-restarts-automatically-r26602/). When that happens, the mod loader thinks it already ran and skips the new process (known Doorstop bug: https://github.com/NeighTools/UnityDoorstop/issues/34). The FM you end up playing then has no plugin in it at all. F9 dead, New data dead, empty logs. Whether FM restarts itself varies per launch, which is why the tool can work for days and then die without you changing anything.
The fix: create a plain text file called steam_appid.txt in your FM26 folder (next to fm.exe) with exactly this in it:
3551340
That stops the self-relaunch at the source. Credit to frankintheocean, who found it after a lot of patient testing in https://github.com/mavarobli/FMSuperScout/issues/7. The current reports (https://github.com/mavarobli/FMSuperScout/issues/13) match it exactly, and it is now in the troubleshooting guide: https://github.com/mavarobli/FMSuperScout/blob/main/TROUBLESHOOTING.md
Quick check: open BepInEx\LogOutput.log in your FM folder. It is rewritten every time the mod layer actually runs. If it is from an older session than the one you just played, the plugin was not in your game.
@Lapidus good thinking, but no shifting memory addresses: the plugin simply was not in the relaunched process, so a reconnect button would have had nothing to talk to. @Wigo this may well be yours too, try the same file, otherwise the "FM will not start" section in the troubleshooting guide.
QUESTIONS AND REQUESTS
@OpticFawn honest answer: unlikely. The plugin leans on Windows-specific plumbing (BepInEx injection, reading process memory), so macOS means rewriting the whole game-side half.
@Kamas1 META_W is the weight per attribute, straight from FM-Arena's attribute testing table. The meta score is the weighted average of a player's visible attributes on the familiar 1-20 scale. Attributes with no measured positive effect are not in the table, and keepers are excluded because the testing could not measure keeper attributes. Which also answers @Panneton0: a GK meta would be an invented number next to measured ones, keepers get role ratings instead.
@Forsti37 your FM24 tool sounds impressive, hope you find a way to release it. That EULA tightrope is exactly why this one is open source, reads memory locally and never touches game files.
I am collecting all feature requests from this thread: USD currency (@johnconnerson), a meta-at-PA column in the table (@kami911, nice work, pull requests welcome), position weighting (@Panneton0), alternative hidden-attribute weightings (@GeorgeFloydOverdosed, if you have data behind your numbers, open a GitHub issue). Some of these will likely make it into an upcoming release.
Thanks to everyone who filed GitHub issues with logs attached. The steam_appid fix exists because one user kept testing until it fell over, so keep the detailed reports coming.
Thank you so much for taking the time to investigate this so thoroughly. I really appreciate the effort you put into tracking the issue down and explaining exactly what was happening.
For now, it actually seems to be working! I created the steam_appid.txt file exactly as you described, and after several launches FMSuperScout has loaded successfully every time so far. Hopefully this was indeed the root cause.
Your explanation also makes perfect sense and matches everything I had been experiencing. The behaviour was always completely random: sometimes it worked, sometimes it didn't, without me changing anything. There were even days where it suddenly started working again after previously refusing to load, which made it almost impossible to understand what was going on. Knowing that FM26 can restart itself and that Doorstop then misses the relaunched process explains that inconsistency really well.
I'll keep testing it over the next few days with multiple launches and different saves to make sure the issue is truly gone. If it happens again, I'll make sure to grab the BepInEx\LogOutput.log from the failed session before restarting FM and I'll post it here.
Thanks again for the excellent support and for taking my report seriously. I really appreciate you sticking with this until you found a likely cause. Hopefully this fix will help anyone else who runs into the same problem.
Probably, the tool needs an additional features that help to combat that issue, for example, there should be a button that you must click every time you load a new save so the tool to check and correct the memory addresses.
That's actually an interesting theory, and I think a manual reconnect/reinitialize button could definitely help.
The strange thing in my case is that it doesn't even seem related to switching saves.
The whole issue is completely random. Sometimes FMSS works perfectly, then I simply close FM26 normally, come back a few hours later (or the next day), launch exactly the same save, and it suddenly stops working.
When it happens, F9 does absolutely nothing, and clicking New Data always says:
"FM26 is not picking up the request. Is your save loaded?"
Then, after restarting FM26 a few times (or sometimes without doing anything different at all), it may suddenly start working again.
That's what makes it so frustrating. There is absolutely no pattern. I never know:
when it will work,
when it will stop working,
why it starts working again,
or whether anything I tried actually fixed it or if it was just pure luck.
I've already tried pretty much everything: reinstalling FMSS, reinstalling BepInEx, verifying the game files, deleting the FMSS AppData folder, deleting the generated files, checking Windows Defender... nothing consistently fixes it.
So I honestly don't know if it's a memory address issue, a communication issue between FMSS and the plugin, or something else entirely. Your idea could definitely be part of it though.
Symptoms:
FMSuperScout works normally for one or more sessions.
After closing FM26 and launching it again later (sometimes the next day), FMSS randomly stops working.
Pressing F9 does nothing.
Clicking New Data always shows:
"FM26 is not picking up the request. Is your save loaded?"
Sometimes it starts working again completely at random without any obvious reason.
What I've already tried:
Clean reinstall of FMSS.
Clean reinstall of BepInEx 6 (IL2CPP x64).
Verified FM26 files through Steam.
Deleted %LOCALAPPDATA%\FMSuperScout.
Deleted request.flag, dump.json, status.json.
Disabled Windows Defender Controlled Folder Access.
No antivirus besides Windows Defender.
Latest FM26, latest FMSS.
Same behavior across different saves.
BepInEx log:
BepInEx loads successfully.
The plugin is loaded:
Loading [FMSuperScout 0.1.40]
No startup errors.
Sometimes I also see:
Verlopen/onleesbaar data-verzoek genegeerd
(expired/unreadable request ignored).
Since the plugin is loaded correctly but FMSS later reports "FM26 is not picking up the request", could there be a known issue where HotkeyBehaviour or the request listener stops processing requests after restarting FM26?
If there is a debug build or additional logging I can enable, I'm happy to test it.
Thanks!