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 Zen .ucas/.utoc containers alongside the .pak file. There is a tool called retoc that reads the IO Store container files and converts them back to the legacy format for editing - though it is unstable on UE4 versions as the file format was not mature enough yet to allow assets to be round-trippable. | Produces .uasset/.uexp files within the pak file. | Default values (OFF for UE4, ON for UE5+) |
| Unversioned 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 |
| 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 (with the side effect of many more disk read/write operations) | Pak file will not be signed | OFF |
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. Later on we will discuss UE5 cooked editor which will involve working with cooked content in the editor but note that these techniques still won't allow for the majority cooked content to be editable as if they were raw original assets.