EHM The Blue Line

tommiejohansson wrote:

archibalduk wrote:I'm afraid I cannot tell you off-hand exactly what the syntax is for the extra_config.cfg file but you could try downloading some of our older rosters to see if those extra_config files contain examples.

Although you might be able to edit affiliations within the game, you're not going to be able to use the extra_config to change a team's name or location AFAIK.

Ok, maybe it is better to just change the team to the Winnipeg Jets from the start-date.
After all it is just 4 years from that date to the irl-date.

I did just want it to change name in 2011 because of the reality-feeling. But it is not so long time.
So i guess i could live with it!

nino33 wrote:Changes you make to a database/Extra Config File only take effect whe starting a new game (so you can't change anything on a game already started, even if your changes are "in the future").

The Extra Config File was initially the only way to make some changes until the Pre-Game Editor was created....I think the things you're refering to (changing affiliations and team colours) are so much easier to do in the Editor no one uses the Extra Config File to do so

In regards to "what to do".....there is nothing you can do to change the Jets to the Thrashers in a game you've already started, but you could use the most recent version of the Lidas/Manimal rosters (which I believe have the Jets replacing the Thrashers)

Regards

For the first, i know that it has to be a new game to be done. Thats why i am making it in the pre-game editor and in the extra config.

Sorry for super long quote..
But it is actually possible to swap teams between leagues, renaming teams and even creating new teams and comps in saved game.. you name it. It is pretty similar progress than editing pre-game data.

Lazion wrote:it is actually possible to swap teams between leagues, renaming teams and even creating new teams and comps in saved game.. you name it. It is pretty similar progress than editing pre-game data.

Very interesting! How? I’m guessing not via the SavedGame Editor…
I think this is the first post I’ve ever seen indicating changes can be made to an EHM saved game (beyond those already possible with the SavedGame Editor)


My own desires are more about start-up - I would love to be able to reduce the number of teams in playable leagues in EHM…but the task seems overwhelming. It only seems possible via hex editing, and there’s no tutorial available – I’d need step-by-step instructions with accompanying screenshots! Hobbit13 helped me with unretiring some numbers in the 1974 database ages ago, and I was only able to do so by following his step-by-step instructions and accompanying screenshots.

I really would love to reduce league size in the 1974 database…for example, the WHL/OHL/QMJHL have 25 more teams in EHM than they did IRL 1974! The Russian Elite League only had 10 teams IRL 1974! There were only 41 minor-pro teams in NA IRL 1974, but the AHL/ECHL/CHL/etc in EHM07 gives me dozens more teams then I need!


Do you (or anyone else) know if the non-playable leagues have any editing restrictions? Can I edit League names? Can I delete teams? Can I delete entire leagues?


Regards

^ Hex editing Saved game file.
I can post small quide for swapping teams between leagues. I haven't looked into saved game file before and noticed that all those temporary files are stored in exact same format in saved game file than what those are in temp folder, which makes editing temp files little more easier.

You can delete leagues and teams, but there are restrictions for few non-playable leagues and teams which you cant delete without making game to crash.

That sounds great!

I'd be very interested to hear what you have found in the saved game. I'm very interested in writing something that exports stats from saved games. However the problem I've always had is trying to figure out the data structure (as SI keep the saved game format a secret).

Btw Nino - It's worth pointing out that any saved game editing can only be done if you have disabled the "Save Compressed" option in game. If the saved game is compressed then you won't be able to edit it.

From what I have seen saved game data structure doesn't vary that much from pre-game format.
When opening saved game file in hex-editor you can see order of the structure. In this case it goes like this: continent.dat, officials.dat first_names.dat etc.
Only problem is to easily find where one data file starts and where it ends.
EDIT It actually uses exactly same format what pre-game http://www.ehmtheblueline.com/forums/vi ... =88&t=8381

Swapping teams between leagues is simple.
First search from top to bottom full team name. E.g. Harvard Crimson
http://oi45.tinypic.com/dfgkuu.jpg

Roll list up until you can see next team name (St. Lawrence Saints).
Flood down from beginning of Saints abbreviation lenght of 78 (hex)
http://oi46.tinypic.com/2r6pqnm.jpg

From there on you can see nation and league ID for Harvard Crimson. CE 00 00 00 is nation ID and 16 00 00 00 16 00 00 00 16 00 00 00 is league/division ID's.
Now if I want to defunct this team I replace nation and league ID's with line of FF FF FF FF x4 and if I want to change Crimson's league I just replace current ID's with wanted league ID's.
You can find league ID's from club_comp.dat pre-game database folder or from saved game file by searching league name and flooding length of 18 (Hex) up from wanted league abbreviation. In this case I have done it for Hockey East.. League ID is 0C 00 00 00
http://oi50.tinypic.com/2cd7nlf.jpg

For teams in playable leagues this can only be done after season is over in end of Juny before first ingame updates. Otherwise game will crash.
And if you are removing teams from playable league remember to add same amount of teams so league size doesn't change. You can remove and add as many teams you want in non-playable leagues.
I haven't tested this that much yet, so if you are defuncting team you probably have to clear team roster before. In my test all players went to UFA list but in second test they played in unknown league in defuncted team.
There's lot of more stuff where I can guide to when I find more time.

Interesting - keep it going

Alessandro wrote:Interesting

Agreed! Thanks for posting Lazion!

I thought I'd split this thread off for discussing the saved game structure.

I taking a quick look at the .sav file to see how things are laid out. It looks like it starts with what is basically an index. I think the first 12 bytes are unrelated to the index. So the index actually starts at the 17th byte. Each index record seems to be 268 bytes long. I not sure what the first 4 bytes of each index record is, but the next 4 bytes is the size of the file and then the remaining 260 bytes seems to be the file name. So from this, it should be possible to navigate through the whole .sav file.

I'm not 100% certain on the location of the first file index (i.e. whether it is the first 12 bytes that are ignored). I might be 4 bytes out. The Index.dat file in the database has an initial 8 bytes which are ignored. I'm just wondering whether it's the same for the .sav file. I'm also not entirely sure about the length of each record. The fact that the file name appears to be 260 bytes isn't consistent with the DB data structure.

This screenshot shows what I mean (this is taken from the very beginning of the .sav file):



The white bit at the very beginning of the file is the 12 bytes that seem to be garbage.

The red section shows the first record. I'm not sure what the first 4 bytes is (EC 15 04 00), but the next 4 bytes is the file size (9E 01 00 00). The rest of the record is the file name (i.e. continent.dat). As with the DB, the bytes are swapped and so the file size I mentioned (9E 01 00 00) is actually 00 00 01 9E. If you convert this hex number to a decimal/normal number, you get 414. The size of the continent.dat file in the DB I used to create the game is 414 bytes.

The blue section shows the next record.

^This finding is very helpful.
I have been tracking some .dat files from saved game and with this knowledge I can finally find those pretty easily.

Lazion wrote:^This finding is very helpful.
I have been tracking some .dat files from saved game and with this knowledge I can finally find those pretty easily.

I've been using the Blank Database to experiment with the saved game because I think it will be easier to figure things out with fewer staff and player data.

Something I noticed is that some of the DB .dat files are a different size in the .sav file. For example, in my previous screenshot, the first_names.dat file (the 3rd record in the screenshot - just after the blue highlighted record) has a file size listed as 582,360 bytes (D2 E2 08 00 which is of course 00 08 E2 D2 when you un-reverse it) whereas the first_names.dat file in the original database file I used to start the new game is 581,400. The data structure for first_names.dat is 51 + 4 + 4 + 1 = 60 bytes per record. So it looks like that the game added 16 new records to the version of first_names.dat stored in the .sav game: 582,360 - 581,400 = 960 bytes. 960 bytes / 60 bytes per record = 16 records.

Assuming I have correctly identified the length of those initial index records, I should be able to write a simple tool which loads any .sav file and creates a list of how long each file is and where to find it in the .sav...

Laz - I have made some more progress in figuring out the .sav file structure. The first 8 bytes of the file seem to be garbage and don't vary from game to game. I'm guessing this might indicate something like the game version (i.e. 3.0.4). IIRC in previous versions of Championship Manager (the prequel to Football Manager), sometimes a game patch upgrade wasn't compatible with pre-patch games. I guess this is a way of implementing this. For example, let's say you create a game using Championship Manager v2.0.0. Then you install the v2.1.0 (and let's pretend that v2.1.0 isn't compatible with saved games created under v2.0.0). Including the game version info in the saved game is a way of checking for compatibility. Also, v3.0.3 of EHM introduced some additional data fields to one or two of the .dat files and so I'm guessing EHM needs to know which data structure is used by the saved game.

Anyway, the garbage bit isn't important. What's important are the 4 bytes that follow. This tells you how many sub-files are contained in the .sav file. If you take a look at the screenshot I posted yesterday, you will see 4 bytes in the white section just prior to the red section. In the screenshot the value is 65 00 00 00. As always with EHM, you have to reverse the bytes, so it is actually 00 00 00 65. This translates to the decimal value 101. Sure enough, there are 101 file names listed in the index section of the .sav file. I have double-checked my theory with another .sav file I have and it works (the number of sub-files seems to vary by saved game - I guess it depends on what competitions are taking place in-game, how many seasons you have played and how many leagues you have loaded).

In the screenshot above, you will see that continents.dat is the first file listed in the index. The actual files are located further down in the file in the same order as listed in the index (but we already know this). There seems to be a gap between the final file name listed in the index and the beginning of the actual continents.dat file. I don't know what this is, but it seems to vary in size between .sav files.

I have written a tool which reads the index of the .sav file and saves the information to a csv file. It also calculates where exactly in the .sav file each sub-file is located. The problem is the unknown gap which varies in size from .sav to .sav. So the tool is always a bit inaccurate. If I can figure out how to calculate the size of this gap, the tool will be 100% reliable.

EDIT: It seems continents.dat is always found at 000416EC regardless of the size of the file. This might mean the gap before continents.dat is just a buffer to ensure that continents.dat is always located at the same place in the file after the initial index...

Figured it out! Continent.dat is always located in the same place in the .sav file.

Download this file: http://sdrv.ms/TSaM9s (note that you may also have to install the MS VC++ 2012 Redistributable). Unfortunately it is only compatible with Windows Vista and 7 at the moment.

Put the attached exe file in the same folder as your EHM saved game. Rename the saved game to save.sav. Load the exe file and it will create a sav_index.csv file which lists all of the sub-files in the .sav file. It also lists the location of every sub-file. Note that the first byte in the .sav file is 0 - so that's why the location might be one less than what you'd expect.

Wow, great job!
I'm going to test this out tomorrow. I'm keen see what effects some of .dat files have in game which are not editable in pre-game data.

I forgot to mention: The Start and End columns in the csv can be converted to hex in order to find out the offset location. For example, the Start for continent.dat is 268012. If you convert this number to hex using Google or this site you will see it is 416EC. If you go to offset 0x00416EC you will find the first byte of continent.dat in the saved game. If I find a spare 5 minutes today, I'll add two columns to the csv which list all of the Start and End locations in hex.

Btw, fog.dat is an interesting one. It's only 1 byte in size. My guess it that you can turn fog of war on or off by setting it to 1 or 0.

archibalduk wrote:Btw, fog.dat is an interesting one. It's only 1 byte in size. My guess it that you can turn fog of war on or off by setting it to 1 or 0.

Really? I have a lot of longer list in fog.dat.

Tool works like a charm.

I looked at draft_manager.dat and I can say that it only have cosmetic effect. You can change type, date and locations for drafts, but changed date only shows up in news. Draft is still held in default date and draft type didn't have any much of effect either.

Also I have played around with 'league'.tmp files trying to add more teams in standings screen without luck. I usually get arena.cpp and comp_history.cpp errors when loading game. I figured few new values from league.tmp tho.. nothing major.

Lazion wrote:

archibalduk wrote:Btw, fog.dat is an interesting one. It's only 1 byte in size. My guess it that you can turn fog of war on or off by setting it to 1 or 0.

Really? I have a lot of longer list in fog.dat.

Ah perhaps it's because I am using a small DB (only 7 players/staff in the DB) and also because I have not simmed through any days.

I'm going to keep working on the tool. I think I should be able to write something to export the player stats - if the stats are located where I think they are...

Btw, do you have any idea what the first 4 bytes of each index entry are? I haven't been able to figure that one out.

Here is version 0.0.2: http://sdrv.ms/13sZoDS

The only difference you will see in this version is that the csv file now shows the start and end locations of each sub-file as a hex offset. Hopefully this will make things easier because you can enter these offsets into your hex editor to get the sub-file.

A major internal difference with this file is that I've re-written the file from scratch. The first one was very rough and ready - this one has a proper internal structure and so it will be easy to add new modules/features to it.

archibalduk wrote:Ah perhaps it's because I am using a small DB (only 7 players/staff in the DB) and also because I have not simmed through any days.

Same here, blank DB, minimum size and no simming. It's 19,425 bytes long according to sav_index. There are some game generated youngsters in save tho.

archibalduk wrote:Btw, do you have any idea what the first 4 bytes of each index entry are? I haven't been able to figure that one out.

No idea, but I can take a look at those.

I've been working a little more on the saved game and have started working on the ability to process the various sub-files. So far, it can read the first_names.dat and second_names.dat sub-files. This isn't much right now, but once I have got the staff data read in, it'll be able to cross-reference the names with the staff data. This will then lead to the possibility of exporting spreadsheets of attributes, contract data, player stats, etc from the saved game.

Just by way of full disclosure: I found that the final 16 records in first_names.dat and second_names.dat are spaces for the user GM names. If you only add one GM to the game, you'll find 15 blank entries right at the end of each name sub-file.

Assuming I can read the player attributes into my tool successfully (I think this will be very easy - but I don't want to tempt fate right now), there is a very real potential here to fix the player regen issue. There is no reason why I cannot randomise the PAs of regens stored in a saved game. We can also randomise all of the other attributes a regen shares with the original retired player (e.g. position, shooting hand, height, weight, etc). Obviously we don't want purely random PAs, but we could weight things or adjust things slightly. So maybe that Hasek regen could end up with a much lower PA than usual - and with a different height/weight and maybe even a different stick side...

EDIT: Or perhaps rather than randomising PA, we could randomise player positions. So a Hasek regen might end up playing centre instead. Once you add into the mix the possibility of different heights and weights, maybe that's sufficient to defeat the regen bug (perhaps some of those mental/physical attributes which pass from retired player to regen might also need some randomising).

Lazion wrote:

archibalduk wrote:Btw, do you have any idea what the first 4 bytes of each index entry are? I haven't been able to figure that one out.

No idea, but I can take a look at those.

I have figured it out. It is the location of the subfile. For example, the entry for continent.dat is 268012. Sure enough, the first byte of continent.dat is located at 268012.

I've loaded in all of the club, competition and player/non-player data. I haven't tried exporting it to csv yet to double-check - that's my next task. Assuming it works, making a player regen fix of some sorts will be very straightforward.

Getting hold of the player stats seems a little harder. There seem to be two sub-files: player_stats_hist.tmp and staff history.tmp. To test it out, I deleted from the Blank DB all player career history and added just one record (for the 1932/33 season so that it easier to find this number in the .sav file) for the single player in the DB. From what I can tell, player_stats_hist.tmp is 166 bytes per record and staff history.tmp is 52 bytes per record. Some of the entries in each of those files relate to dates (the player_stats_hist.tmp includes a figure that is 1932 but the other numbers don't seem to relate to the player career history entry I added to the DB before starting the game). I don't know what the staff history.tmp sub-file contains, but there seem to be several entries (maybe about 40) even though I haven't simmed any games and there is only one player career history entry. The other unusual thing is that it is hard to find any part of those two sub-files that store a staff ID number (but I haven't checked all that closely yet).

Laz - did you come across any player career stats in your experiments with the .sav files?

archibalduk wrote:

Lazion wrote:

archibalduk wrote:Btw, do you have any idea what the first 4 bytes of each index entry are? I haven't been able to figure that one out.

No idea, but I can take a look at those.

I have figured it out. It is the location of the subfile. For example, the entry for continent.dat is 268012. Sure enough, the first byte of continent.dat is located at 268012.

Haha! I thought about this one day, but I was too lazy to check it out.

archibalduk wrote:Laz - did you come across any player career stats in your experiments with the .sav files?

Not really. I only looked at hall_of_fame.tmp(?) and in injury_history.tmp and some transfer history file.. can't remember what it was called.
It's been a while.. Umm.. is there any game generated non-players or players in your saved game? Game might generate overaged players in junior teams and they get released in day one, so I was thinking that maybe transfer file which I mentioned above is called staff_history.tmp. But then again 52 bytes is rather long for transfer entry.
And if you have used NHL start date some leagues have already played few exhibition games.. maybe those 40 entries in staff_history are ongoing season stats for players?

I took another quick look to saved game.. this time in contract.dat.

As you can see we can edit all little details from contracts and from player status.
I'm trying to figure out how each value effect in game and post my findings in here.

Wow, nice! $1.1bn a year is very generous!

I don't know if it is of any help, but the Saved Game Explorer can now extract all of the sub-files from a saved game into separate files. I have found it makes it much easier to figure out the structures. I'll try to upload it later today.

Here you go.. there's still gaps without description, but most of the stuff is listed.