UE4SS is a Lua and C++ modding layer for Unreal Engine games, not a plugin

What the acronym covers, and the five things it does

UE4SS is the Unreal Engine 4/5 Scripting System, and the GitHub description lists its roles compactly: an injectable Lua scripting system, SDK generator, live property editor and other dumping utilities for UE4 and UE5 games. The README expands that into a feature set worth taking seriously.

There is a Lua scripting API for writing mods against the Unreal object system, and a C++ modding API for the same thing in compiled form. There is a blueprint modloader that spawns blueprint mods automatically without editing or replacing game files, which removes the step that usually makes modding a game invasive. There is a live property viewer and editor where you can search, view, edit and watch properties of every loaded object, described as useful for debugging mods or for working out how values change at runtime.

The dumpers are the fourth pillar, and there are several distinct kinds. The UHT dumper generates Unreal Header Tool compatible C++ headers so you can create a mirror `.uproject`. The C++ header dumper generates standard headers from reflected classes and blueprints, with offsets included. A file parsing dumper generates `.usmap` mapping files for unversioned properties, and a UMAP recreation dumper writes loaded actors to file so you get `.umaps` in the editor. There are further experimental features linked from the same documentation.

The implementation is C++, licensed MIT, with the documentation at docs.ue4ss.com and a Discord for support alongside a separate Unreal Engine modding Discord. GitHub reports 2926 stars, 525 forks, 273 open issues, and a push on 2026-09-21.

It is injected through a proxy DLL, which explains the install layout

The installation mechanism is the single most important thing to understand, because it determines where files go and what happens when something breaks.

The README describes installing by downloading the non-dev version of the latest non-experimental build from Releases and extracting the zip into the game's binaries directory, spelled as `{game directory}/GameName/Binaries/Win64/`. If your game appears in the custom config list, the contents of the relevant folder go to `Win64` too. For mod development, download the zDEV build instead.

The README and the most recent release notes describe different layouts, and both are current, so read carefully. The release notes for the December 2024 build say the default installation layout changed: all UE4SS files, including `UE4SS.dll`, settings and mods, now live in a `ue4ss` subfolder next to the game executable, with only the proxy DLL remaining in the game's `Win64` directory. The stated reason is that it keeps the game folder cleaner. Old installations keep working for backwards compatibility if the DLL is replaced directly.

The proxy default is worth knowing. By default UE4SS generates a proxy based on `C:\Windows\System32\dwmapi.dll`, and you can point it elsewhere with a CMake variable at build time. When installed via proxy DLL, two command line options exist. `--disable-ue4ss` temporarily disables UE4SS without uninstalling it, which is the fastest way to confirm whether a crash is UE4SS or the game. `--ue4ss-path <path>` points at a custom DLL path, supporting absolute and relative paths, so you can test a different build without touching your installation.

There is also an environment variable, `UE4SS_MODS_PATHS`, which takes a semicolon-separated list of additional mods directories. Paths are processed in reverse order so the first entry has highest priority, the same convention as the `PATH` variable.

You may need to fix AOB scans yourself, by design

This is the paragraph that decides whether UE4SS suits your purposes, and the README puts it near the top under a heading about targeting UE versions from 4.7 to 5.8.

It says the goal of UE4SS is not to be a plug-n-play solution that always works with every game. The goal is to have an underlying system that works for most games. You may need to update AOBs on your own, and the README points to a guide for doing that.

That is an honest statement about the nature of the work. A shipped Unreal game is compiled, optimised and stripped, so the memory patterns the tool looks for differ per title and per engine version. A system that fixed that automatically for every game would need per-game signature databases, and maintaining those is exactly the kind of work that tooling projects in this space hand back to the user.

The universal mods feature is a related acknowledgement. Rather than per-title fixes, it unlocks the game console and other capabilities that work generally, which is the approach to take when you want the same effect across many games instead of a deep hook in one.

Practical takeaway: before committing to a project, identify the game and its engine version, then check the custom game configs documentation and the issue tracker. If someone has already added your title, your odds are good. If not, budget for signature work, and read the compatibility guide that the README links for fixing compatibility problems.

