PAYDAY 3 Modkit & Modloader

My role

Engine programming, editor tools, runtime systems and technical UI

Project

PAYDAY 3 Modding, community-developed tooling

Technologies

UE 5.5.4, C++, Blueprints, Slate, UMG, C# and Unreal Automation Tool

Period and status

2026 to present. Active development; PDML in public early access.

From restoring tools to rebuilding the workflow

PAYDAY 3’s August 2026 move from Unreal Engine 4.27 to UE5 disrupted the community’s established modding environment. I had already developed VanillaHUD+, HUDCore and other mods, and helped maintain the earlier UE4 project. Recreating that environment was the starting point. Building a more capable development workflow became the goal.

I developed the custom UE5 compatibility editor, the Modkit project, CrimeForge and PDML, working across C++ engine compatibility, editor extensions, Blueprint systems and interface design. I also integrated and extended the Suzie-based native class workflow, built templates and documentation, and supported creators through setup and troubleshooting. Other developers, testers and documentation contributors have helped shape and validate the ecosystem.

A custom editor that understands installed game content

The custom Unreal Engine 5.5.4 editor mounts supported retail containers, including IoStore content, from the user’s installed PAYDAY 3. With the game path, AES key, current AssetRegistry.bin and reflected native types configured, supported assets appear at their original /Game/... paths in the Content Browser.

My compatibility work bridges cooked package loading, editor assumptions, dependency resolution and game-specific serialization. It includes registry preservation during refreshes, cooked Blueprint references, supported levels, thumbnails, material instances, skeletons, animations and fonts. Modders can inspect supported content in context instead of manually reconstructing every dependency before starting.

Reconstruction with explicit limits

Supported assets can be converted to uncooked copies for replacement workflows. Simpler types can be reconstructed substantially. Complex Blueprints and widgets provide a partial starting point: recoverable defaults, parent classes, components, references and widget structure. Original Blueprint graphs and native function implementations are not automatically recovered.

Widget reconstruction is especially relevant to my UI engineering work. A replacement must respect game-specific parent types, properties and named bindings. Recovering a widget tree is only part of that problem; binding metadata, animation data and tick behaviour also affect compatibility. This remains active development.

The environment also supports demonstrated custom material, mesh and animation workflows. The team’s material baking work helps interpret layered colour and mask systems, with remaining visual limitations. Modified Wwise integration supports compatible audio workflows when users supply the matching third-party SDK files.

Suzie: resolving the missing native types

Cooked assets reference PAYDAY-specific native classes unavailable in a standard Unreal project. I integrated and extended a workflow built on the existing JMAP and Suzie projects to expose those reflected types in the editor.

GenerateJmap.bat gathers metadata from a locally running game. Suzie reads the JMAP in Content/DynamicClasses/ at startup, then generates and registers compatible class representations. That enables supported Data Assets and Blueprints to resolve game types, including the SBZ family and PD3HeistDataAsset. Reflection supplies structure, not the game’s original C++ implementation.

Keeping the JMAP and Asset Registry current makes ordinary game updates easier to maintain. Engine-level changes can still require compatibility fixes. Read the architecture documentation.

CrimeForge: authoring, validation and packaging

I developed CrimeForge as a PAYDAY-specific Unreal Editor plugin. Its Slate interface brings searchable mod cards, metadata, configuration, Content Browser navigation, compatible legacy imports and Forge actions into one place. Each mod is an Unreal plugin with its own namespace.

The current Blank, Logic Mod and Custom Heist templates create the relevant plugin and registration assets. Logic mods receive a Blueprint derived from PDML’s ModActorBase. Heists receive a level and PD3HeistDataAsset with their initial references connected. HUD and audio templates remain planned.

Forge validates the selected mod before cooking, checking Primary Asset Labels, Asset Manager registration, chunk configuration, explicit assets, dependencies and stale template references. Blocking errors and warnings are presented separately; recognised configuration issues can be repaired where safe.

The packaging challenge goes beyond wrapping Unreal’s build button. Plugin-owned assets and replacements at original /Game/... paths need different handling. CrimeForge uses a plugin cook for ordinary content, adds a project replacement cook when required, and combines the selected output into one PDML-compatible plugin. Plugin-only mods skip that extra pass. Custom C# automation runs through Unreal Automation Tool, with optional copying into the game and launching for testing.

PDML: runtime systems and player-facing UI

I developed PDML as the runtime counterpart to CrimeForge. Complete plugin mods live under PAYDAY3/Mods/<ModName>/, keeping their descriptors and cooked containers together. PDML provides supported registration, initialization and Blueprint APIs for logic mods, custom UI, settings and custom-heist foundations.

The in-game Mod Manager and integrated settings framework connect my runtime and UI work. Authors expose configuration through shared APIs; players adjust supported mods inside the game. This builds on my earlier HUDCore and VanillaHUD+ experience while removing repeated integration work for other creators.

Engineering challenges and current boundaries

The hardest problems sit between systems: making cooked packages useful to an editor, registering compatible native types, preserving references during reconstruction, and packaging multiple content roots without pulling unrelated game assets into a mod.

Custom heists now have an authoring and registration foundation, but advanced AI navigation, AirNav and some game behaviours need more work. Runtime plugin mounting and Asset Registry discovery are ongoing investigations. Reliable dynamic unloading, load ordering, enable/disable controls, hot-swapping and in-game ModWorkshop downloads are not established public-release features.

Community, documentation and recognition

The result is a publicly documented path from local setup to a forged, testable plugin mod. I help maintain Antora and AsciiDoc guides covering the editor, reflection, CrimeForge, PDML, replacements and custom heists. Community feedback helps turn individual compatibility discoveries into repeatable workflows.

The announcement credits recognise contributions including Columbus’s material baking work, Capcake’s custom-heist documentation and testing, Pinki_Ninja’s documentation and testing, and wider compatibility testing. FlamingFury1000 contributed future Mod Manager concept UI; that concept is distinct from the current interface shown here.

Beyond the response from the modding community, the project has received positive acknowledgement from Starbreeze, the developers of PAYDAY 3. They have expressed appreciation for the work and an interest in supporting the effort further, although I can’t share additional details at this stage. The toolchain remains community-developed.

Project resources

• PD3 Modkit and public tool source
• Documentation and getting started
• Custom editor and compatibility documentation
• PDML early-access release on ModWorkshop
• PAYDAY 3 Modding organisation

The full development article explains the engineering decisions in more depth. My earlier PAYDAY 3 Modding project covers the UE4-era work that preceded this toolchain.

Screenshots above come from the public community announcement. The banner and portfolio thumbnail are from the PDML ModWorkshop page.