Saints Row 2 Monkey Patch Project

Saints Row 2 Monkey Patch​




Introduction​


This project alters the original Saints Row 2 executable file with patches and fixes that can't be implemented by other means. A monkey patch is a
patch that is implemented as the program is running instead of changing the files of a program. It has advantages and disadvantages but as we don't
have access to the original source code and the Steam version is encrypted, it's the only method open to us.


How to use?​


Replace the DFEngine.dll in the game's directory with the patched version, making a backup of the original if required. To uninstall, just delete the patched
DFEngine.dll file with the game's original one.

The patch will generate a sr2patch.txt file with debug information about what the patch is doing.

If you want to keep the GOG 30 fps limit, then run Saints Row 2 with the command line parameter keepfpslimit.

What patches are available?​


At this moment in time, these patches are available.

  • Removes the ads from the game, and telemetry (if used by the game).
  • Removes the fps limiter of the GOG version. You can disable this patch using the command line parameter keepfpslimit.
  • Integrates OpenSpy as a replacement for GameSpy.
  • (Testing) Fixes the speed-up bug automatically without the need to use powertools.

Other information​


As none of my computers are effected by the speed-up bug, I can't completely test it. I can do the opposite and cause the bug to trigger. I would very much appreciate anyone who is effected by the bug to let me know if it works.

The source code is included in the download. You can also go to the project's github page. If anyone has any patches to contribute, please fork the repository and add to it.

Licence​


This code is written under the MIT licence. I chose this as it's the least restrictive licence.
 

Attachments

It is a good day when you post.
I thought "wouldn't it be nice to know when Scanti posts a thing" and lo and behold, this site has that feature.
Thank you! (gonna follow some other cool people too)
 
Are you planing to implement support for higher quality audio files and maybe some other limit increasing? It could be nice to finally have a way to implement Xbox 360 quality voices and SFX. Also, performance and lighting fixes would've been a nice addition. I'm not even asking about the possibility of DLC loading implementation, since this would probably involve a lot of reverse engineering. Anyway, very nice mod, keep up the work and maybe some day this port will actually be bearable.
 
Are you planing to implement support for higher quality audio files and maybe some other limit increasing? It could be nice to finally have a way to implement Xbox 360 quality voices and SFX. Also, performance and lighting fixes would've been a nice addition. I'm not even asking about the possibility of DLC loading implementation, since this would probably involve a lot of reverse engineering. Anyway, very nice mod, keep up the work and maybe some day this port will actually be bearable.
I'll add looking at the audio files to my to-do list. The problem is that the limitation is probably down to memory issues. The memory is usually preallocated to the maximum amount of memory each data type is going to use up. On a console where the free memory is usually constant it makes the game more stable, but on Windows where the amount of free memory varies from system to system it can lead to memory problems. So the fix may not work on the vanilla Steam version as you would need to change the executable to be large address aware (to free up some more memory), which the copy protection of the Steam version actively stops you from doing. (I know there are ways around it, but they remove the copy protection, which I won't use or discuss the use of).

At the moment, I'm flipping between decompiling the code in general and focused decompilation of a particular set of routines. I need the "unfocused decompilation" to get a feel of how the data structures work (it's all interconnected, man). Before, I was focusing mainly on program flow, but a more data driven focus really seems to help me. That's how I noticed the precision bug in the timing routines.

So I'll focus on some problems, if they are fixable just in isolation, and some problems I will fix as I come across them.

As for adding the DLC, that probably won't happen if parts of the DLC are hardcoded in the game engine. I would need access to the original source of the added code. Plus, I would have memory problems with the Steam version, as I explained before.
 
I'll add looking at the audio files to my to-do list. The problem is that the limitation is probably down to memory issues. The memory is usually preallocated to the maximum amount of memory each data type is going to use up. On a console where the free memory is usually constant it makes the game more stable, but on Windows where the amount of free memory varies from system to system it can lead to memory problems. So the fix may not work on the vanilla Steam version as you would need to change the executable to be large address aware (to free up some more memory), which the copy protection of the Steam version actively stops you from doing. (I know there are ways around it, but they remove the copy protection, which I won't use or discuss the use of).

