Jump to content
Sports Interactive Community

Ritari

Members
  • Content Count

    238
  • Joined

  • Last visited

Everything posted by Ritari

  1. So no FM12 for me. I DO NOT WANT TO INSTALL SOME OTHER PROGRAM THAT NEEDS TO BE RUNNING TO PLAY A GAME. Well, I can at least continue playing my current FM10 save for the next year (skipped FM11), and maybe they'll wise up for FM13.
  2. Could this be updated to FM10? The editor has changed quite a lot, and the file mentioned does not seem to exists anymore.
  3. Without the J-League FM will always be an unrealistic representation of the world of football. ____________________________________ K***s on epäoikeudenmukainen kusipää!
  4. What kind of development system are you using for this? The actual game comes with DRM that blocks debuggers from accessing the game thread. Will that be a problem for this editor?
  5. I'll post this proposition here, too. We all know that the football world is divided into two major league schedules: there's one running from the fall to the next spring and one running from spring to the next fall. Most of the leagues follow the first option, and so also most of the leagues present in the Football Manager games. This presents one problem to us players who like to simulate the football world as realistically as possible. (What I mean with this is that the starting point of the game should be as realistic as possible, since when the game progresses it no longer follows the real world.) Since most of the versions of FM are released before any of the spring-to-fall leagues have ended, there are no problems in the initial release versions. But since a data update is usually released some time after the initial release, most, if not all, of these leagues have ended for that season and their histories (competition, club, player/staff) have been entered into the database. Also real life promotions/relegations have been taken into account. This means that the updated database is up-to-date with the real life situation at the end of the calendar year (or close enough). Therefore, it is no longer up-to-date with the situation when the game starts in the previous summer. I, and many more I would suspect, always start the game from a date in the summer of the release year, even if I plan on managing a team from a spring-to-fall league. This then means that with an updated database I would have after the first (half) season duplicate histories in the game. And of course, would have played with the wrong teams in the divisions in the first place. Previously, I've always either not installed the data update at all or if I have then manually corrected all these things in the updated database. I would very much like to use an updated database, because it features so many good things like the removal of duplicate players/staff, corrected player/staff information and so on. But at the same time, it is very tedious work to have to check every spring-to-fall league's teams and remove their latest season's histories and correct the promoted/relegated teams back to the previous season situation. Finally I get to the point and the actual proposition after this rather long background elaboration. I've finally come up with an idea on how to fix this so that everybody would be happy (except maybe the coders). What if there was a possibility to choose which season's histories/starting teams promotion/relegationwize you would want in a new game? There could be a tick box during the creation of a new game which would tell whether the game should use the latest histories/teams in these spring-to-fall leagues (ticked) or not (unticked). Then there would have to be something in the database entries that the game would check if that tick box is ticked. This would mean that all history entries for the latest season would have its own tick box to make the database understand that this season entry is optional (i.e. if the db is ticked then the entry is used, if not then not). The only problem left is how to deal with the promotions/relegations in the database. I have not yet figured an easy solution for that using just the database. Maybe the simplest option would be an .edt file style solution. That way the database wouldn't have to be changed in that regard at all, but there would only be another .edt file to be used for that. If these were to be implemented into the database and the game code, us realist-till-I-die players would have the option to choose to use the latest database but still preserve the real life situation at game start. Not to mention save our time on having to edit the database ourselves. How does this sound, SI? Is it doable? Or is just too much work for a tiny group of players' benefit?
×
×
  • Create New...