forameuss

I think I picked the wrong guy, was there someone else in that list at Southampton? Broja definitely not it, like you say. Core point still stands though. I think the "in vogue" way of developing youth for the biggest (read, richest) clubs is just to let better facilities do it, then buy them when they're a surer thing. Bit of a miserable state of affairs.

Several of them didn't begin their careers with Chelsea and were brought in later. Musiala and Broja were Southampton, Gilmour was Rangers. Several others were brought into Chelsea having been with other clubs at a younger age. In FM terms, they'd likely be a product of Chelsea, but in reality, not really. Which is what a lot of clubs with cash do. Let proper youth academies do their work, keep your ears open, and chuck obscene amounts of money at the clubs so you can bring them in and "finish" them. And by finish, I mean mostly chuck them out on loan until you're eventually bored, then sell them, since that's what happens most of the time. And given it's the post you replied to, are any of those players going to fall into the 1% I mentioned? Musiala likely, but the rest of them seem like a smattering of Premier League stars, and most will just end up being your standard level player, and will have likely come into the youth academy with hundreds of others who were absolute jobbers. Which is the point. That's pretty much exactly what the game currently produces, mostly producing "3 star" players that will go on to be solid options at a certain level.

And with that, I'm going to say that we have a v1.0. I've updated the second post with the details, so have a read there for further details. In case I didn't stress it enough elsewhere, please be aware that this is very much an early version and I don't expect that it'll be fully working for everyone. If you see anything obviously wrong, or just have some suggestions for how it could be better, feel free to fire them over to the email I've added to the footer. I'll be gathering everything and looking to fix any problems as soon as possible, and start on the many new features I'm planning on adding.

I believe that stuff is contained within league rules, so currently no. It is on the list for the next couple of versions though to at least experiment on what can be done with the basic rules. Aha, on looking into it, I was only mirroring what the editor allowed within reason. On the base you can't create local regions for some reason, so I couldn't create them to get all the ids I'd need to get it working (or at least didn't try). However with the new editor skin that unlocks a lot of stuff, looks like I can now add. I'll probably get it in for the next version EDIT: Actually, looked into it in more detail, and looks like it would have worked anyway. I moved away from a certain way of doing the objects a while back that put a big divider between things you could add and things you couldn't. Just checked, and if you add to the spreadsheet, it'll add it in the editor. The only bit that's missing is the cities for each region, as those completely slipped through. I'll get them on the list to add for the next version

Yup. Not got it in front of me so may be a few differences, but there's definitely a field for CA/PA. For positions, you have a separate field for every position as listed in the editor with 1-20. You also have the field where you can add the role you want the player to have attributes filled out for if you don't provide specific attributes yourself. The players I created I wanted them to have specific obvious traits to them, like the hyper-aggressive central midfielder, the forward that's about 8 feet tall, his tiny strike partner. Each of those players have specific attributes filled in with either extremely high or extremely low values, then you provide a role that the game can fill the rest of the attributes in for.

I would imagine so, for now. It certainly hasn't been tested on anything else, and I'd imagine some of the path stuff maybe isn't as flexible as it could be. Certainly one for the future if people really want it. Yup, there's support for adding a home, away and third kit for all clubs and nations. There's still the issue in the editor itself that you can't see the kits, but the changes themselves work in-game. I believe that's one of the ones you can't add and only modify existing ones. I'd need to check for sure, but almost certain that's the case. Although that's purely because the Add option is greyed out - maybe there's a way to mod the editor to be able to add? Not sure. That's already there on the Club object I believe.

Are you going to provide screenshots of all the times it didn't happen too? And that's not some snide gotcha or anything, if you're trying to prove something, you'd really need to provide a rundown of all your draws and show that an abnormally high percentage of them were doing that. You could show 20 times it happened, but that's a lot more notable if it's 20/20 than if it's 20/100.

I look forward to you pointing out the thing is an absolute turd in the first five minutes then! That would almost certainly be very helpful. Testing is a real skill.

And furthermore, I'd imagine that if you had a view over every youth player that "graduated" at a club when they were 15, 90% of them would be jobbers who would never amount to anything and be working "proper jobs" by the time they reach adulthood. 6% probably eke out a decent living playing football, although at a much lower level. 3% "make it big" at a big club. Less than 1% probably go on to be considered world class, and probably once or twice in a generation do you get the sort of talent that people believe should be getting churned out of youth academies in FM as soon as you hit 20 on facilities.

