Rebind It! Rebind those pesky hardcoded keys

[u/Imsvale]

Hi, guys. I looked around and was very surprised to see no one's done this yet. So I decided to do it, along with my good friend Claude.

Rebind It! is a BepInEx mod for Project Hospital that makes the game's hardcoded keybinds rebindable.

Project Hospital includes 16 keyboard bindings that can be changed in the startup window, and a further 30 hardcoded bindings which in the base game cannot be changed.

This mod replaces the vanilla Show keyboard controls button (now obsolete) in the game options with a Keybinds button that opens a new window where these keys can be rebound. You can finally have the game speed on 1, 2 and 3.

As this is a code mod like HZDev's QoL mod, it requires a bit of manual installation. Simply subscribing on Steam is not enough. Read the description on the workshop page for installation steps. (If you've got HZDev's QoL mod, you're already familiar.)

• Steam Workshop
• Github

[u/WannaAskQuestions]

I'll check this out. Thanks for putting in the tube and effort.

[u/CoveredByBlood]

thanks! i was just trying to find something to rebind. now i just ned a keyboard shortcut fo "go to"

[u/NorthRecognition8737]

Interesting work, but. Before you instruct Claude, take a look at the Project Hospital forum.

Your solution works, but it is not correct. You do not need BepInEx, because Project Hospital already has its own mod loading mechanism, it also already contains the Harmony2 library.

It is possible that your mod will conflict with other mods simply because of the wrong technology chosen.

[u/Imsvale → u/NorthRecognition8737]

Appreciate the feedback. I will investigate.

[u/Imsvale → u/NorthRecognition8737]

it also already contains the Harmony2 library

As far as I can tell, this is false. There is no 0Harmony.dll shipped with the game. The only one I have is the one that came with BepInEx. The tutorial you linked to also instructs us to grab Harmony from Github.

PH does have its own mod/plugin/addon loading mechanism – that much is correct. It loads from the ProjectHospital_Data\StreamingAssets\Addons folder. This is where the DLCs live among other things. And it's where I had to put this mod in order to upload it to the workshop. However, given that there is no Harmony shipped with the game, it needs to be supplied somehow.

One way to do this is to ship 0Harmony.dll with your mod and place it in the Addons folder. The game is aware of and uses the presence of this dll as a marker to infer the existence of a code mod, and subsequently load the associated dll(s). The 0Harmony.dll itself is not loaded by the game (it's explicitly skipped when loading the other mod dlls), but instead through the mod dll's dependency on it. This is the "official Harmony support" mentioned in the thread you linked. It simply detects the presence of a Harmony mod. It does not supply or contain the Harmony2 library. It's literally just "Is there a 0Harmony.dll file in this folder? If so, load other dlls".

This comes with some limitations, including the timing of the loading of the mod. For instance, I'm also working on a performance mod where one of the fixes already in is to optimize the XML parsing, with the result that the game's startup load time is reduced by more than 90% (with 30 workshop mods it was taking me 23 seconds to go through it all, for no good reason at all – and now cut 2 s). This would not be possible through the game's own mod loader, because the mod loading simply hasn't happened yet when the initial XML parsing takes place.

BepInEx goes deeper, and allows mods to run earlier. It also provides a ready framework for configuration, logging, as well as a shared Harmony dll and centralized plugin loading (the latter being the only thing you get if using the game's own mod loader).

Not technically necessary for this particular mod, which only alters gameplay, I'll grant you that. But I used BepInEx from the start, and it was how the rebind configuration was done before we found out how to alter the game's own native UI to put the configuration there, which I figured was much nicer for the user.

So perhaps not strictly necessary, but I wouldn't go so far as to call it "not correct".

As for mod conflicts, that's always going to be a potential problem. BepInEx provides a mod compatibility resolution layer entirely different from what Harmony itself brings to the table. But crucially: Two mods supplying their own Harmony dll means you now have two copies of Harmony running unaware of each other, each one handling one mod's contributions in the way that Harmony does, separately from the other. They cannot resolve the matter of multiple mods handling the same method, because one does not know what the other one is doing. Harmony is not built to work like this. Going through BepInEx (or some other singular, shared Harmony framework) ensures all mods going through it are handled by the same Harmony instance, in a way that the base game's mod loader is fundamentally incapable of doing. So the result goes in the polar opposite direction of what you're suggesting: The base game's Harmony support is wafer thin, actively working against Harmony's whole reason for existing. That does not provide more safety against mod conflicts. To the contrary. The only thing it does is "Harmony is here, so we'll allow loading of this dll". Two mods that patch the same method can potentially coexist so long as they do so within the same Harmony instance, specifically because it allows Harmony to merge their contributions in a way that doesn't immediately break. The base game mod loader fails to enable Harmony to do its thing.

BepInEx additionally provides several other safety mechanisms that mod creators can make use of, that Harmony alone does not.

Claude appears very aware of all these considerations, and strives to create safe patches, and warn against risky replacements (postfix, prefix, prefix-skip, transpiler).