Building it needs MSVC with C++23, Rust, CMake and a linked Epic account

The build requirements are strict enough to be worth quoting in full, because they are the first thing that rules a machine out.

You need Windows; the README says Linux support might happen at some point but not soon. You need an MSVC that supports C++23, specified as toolset version 14.43.0 or newer, MSVC version 19.43 or newer, and Visual Studio 17.13 or newer. You need a Rust toolchain of at least 1.73.0, CMake of at least 3.22, and either Ninja or MSVC as the build system.

Before compiling, you clone and initialise submodules recursively:

git submodule update --init --recursive

Two warnings come with that. Your GitHub account must be linked to your Epic Games account to get the Unreal source access needed for the pseudo code submodule. And you must not use the `--remote` option, because it forces third-party dependencies to their latest commits, which the README says can break things.

Build modes follow a naming scheme of `<Target>__<Config>__<Platform>`. Targets are Game for regular games on UE newer than 4.21, LessEqual421 for 4.21 and older, and CasePreserving for games built with case preservation enabled. Configurations are Dev, Debug, Shipping and Test. The only platform is Win64. The commands themselves are conventional CMake:

# Configure with Ninja (recommended for faster builds, single-configuration)
cmake -B build_cmake_Game__Shipping__Win64 -G Ninja -DCMAKE_BUILD_TYPE=Game__Shipping__Win64

# Build with Ninja
cmake --build build_cmake_Game__Shipping__Win64

The README also shows the MSVC generator as an alternative, which is multi-configuration and lets you switch configurations without reconfiguring, at the cost of needing an explicit `--config` flag on the build step.

The tree shows both `CMakeLists.txt` and `xmake.lua`, and the December 2024 release notes explain why: CMake was added alongside xmake, CMake is now the default, and xmake may be deprecated in future with no guaranteed ABI compatibility. If you find an old tutorial using xmake commands, that is the reason.

Known crash fixes live in the release notes, not the README

When UE4SS misbehaves, the troubleshooting that actually helps is distributed across release notes, and the 3.0.1 patch is the clearest example.

That release lists known issues with their solutions. If the GUI console is enabled and the window is blank or white at launch, set `GraphicsAPI = dx11` in `UE4SS-settings.ini`. If the game crashes at startup, set `bUseUObjectArrayCache = false` in the same file. If mods are not working as expected, follow their own install instructions rather than what used to work, because UE4SS supports multiple installation layouts. It also warns to delete the old `xinput1_3.dll`, which crashes the game if left in place, and notes that C++ mods must be rebuilt to work with 3.0.

That last cluster of details tells you the shape of the problems: config flags with specific names, a legacy DLL that must be removed, and binary compatibility between the host and compiled mods. All of it is the ordinary consequence of injecting into another process.

The settings file itself is named `UE4SS-settings.ini`, and the December 2024 notes confirm it has changed shape across major versions. The 3.0 notes instruct you to replace all existing files except the `UE4SS_Signatures` folder if your game uses custom signatures, and to back up settings changes before doing so. That folder is worth knowing about: it is where per-title signature fixes live, which is where you would add or update AOB patterns.

For live debugging there is also the property viewer, which lets you watch values change as the game runs. For mod authors that is often faster than reading a crash dump, because it shows the state before the failure rather than after it.

Editorial conclusion

UE4SS is a power tool with a specific expectation attached: the README states outright that it is not a plug-n-play solution that always works with every game, and that you may need to update AOB scans yourself. That sentence should govern your expectations of the whole project. What the repository gives you is unusually complete for this genre: a Lua API over the Unreal object system, a C++ modding path, blueprint mod loading that needs no game-file replacement, four categories of dumper, and a live property viewer for debugging. What it cannot give you is a guarantee for your specific title. Install the latest non-experimental build into the `ue4ss` subfolder beside the game executable, keep the proxy DLL in `Win64`, and if a game misbehaves read the known-issues list in the release notes before you start debugging your own mods.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. UE4SS-RE/RE-UE4SS on GitHub