One more slight update, I've been working to try and identify as much stuff as I can see is currently wrong with it, and the stuff I really want to add, and I've sectioned off what I want to do before initial release, and good news is there's only a couple of things. I've managed to get it packaged up which was a big hurdle, so shouldn't be too much longer before version one. I'll keep you all posted

Absolutely. You could manually put all those names in, or, if you fancy mucking about a bit in Excel, I'd imagine you could just pull the nickname field of your club through into the stadium field and do it that way.

Do some people really want the quality of youth to just be some function of three numbers with the biggest number always producing once-in-a-generation style players? Not only would that be highly unrealistic, wouldn't it also make the game pretty tedious? Thousands of clubs in the game, but nah, let's just make sure only the top ones produce anything because big number is big.

Ah, if nothing is added or deleted, then I don't think there should be any issues, but I wouldn't want to say absolutely for sure. Definitely one that would require testing.

That's a very good question actually. So the short answer, I'm not really sure to be honest. The app is currently assuming (with the way the IDs start) that there have been no changes to the database, and I've yet to try it with any other editor files. However, there is the Merge Editor Data option in the editor, which I assume realigns all the IDs so they're not clashing, so perhaps it would work. Someone with more experience of that side of things would have to opine.

Devil's advocate though, if every player in the database gets capped at 130PA, doesn't 130 become the new 200? Obviously players won't look quite as good attributes wise, but it becomes just a different scale. Or is there more to it because there are things tied to the ability like reputation etc?

I've added a section on the second post about current status of the project. Last night I delved into the packaging up of the project, and then went down a rabbit hole related to that. Still a few things to iron out, so hopefully get some time on that later. Once I've achieved that, I'll take a call on whether there's anything else I'd like to fix first, but I suspect it'll be good enough to distribute at that point to let people have a play around with it if they're interested

