Jump to content

A word about modifying interactive software requiring a launcher for its DRM and preserving modifications between updates without special tools.

Preface

Having heard Linus complain about games automatically updating in Steam, I feel compelled to highlight a feature of Microsoft Windows since XP?️ and something that's been around since Ext3 was a thing for open-source operating systems. This works for anything which requires updates for continued operation by an end-user. And you already have these tools in your system⚔️.

Quote

 

?️ For XP, the capability to use the feature described was available but required additional administrative intervention to enable.

⚔️ Whether you can use said software depends on if your software is inside of a partition format which supports the features provided by said software (i.e. NTFS5, Ext3, Ext4 etc.)

 

 

The feature

Filesystem links. Many open-source systems had been using hard links for creating faux replacement of library files when a library upgrades, avid users have been using directory junctions and symbolic ("soft") links with remote storage management software to distribute files without creating hard duplicates on the local filesystem and yes, it can even make game modding without destroying or otherwise making useless original content stupid-easy‼️.

Quote

‼️ But be warned, if you modify an existing hard link and save over it, those changes will apply to the original file. Always delete the link before saving if modifying content accessible through a hard link. Or any link, as a matter of fact for a file you are modifying. Can't be too safe!

 

How it works

For files on partition formats which support this feature, the idea is pretty simple; they're shortcuts on steroids. Rather than a launcher to a file, they are the actual file itself being referenced from a different location. This can be leveraged in a variety of ways (use your imagination), but there are some limitations:

  • The partition must support the creation of filesystem links.
  • Between partitions, only soft links can be used.
  • Directories (usually) should not be referenced by a hard link.
  • Soft links contribute to inodes in use (as they are, in effect another file).?
  • Filesystem link support for remote storage applications vary.

For soft links, they reference the absolute path of a file. So if the path does not exist, the file is broken. For hard links, they reference the index node of another file. This is why whereas soft links use inodes, hard links do not because they are the file. Also, wh you can delete the original file but your hard links still cue the file you deleted because the index node is not orphaned.

 

Soft links can also be made to a partition format which does not support links in most instances, but not from because the partition format targeted does not support it.

Quote

? This is more of a Linux thing with Ext3 on. Ext3 parts usually have a limited number of inodes, whereas to my knowledge NTFS has no such arbitrary limit for file IDs.

 

So right how does this help with games?

In a variety of ways, links can be made to help preserve the original copies of files, but have modified content made available by referencing a game from a different path. It might seem like a pain in the ass to do, but with some work in the command line you can create easy-to-use scripts to execute which will do all of the heavy lifting for you.

 

...No wait, hang on! Yes, I said scripts, but the software used will help create these scripts rather easily with some basic modifications. I promise it's easy. If this idiot can do it... well, yeah.

 

#teamtrees

From hereon, everything referenced is for Microsoft Windows. You open-source nerds should be smart enough to convert these instructions for your variety of Linux, Unix or BSD.

 

To create a forest, one must first plant its seeds. While cliché, it's also true, and as such this maxim should be exercised before any other action takes place. To get your seeds, open cmd and cd into a directory you want to create a duplicate of. Once there, perform tree /F /A > file.txt (name file.txt anything you wish, to any path you want this text file to be at) and open it in your preferred text editor.

 

Growing the forest

Its output is... well, a tree of the directory, including files (due to the /F argument) and using readable characters (due to the /A argument). Using find and replace, use context clues to figure out which set of characters to replace with the following commands:

  • mkdir
  • mklink for soft file links
    • mklink /H for hard file links
  • mklink /D for soft directory links
    • mklink /J for hard directory links

On Windows, a limitation of how many files can be made in a given partition isn't too much of a concern so really, you should use soft links wherever you can, but only for directories you will not be touching. Having foreknowledge of what directories your modifications will touch is necessary for these future file operations to produce a clean work which does not jeopardize the integrity of a game's original files.

 

So in brief, this is how your script should handle this operation↔️:

  • mkdir modGame
  • cd modGame
  • mklink /D modGame originalGame/originalDir
  • mklink modGame originalGame/orginalFile
  • mklink /D modGame modSrc/modDir
  • mklink modGame modSrc/modFile
  • mkdir modGame/moreDir
    • mklink /D modGame/moreDir originalGame/moreDir/originalDir
    • mklink modGame/moreDir orginalGame/moreDir/originalFile
    • mklink /D modGame/moreDir modSrc/moreDir/modDir
    • mklink modGame/moreDir modSrc/moreDir/modFile
    • And so on
Quote

↔️ It would make sense if mklink allowed users to define source first, then destination. That's how GNU Coreutils' ln does it. But not Microsoft, oh no. Destination must be defined first for mklink to not suck.

 

With each representing the following:

  • original*: Original game, original game directory or original game file.
  • mod*: Modified game, modified game directory or modified game file.
  • modSrc*: Modification source
  • *Game: Title in question
  • *Dir: A directory / folder
  • *File: A file

The two initial commands are for creating a new directory for the modified game. So while some things could be directly linked, such as a game's dependencies or the game itself, other things which your modifications will adjust must be put into their own directories, and should be a mix of the game's original files, with the modified files which would otherwise be overwritten.

 

The above example can be modified to suit; if you intend on just creating the modified game root directory yourself, just have the link commands and create new directories further up the tree as you go. Save your work as a batch  (.bat) file, and execute it. If all goes well, your work should yield a modified game using only symbolic and / or hard links.

 

A GUI way

If the above is just, like, way too much or you don't feel like spending a weekend doing any of this stuff, then there is a utility for Explorer you can install which will permit creation of filesystem links within the file manager itself. This utility can be found here: https://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html#download

 

The main caveat being that if you want to share this with your friends, you have to repeat your operations on their machines, whereas with a script your operations can be distributed with simple instructions for them to apply modifications themselves, should you want to share interactive in a multiplayer session where mods are not usually supported in-game. If you want to get into some more advanced stuff using %variables%, then you can further simplify the main script and tell your friends to play with the variables themselves, as well include simple if/else conditionals to stop your friends from being idiots and somehow accidentally using the wrong stuff, but that is beyond the scope of this article.

 

Conclusion

The use of filesystem links for game modification can be a bit tedious; Not only do you have to create a file which performs operations for you or use a GUI utility to do this stuff (and replicate your steps on other machines), you also have to manage your links between game updates. This can be as simple as overwriting your mod sources, or as complex as re-writing the entire script from scratch. however the time spent is worthwhile, if you want to modify something guarded by DRM, but not want to also ruin your original content to keep that usable in multiplayer or other guests who don't prefer to use your mods.

Edited by Autoism
Yikes... see reply.
Link to comment
Share on other sites

Link to post
Share on other sites

Fixed up file paths for examples. I was fatigued while writing this originally.

 

Edit: Yikes! I forgot that mklink swaps source and destination compared to GNU Coreutils ln. Sorry about that!

Link to comment
Share on other sites

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×