For mods, runtime file loading of plain data files is the lower risk route, because the files are assets such as images, audio and models. PCK or ZIP packs are more capable and can carry scripts, so they carry code risk. Choose by what your mods must do, not by convenience.
The two routes in plain words
Godot documents two ways to bring outside content into a shipped game.
Resource packs. Players or you produce a .pck or ZIP file from the Godot editor. The pack contains resources that Godot has already imported, and the documentation says packs usually hold scripts, scenes, shaders, models, textures and audio. The game loads the pack at runtime.
Runtime file loading. The game reads loose files directly. The documentation lists use cases such as texture packs, user provided audio for an in-game radio, custom levels or 3D models exported as glTF or FBX, and user fonts. It adds that this can be combined with web requests to load from the internet.
Comparison
| Question | Resource pack | Runtime file loading |
|---|---|---|
| Can it carry scripts? | Yes, per the docs | Not by design; you load data files |
| Do mod authors need Godot? | Yes, to export the pack | No, any tool that writes the format |
| Fits game logic and resource handling | Closely | Less transparent, per the docs |
| Main risk | Executes code you did not write | Parser bugs and unexpected file contents |
| Good for | Expansions, patches, trusted creators | Skins, audio, levels as data |
What "safer" means here
Safer does not mean safe. A data file can still be malformed, enormous, or aimed at a bug in an image or model parser. Your game should limit file sizes, handle load failures without crashing, and never pass file contents to anything that evaluates them.
But the worst case differs. A malicious pack can be a program. A malicious texture is usually a parsing problem. That gap is why many studios keep scripted mods for a trusted tier and offer data only mods to everyone else.
A decision guide
- Write down what a mod needs to change. If the answer is "how things look and sound", use runtime file loading.
- If mods must change behaviour, ask whether a small data format could express it, such as a table of stats or a level layout file that your own code interprets.
- Only if neither works, accept packs, and apply the controls in the PCK patch and mod guide: signing for first party packs, clear warnings for community ones.
- Do not mix routes silently. Make the trust tier visible to the player in the mod menu.
- Keep your own game content out of the runtime loading path. Godot's documentation warns against using runtime loading for resources that are part of the project, because it is less efficient and skips resource handling.
What to log for support
When a mod misbehaves, you want to know which route it used. Log the file name, the route, and the load result. If a crash report mentions a pack, support can ask the player to remove it before anything else.
Where scanning fits
Neither route changes what your own project depends on. Your build still pulls engine templates, addons and perhaps NuGet packages, and those belong in an inventory. Safeguard's SBOM and dependency scanning can read project manifests, and a free scan is at gold.safeguard.sh/scan. Mod content that arrives after release is outside what a build time scan sees, so the controls above matter.
Quick check
Can players use glTF models as mods without Godot?
The Godot documentation describes loading custom levels or 3D models made in any tool that can export glTF or FBX through runtime loading, which avoids needing the Godot editor to pack them.
Is runtime file loading free of risk?
No. It removes the script route but not parser bugs or hostile file sizes, so validate input.
Should my own DLC use runtime loading?
Godot's documentation advises against it for project resources and points to packs for patches and DLC.
Sources
- Godot documentation: Exporting packs, patches, and mods
- Godot documentation: Runtime file loading and saving
Last reviewed: 19 October 2026.