Oh don't worry, it isn't an "unable", I just hadn't really gotten around to it. The initial edit I wanted to try didn't really have any need for it as it built on the existing Scottish system. My next one will need pretty much everything created, so I'd planned to flesh things out then. So taking those in turn, team league and cup histories is something I added recently. Might not be absolutely perfect yet, but it's pretty much there. It's not quite as swish as I wanted it to be because of the way the XML is structured, but you can remove specific rows and add ones to replace it (I've "inserted" my made-up club into the Scottish Premiership history to win a few trophies) or just clear everything that's there and start again. Referees, like I said, shouldn't be too difficult. I expect they'll just have a few extra fields that other Person objects don't have, then share the rest. Shouldn't be too bad. Players adding in bulk is pretty much one of the main reasons why I did it, so that's good. You can edit existing objects fairly easily too, just add the unique name of the object (usually just the name although that might change) change one field to tell it you're dealing with an existing object, then update the fields you want to change. I used it to change the competition of a couple of clubs so I could replace them with my new ones. That's quite interesting actually, I didn't know you could do that. I don't think I necessarily need to (although it would be cleaner, certainly) but the range of unique IDs that the editor uses has been a main source of pain in the project. I think there's 4 for most objects, the "long" db_unique_id it mostly uses, the sequential 200******* one, the db_random_id (which the editor uses, but doesn't seem necessary) and the short db id (which again doesn't seem to be needed). I've recently dragged most objects in by parsing the XML you can export from the editor. If you change the name of an object, that will generate one XML entry. Turn that into the dictionary in Python, parse out the unique_id and the old value of the name, and you have what you need. To be fair, that was more a flippant comment than anything. Really, the "why bother" question is really a matter of preference. Like I've said, my initial edit really didn't need the vast majority of fields. I think I've probably touched maybe 20-30% of them. But my plan for this is to try and avoid just providing something that does this narrow amount of functionality and try and cover all the bases so that any kind of edit is possible. Lofty goals probably.

None of that means anything with regards to how easy it is to fix in software development terms. You can wholesale refactor the entire code base with little issue, or you can change one value and a linked module completely breaks. No-one can possibly say how easy something is to fix unless they're sitting there looking at the code, and even if you are it's incredibly difficult to accurately tell. What we do have a window into is what we can see. It hasn't been fixed yet, despite them taking an unprecedented (for SI at least) step of specifically calling out fixes and giving a vague timescale. If it was that easy, they'd have fixed it by now. And because there'll be plenty of people shrieking and claiming shill or whatever, the existence of any issue in the first place reflects badly on SI. Giving them the benefit of the doubt and saying something is difficult in a system that's near enough decades old in parts is not remotely defending them.

Current Project Status v1.1 - Yarrow now released, see this post for details v1.0 - IT'S HERE! Well, kind of. Bear with me, as this initial release is likely to be a little rough while I iron out some of the kinks. Please read below for an updated user guide of sorts, and any notes about any features or limitations. I'm going to try initially hosting the exe file on a shared Dropbox folder, so if you're interested in giving the tool a go, drop me a PM and I'll reply with the share link. I *think* at that point you can just download that file locally, then you're good to go. v0.1 - Working on packaging up the code into a working executable that can be distributed. Once that's achieved, there should be some kind of "release" to anyone that's interested Buymeacoffee Link Honestly, I feel a bit dirty putting this in, but thought I may as well. I am in no way expecting anything from this, but I'm really enjoying working on this, and have a long list of things I'm interested in adding to it. If during this process you feel like you're getting use out of it and you want to contribute a few pennies, it would all be much appreciated. https://www.buymeacoffee.com/fmautoedit User Guide First, download the exe from the provided Dropbox link. I advise saving it to its own folder, and then creating input, output and database folders alongside it in an easy to find location. On opening the exe, you'll see the below screen First, select your input, output and database folders that you created one-by-one using the Browse components above. This will tell the tool where to save everything to. Once that's set, you can enter your desired project name in the Active Project field, and click Check. If you're starting a completely new project, you'll see the red text below, telling you that it's new. If you're wanting to work on an existing project that you've already gone through this process with, you can perform the same process, but you'll see green text. Once you have your desired project name, whether new or existing, click Load and you'll see a popup like below. This will point you to where your input spreadsheet is, and where you add your edits. Follow the notes below for how to edit the spreadsheet, but this is likely something just to have a play around with for now. I'll probably not cover everything I should say and forget some bits, but some notes I can remember off the top of my head The names database for people only has names for Scotland, USA, Italy, Northern Ireland, Republic of Ireland, Wales, Russia, England, Spain and France. If you try to use the RANDOM keyword for any names in a nation outwith this list, the field will go red. If you go ahead with that edit, the tool will likely crash when you generate a file, or at best create a player called RANDOM RANDOM. Adding a whole nations names is a long process, but I do intend to get some better coverage of this in future versions Any field that is an Object type has no validation on it in the spreadsheet. So say you want to make sure that a City's Nation is Scotland, but you constantly type Scoland because your t key is broken. The spreadsheet will accept this, but the tool will throw an exception later on telling you that it can't find the object. This is something that will be improved later on Please note that every object type has a "Guide Row" at the top. This gives you the type of the column (if it's a standard one like String, Number, Object or whatever) or the dropdown menu if it's a dropdown in the editor. In these cases, make sure you either fill down the value to the row you're editing, or copy the entire cell. This will keep using the dropdown and make sure whatever entry you put in doesn't crash the system. Dates are of the format DD|MM|YYYY, and need to be in that format. This may improve in future to make it a bit more flexible for different formats Colours need to be of the format R|G|B (so like 255|255|255 for white). Again, I've got it noted down in future to make colour choosing a bit more obvious for people that don't want to deal with meaningless RGB numbers all the time I can't see anything else obvious, but I expect there are some other niggles I've forgotten. Important thing is to get a lot of eyes on it to notice any of the snags, then I'll get working on getting those sorted Once your spreadsheet is completed, you're ready to generate your project file. Return to the tool and you'll see this screen. The three "Open *" buttons are pretty self-explanatory (although for some reason it just navigates to the folder rather than opens it, annoyingly). The one you really care about is Generate Project File. When you click that, you'll get a popup warning you that it may be a long-running operation, but that's safe to click through. You'll see a (janky) spinner while it loads, and see the logging ticking away in the background. None of the log messages are particularly important, but it will give you a running tally of what objects have been added. Once it is complete, you can go to your output folder, and your XML will have (hopefully) been created. Use the steps in the Examples below to load it into the editor and inspect the results. Examples (slightly out of date) As a fairly basic example, we'll create a fictional club (Somewhereshire United) from a fictional city (Somewhereshire) with a squad of 23 players. The steps we'd go through for that are as follows Open the FMAE program and create your project with a meaningful name. Enter the name into Active Project, click Load, and then click Create Project. This will create a config file to point to the correct locations, as well as an Excel file that you can start to populate Open the spreadsheet, and find the template for each object. For things in the editor that have a dropdown to select your value, the excel will have a dropdown too to make sure you can't select something that won't work. Start with creating the city. For any existing objects, you can just type the name and the back-end will link up the IDs as long as they're spelled right. Then create the club. You can add your new City into that field, as when the editor file is created, it knows which IDs to use Then create your players. I've put the bare minimum of data in there just to get working, but it gives you an idea. As you can see, RANDOM has been used for names, so the code will check the nationality and pick a random name from all the current names in the db with English nationality. Please note, these names only cover a few nationalities currently, but more will be added. I think all UK nationalities are there, along with the US, Italian, and maybe a few others. The date of birth is also semi-random. You input an age, and it'll pick a random value during the year that would make that true based on the current date. It was really, really tedious putting in random dates manually, after all. Finally, worth noting the CityOfBirth field. Every city currently in the database is supported, but if you make a spelling mistake, the process won't work (that will be improved). There's a few edge cases for when there are multiple objects with the same name. For example, there is more than one stadium named Wembley in the world. In those cases, you're kind of stuck, so that's an improvement that also needs to be made. From here, you've got enough data to generate the file. Load in your project, click Generate Project File, and it'll go and churn through your data. Once that's complete, you can find your XML file, a sample of which is shown below. You can then import that XML into the Editor itself and make sure all your changes went through OK. You can also see the names that have been chosen. Please note, because of the way the random works, if you regenerate the file, the names will change I think. So if you want to keep Trovarn Bamborough (because why wouldn't you? Brilliant name) then you could go back to your spreadsheet and change the random to the fixed name. And that's it really! Feature List The below is a non-exhaustive list of everything the system currently does. Projects can be separated out with different config files and input spreadsheets, should just be a one-click thing rather than needing much work on user side Objects that can be created and/or amended Agreement Award City Club Club League History Competition Competition History Derby Injury Language Media Source Person (Player and Non-player) Person history Person plans Stadium Stage Name Weather Objects that can be amended but not created Continent Nation

Please Note: This post will be pretty bare at the moment, but once I'm not at work I'll add some screenshots and examples to show what I'm talking about I've mentioned it in passing, but I think I finally don't hate my current project enough to actually reveal it and hopefully get it into the sort of state where someone might find it useful. The Background In FM terms, I often have grandiose ideas of things that could change. I like odd leagues with different structures, but there aren't enough of them anymore, so I've always had interest in changing things to make some. Unfortunately, as you'll all know, the editor is...well, it's pretty awful. Incredibly powerful, but often ugly, uncooperative and just generally pretty rough. The thought of doing a large-scale edit using solely the editor seems like a daunting task, if it's even possible at all with my limited attention span. So a few years ago I wanted to try and do something that could make that whole process easier, and give me a chance to actually put my plans into action. Or, at the very least, get those plans to a point where they can be realised, then lose interest, and move on. The first iteration was pretty awful. So much so that it never really came close to being finished. I still have some of the early input spreadsheets, but they're hideous, and I'm not even sure they did anything. So that was abandoned until about 6 months ago when I decided to start again from scratch, with a (slightly) more experienced head on. The main aim of the project is to allow much larger edits to be built up extremely quickly. So say you want to create a new league from scratch, including slightly custom players for each club, that would not only take a huge amount of time in the editor to create the objects (or clone and adjust existing ones) but as the edit gets larger mistakes aren't too obvious to spot. With this, the idea is that you can see all your data at a glance, and creating a new object is basically a matter of adding a row. 1 competition, 10 clubs, 30 players for each, that can be created in full fairly quickly on a spreadsheet and then translated into something the editor can understand. That's the idea. The Implementation I won't go into too many specifics unless people want them, but in FM tradition, basically it's a combination of a very structured spreadsheet alongside some background code, in this case in Python. The vast majority of the work from a user perspective goes into the spreadsheet, which is where you'll be setting out your data. There is a column for most data points for every object you can create in the database, as well as some you can just update like Nations. I've not covered absolutely everything in the editor, as some of the objects have absolutely insane levels of detail that you won't need for most edits. They may be added in future. The spreadsheet has been designed in such a way that you can make use of everything Excel offers to make data entry easier. You don't need to give each individual player a name, for example, you can ask it to do it randomly, and it'll pick a nationality-appropriate name. You can use Excel formulas if you really want to and it makes it easier, the code will pick up whatever the value is and add it to the object. Once your spreadsheet is spick and span, there will be a very simple Python interface where you can click a button, and it'll spit out an XML with all of your data in it. That can then be imported into the editor, saved as an FMF and used in-game. I think I'm clocking an edit with around 2500 distinct changes (not huge, but sizeable) taking about 30 seconds to generate, which is positively lightning compared to early versions. And the way it's looking, it doesn't seem like adding loads more changes will affect things too badly, but unknown at this point. (Current) Limitations This could be a big section... As I mentioned earlier, there are a fair few data points in the editor that don't appear in this. Usually this is because I simply didn't feel like I needed them, but that was down to the specific edit I was doing. There's a few that are on the list to add, and I suspect there's a lot that people would be interested in having if this ends up being "released" in some way. The spreadsheet could do with a few more functions to help people populate data. Maybe some macros that would populate a basic player and let you fine-tune, maybe more fields allowing random input to stop needing to populate everything manually I can't add referees yet. Because why wouldn't you want that? Also can't add a few other person types, just strictly Players or strictly Non Players. Could add more. This is strictly just for data changes currently. Competition rules are not covered. Future Plans Well, this is the big question. This project was started as largely a personal one, and as a result it's a bit of a mess. But if people would be interested in having this to play with, I'm not too many steps away from it being able to be packaged and distributed. So that's a tentative aim. I'm definitely going to investigate whether I could get Basic Competition Rules working using the spreadsheet. Advanced Rules...no chance, I'd imagine, but basic rules might not be too bad. It depends what the XML looks like. Ideally cover every editor field in the spreadsheet and leave no gaps as to what data can be represented. Some of these are conditional on others being present, so there may be some omissions, but I'd like to get near-perfect coverage If there is interest, it would be good to know what people would like in a system like this to see if that's possible and make it even more useful

Care to outline exactly why you believe it would be "very fixable"? And in that case, why haven't they just done that?

It's almost like certain features are a lot easier and quicker to develop than rebalancing AI interactions in a complex system. Whodathunkit? Have they been an issue for ages? Absolutely. It's part of the biggest problem the series has had for the past few years. But that doesn't make them any easier to fix. In fact, it makes it quite the opposite.

Opening up a proper beta probably requires a good number of users to properly beta test to make it worthwhile. And properly beta testing isn't going to be something that a lot of people are particularly interested in doing, because it's often tedious. It's not really just playing normally and chucking up a few bug reports when you find them, in fact it's often not really playing at all. Otherwise they can just lean on people raising issues with the retail copy. They've tried it before, they shuttered it, I can only assume they don't see it as worth the effort. Hard to argue given one side has the numbers on it.

Banned forever as currently there is no end date announced. Once there is, I expect it'll be updated as such.

I've deleted all players previously in an attempt to get a true made-up database for players, rather than just renaming the existing ones. I think from memory it led to some weird balancing issues, but it wasn't too bad. Obviously those kinds of issues don't really matter if you're creating a completely new system. Unfortunately I don't think there's really a way around the performance issues. I do think that the 24 editor is a lot better with bulk operations than 23 was. It used to take near 10 minutes to bulk edit around 50k objects, now it's a hell of a lot quicker. Not sure whether deletes take longer, not something I've tried yet. One thing that might cause issues with that is any hard-coding that SI have done in the background. There's a lot of sticking-plaster stuff to get all the functions in the game working, and a lot of them are probably going to assume that certain objects are present. It might be smarter than that, but I'd be wary. Unfortunately for us, I think this kind of stuff will come under the "unrealistic input = unrealistic output" situation where SI are concerned