Dealing with Paks
To get access to the assets inside of a pak file, modders will need to unpack it. There are plenty of tools that can achieve this, although if a modder already has the correct engine version installed (which they can find out by right clicking the game’s binary and looking in the details tab) they can call to the UnrealPak utility by command line or batch script. However, if the game uses IO Store, they must use another tool to obtain a manifest/mappings file that contains special data that allows other tools to then unpack the pak files.
Once modders have created their edited or new assets, they need to pack only the assets back into a pak file. If the game uses the IO Store format, modders must repack using that same format. If the game uses pak signing, they must copy the existing sig file and rename it to match the name of the mod pak file.
The quality of the modding experience can differ depending on what packaging settings have been defined in the game’s project, but obviously the people responsible for these settings need to weigh up these settings with their own circumstances:
Name | Engine versions | Default | What ON does | What OFF does | Optimal |
---|---|---|---|---|---|
Use IO Store | 4.25+ | OFF for 4.25-4.27, ON for 5.0+ | Produces .ucas /.utoc file types within the pak file, which are less mature formats so requires considerable extra work to work with them like the previous format. There is a tool called ZenTools that reads the IO Store container files and converts them back to the old format, but it is unstable at best | Produces .uasset /.uexp files within the pak file, which are the easiest to work with | OFF |
Un-versioned Assets | 4.25+ | OFF for 4.25-4.27, ON for 5.0+ | Removes version signatures from asset headers. Makes them difficult to mod, as asset parsers depend on reading the versioning information in the headers for deciding on how to parse them | Keeps version signatures in asset headers | OFF |
Event Driven Loading | At least 4.17+ | ON | Produces both the .uasset /.uexp files and is highly suggested for the best modding experience, as most tools rely on both being there | Produces only the .uasset files | ON |
Blueprint Nativization | At least 4.17+ | OFF | For any blueprints that are added to the whitelist, and every userdefinedstruct/enum, their code is "decompiled" to C++ rather than bytecode as an asset, which means that the blueprint cannot be "viewed" by modders with any tool | Cooks blueprints as .uasset files | OFF |
Generate Chunks | At least 4.17+ | OFF | Combined with allow ChunkID assignments asset action being on, it packs assets into specified pak chunks. This makes lives for modders more annoying than anything because having to unpack multiple chunks is a pain and can become messy | Packs everything into one pak file | OFF |
Use Pak Encryption | At least 4.17+ | OFF | Requires an encryption key to be generated and that key must be provided when unpacking the pak. Modders can use tools and a bit of brute force to obtain these keys, but it can be annoying if a game does not need it (I.e., not a game where mods can be used to gain an advantage over others) | Pak file will not be encrypted | OFF |
Use Pak Signing | 4.22+ | OFF | Requires a signing key to be generated and places a .sig file next to the .pak files in the Paks folder. It is designed to be for anti-tampering but as usual is trvially easy to bypass - simply by passing -fileopenlog in the game's launch parameters | Pak file will not be signed | OFF |
PakFileCompressionFormats | At least 4.17+ | None | Compresses the Pak file using Oodle and modders have to be extra careful when dealing with reading/writing files inside of compressed pak files | Pak file will not be compressed | None |
The files that are stored in the .pak files are cooked. This means that they cannot be copied into a UE project and edited inside of the editor. There are a few exceptions, for example data tables and string tables – and to do that you need a couple of configs – but it’s only really useful for basic data mining.