I don't like when game developers limit your choice of save game location to "no choice at all". So let's change that.
M&B stores its save games in the "My Documents" folder, and like many other people I have that one on a separate disk, which happens to be external. This means that write times can be quite long. With frequent autosaves that becomes a nightmare.
So, there are two reasons to mod-app the save game "feature".
1. To save games where you want them to be saved.
2. To save time.
This is an ongoing project where newbies and others are encouraged to fill in things that are left in the work sequence. Successfully completing unfinished parts of the sequence will qualify you for developer section access. See it as practice, or as a tutorial, where you actually see that you can make use of your skills to do practically anything you want.
Work sequence:
The easiest way to solve this problem is likely to BP the write to file API in Windows (kernel32), but OllyDBG didn't work out for me when I attached it to M&B and as SoftICE doesn't work anymore normal memory editing techniques will have to do.
Play M&B in Windowed mode, or you will find yourself having to abort mid-way as M&B, while unfocused, sometimes covers the screen and hides everything on the desktop.
1. Search for "Autosaving" in Cheat Engine for example.
This message appears right before the save game process starts, and that's where we want to go.
2. We get a couple of alternatives. The lowest one 0FB15178 is usually the one we're looking for. See what accesses it.
We find 475150, let's put an access BP on it.
Then step over (F8 in Cheat Engine) until you hear your HD work (the debugger will stop briefly while the save game is written to file anyway).
3. You will find a call to the save game function (5FDFE0) at 5FE630.
Scroll down to find a reference to %s%s\new_game.sav at 5FE118. The string can be found at 8FA0DC.
A code cave where that string is overwritten by an absolute path will probably not solve the problem as some function will expect two %s later on (%s is a kind of C placeholder for variable text).
4. We got to find the place where the %s information is read and change it (or somewhat worse find the resulting string that gets sent to the write file function). So we need to find where the file is created. The new_game file pops up after the call to 44E010 at 5FE153.
Right before it we can see a parameter being sent to it (5FE14E: push ecx). Ecx contains a memory address that points to the full string, i.e. %s has already been replaced. We can choose to make a code cave here to read a static address with the path of our choice.
5. Write a code cave that does this.
6. Write a trainer that lets you enter the path.
7. The save game process involves three files. (i.e. finding the %s-location once will solve everything in "one hit"). The new save, the recent save, and the backup save.
New_game is created.
Backup is removed.
Recent is made backup.
New_game is made recent.
The paths have to be adjusted for all of those. The one-hit solution would probably have to find the right call to SHGetFolderPathW and disregard the output (i.e. set DriveLetter:\MyPath\ instead of C:\My Documents\ . Hint: Look right after 766D13A8, add 0x4C to ebp (seems to be related to SHGetFolderPathW). If the same part of the code is used for more purposes a cmp-filter for the integer CSIDL_PERSONAL can be done. The multi-hit solution can target the location at 5B092F: push ecx . Ecx contains the file paths.
M&B Fire and Sword, 1.143