At the moment, I'm flipping between decompiling the code in general and focused decompilation of a particular set of routines. I need the "unfocused decompilation" to get a feel of how the data structures work (it's all interconnected, man). Before, I was focusing mainly on program flow, but a more data driven focus really seems to help me. That's how I noticed the precision bug in the timing routines.

So I'll focus on some problems, if they are fixable just in isolation, and some problems I will fix as I come across them.

As for adding the DLC, that probably won't happen if parts of the DLC are hardcoded in the game engine. I would need access to the original source of the added code. Plus, I would have memory problems with the Steam version, as I explained before.
Hey, that's all great to hear! For the LAA you could use something like mentioned here. As for decompilation, I think you should get better understanding of game's functions and then try to find specific things. Worked for me when I was making an unofficial patch for CMR. Also, I was looking through extracted DLC files from Xbox 360 build and it looks like audio and textures will have to be converted, but other than that it looks like standard set of scripts and assets, that game loads. You could try to force the game to try and load those files as if those were part of the base game and see what would happen. In any case, you're doing a wonderful job and I only hope, that you will improve this project and make SR2 PC finally a usable port.
 

Saints Row 2 Monkey Patch​




Introduction​


This project alters the original Saints Row 2 executable file with patches and fixes that can't be implemented by other means. A monkey patch is a
patch that is implemented as the program is running instead of changing the files of a program. It has advantages and disadvantages but as we don't
have access to the original source code and the Steam version is encrypted, it's the only method open to us.


How to use?​


Replace the DFEngine.dll in the game's directory with the patched version, making a backup of the original if required. To uninstall, just delete the patched
DFEngine.dll file with the game's original one.

The patch will generate a sr2patch.txt file with debug information about what the patch is doing.

If you want to keep the GOG 30 fps limit, then run Saints Row 2 with the command line parameter keepfpslimit.

What patches are available?​


At this moment in time, these patches are available.

  • Removes the ads from the game, and telemetry (if used by the game).
  • Removes the fps limiter of the GOG version. You can disable this patch using the command line parameter keepfpslimit.
  • Integrates OpenSpy as a replacement for GameSpy.
  • (Testing) Fixes the speed-up bug automatically without the need to use powertools.

Other information​


As none of my computers are effected by the speed-up bug, I can't completely test it. I can do the opposite and cause the bug to trigger. I would very much appreciate anyone who is effected by the bug to let me know if it works.

The source code is included in the download. You can also go to the project's github page. If anyone has any patches to contribute, please fork the repository and add to it.

Licence​


This code is written under the MIT licence. I chose this as it's the least restrictive licence.
Good mod, thanks! Too bad there's no DLC, but it's still awesome.
 
Last edited:
I haven't tested GOTR as I want to keep the game vanilla during testing. However, it doesn't change anything that would affect GOTR, so I'm pretty confident it will work without any problems.

That's one of the barriers to patching the game. I've found a way to change the list of screen resolutions, however in doing so, I will need to change a lua file, which in turn would conflict with the GOTR patch. (It's part hardcoded and part lua coding). So I have to come up with a workaround.

I'm also working on a way to load loose files, instead of packing any altered files into the patch.vcc_pc archive file. The engine abstracts files on the drive and files packed into an archive the same, it's just working out how the mechanism works, priorities and whatnot.
 
The ad and telemetry removal results in the game no longer fetching generic Ultor billboards to paste on the relevant areas' textures, which leads to them becoming bizarre windows into the game's skybox. I'm sure there's a performance boost as a result, but it might be considered ugly for some (I don't personally mind, but I'm also the sort of person that likes trying to peek out of bounds so I'm biased).
Maybe this doesn't happen to Gentlemen of the Row players, or on some other devices? Feels weird nobody's mentioned it.
 
Back
Top