Hades: Game Patches

Probably the most flexible way is to use a versioning system like git. This allows you to manage multiple versions of the scripts and toggle between different modifications without fear of having to re-download the game files if you break stuff. Git has been specifically designed to handle use cases like this well.

It’s a lot to take in though if all you want to do is just mod a single game and aren’t a developer already. The patches can be applied by hand (see the next section), so don’t worry about having to learn git if you don’t know how to use it yet.
It is more convenient to use it if you’re changing and trying out a lot of things though. I only include this part because of completeness, but assume people will just apply patches I provide manually.

In the context of this guide, I’ll refer to Hades Content directory as project root directory (or root directory). You can find it by selecting “Manage > Browse local files” on Hades in your Steam library. All of the commands are supposed to be ran from the root directory.

There’s a free book[git-scm.com] available that explains how to use it in great detail, but you’ll likely need just a few very basic commands:

• git init [path]

  – to initialize a local repository at [path]

• git status

  – to check what’s the current branch and whether you have any pending changes

• git add <path>

  – to recursively stage files at path for checkout

• git checkout <branch_name>

  – to switch between branches

• git checkout -b <new_branch_name>

  – to create new branches

• git apply <patch_path>

  – to apply patches

• git commit -m “description”

  – to save changes; before switching to a different branch

• git merge <other_branch>

  – to merge content from other_branch to current branch

In git you “stage” changes to be committed, and then commit them. This allows you to modify files and then partially stage them so you add only certain details to the commit (in case you want to separate changes you’ve made into multiple different branches).

I also suggest using LFS with git, because the initial commit of the sources can be extremely heavy due to binary texture/sound assets. To install LFS run:

To add files to the LFS, create a .gitattributes file listing all binaries you want handled by LFS instead of git. Here’s my list[gist.github.com] so you can just copy .gitattributes directly into the project root directory.
After you’re done installing LFS, run

to ensure the appropriate files are tracked by LFS. This is important because the initial commit will be incredibly slow even with LFS enabled and can take well over an hour otherwise (didn’t test it; suggest you don’t either).

You might also choose to ignore these files instead, in which case you can copy the linked[gist.github.com] .gitignore file instead and then add it. This is fastest, and probably good enough given that it’s unlikely you’ll be changing binary assets, as that requires special tooling Hades community hasn’t developed yet.

In my workflow, after initializing the base branch (sources), I separate all modifications into different branches, and have a separate branch (run) where I merge them all in. This allows me to retain all the changes in case the game updates and update patches when they need to be updated. It’s also very convenient because I can mix and match different modifications for each run by merging patches based on sources into run selectively.
To get a similar setup (and configure LFS) run the following from the root directory:

After that, you can base your modifications on sources:

And apply them to run with:

This will sometimes open an editor, you can just use the default message. If the editor is Vim, simply type “:x” to save the message, but I suggest you use a different one if you’re new to this as Vim can be tricky to use for noobs.

Sometimes you might modify the files before checking out sources, on another branch. You can temporarily remove (stash) the changes with

, then switch to another branch and revert those changes with

For completeness this section briefly explains the git patch format, so that you can quickly get to patching files. There’s more detailed explanations available in other places[stackoverflow.com], so you can read those if you’re interested or find this explanation insufficient.

A general format of a patch file looks something like:

Blocks like these might be repeated several times in a single patch because a patch can describe changes to multiple files. That’s why I’m staring patches – they provide all the context, tools can apply them automatically, and tools also offer validation so as to avoid changing wrong content.

In the above snippet, the following line tells you the file that was modified:

So you’d have to open that file with your text editor of choice (e.g. VSCode). In this example that’s “Scripts/ObstacleData.lua” in your game’s “Content” directory. You can find it by selecting “Manage > Browse local files” on Hades in your Steam library.

The part with @@ symbols specifies the line that must be changed:

In this case, the patch replaces (removes) lines in the file starting at line number 583, and adds content to the same line. You can ignore the second number. This is mostly useful so you can quicky find the place where you need to apply the changes.

Finally, all the lines starting with “-” need to be removed/replaced with lines stating with “+”. In this case, you’d remove:

And then add: