REFramework: one DLL into the game folder, and what it does not fix

dinput8.dll is the whole non-VR install

For a non-VR setup the install is one file. You download a build, open the zip, and extract only `dinput8.dll` into the game folder, which for a Steam library looks like this:

G:\SteamLibrary\steamapps\common\RESIDENT EVIL 2 BIOHAZARD RE2

That is the entire procedure, and it covers both DirectX 11 and DirectX 12. Nothing has to be configured afterwards, and the Linux instructions further down name that same DLL in a Wine override, which is what tells you the game itself is what loads the file. VR is the other case. You install SteamVR first, unless you are on OpenXR with a supported headset, and you extract the whole zip into the game folder rather than one file from it. The wider extraction matters: the VR support ships with its own runtime pieces, so a VR install changes much more of the game directory than a non-VR one does, and the project keeps a separate VR troubleshooting FAQ for when that goes wrong.

Proton needs a launch option you add by hand, per game

On Linux the extraction is only half of the job. After the files are in place you add a launch option to the game through Steam's properties:

WINEDLLOVERRIDES="dinput8.dll=n,b" %command%

The `n,b` pair tells Wine to use its native dinput8.dll rather than its builtin one, and `%command%` leaves the original launch command intact. Two consequences follow. The option is stored per game, so every title you want to modify needs it added again, and when a game suddenly starts without your mods the first question is which titles you actually touched. The second is order: the option is applied after extraction, so an install done the other way round leaves you deciding between a missing file and a bad override. The documented Linux path is the Proton one, which makes this a Wine route rather than a native build.

Generic mods say all games, the per-game ones name their titles

The mod list has two tiers, and the difference decides whether the framework is useful to you. The generic tier is marked all games: free camera, scene timescale, FOV slider, vignette disabler, ultrawide and aspect ratio fixes, and a GUI hider or disabler. The per-game tier names its targets, and the spread is uneven. First person covers RE2 and RE3. The manual flashlight covers RE2, RE3 and RE8. VR motion controls cover RE2, RE3, RE7 and RE8, while generic 6DOF VR support is the exception that reaches everything. So if what you want is a first-person view or motion controls, you have to own one of the named games, and there is no version of either for Dragon's Dogma 2 or the Monster Hunter entries. The supported list itself is nineteen titles, running from Resident Evil 2 to Mega Man Star Force Legacy Collection, so reach is not the limit. Feature coverage per game is.

v1.5.9.1 shipped on 2025-03-05, so new games mean a nightly build

The two release channels are not in step. The last tagged releases are v1.5.9.1 on 2025-03-05, v1.5.9 on 2025-03-04 and v1.5.8 on 2024-10-25, while the last push to the repository was on 2026-11-01, on a branch whose default is master. Work is still landing, but the tagged builds have not moved in a year and a half, and the README routes you accordingly: the last stable build comes from the Releases page, newer builds come from a separate Nightly Developer Builds repository. That split has a direct cost for anyone chasing a recent title. Onimusha: Way of the Sword, the Mega Man Star Force collection and Resident Evil Requiem all appear in the supported list, and a zip from March 2025 is not what taught the framework about them. If the stable install does not list your game, nothing is broken. You are one channel behind, and the fix is the nightly repository rather than a reinstall.

The Lua API is the extension path, and the object tools are off by default

The framework ships a Lua scripting API and plugin system that apply to every supported game, with its own reference documentation, and two developer tools that live behind a mode you have to switch on: Game Objects Display and Object Explorer. Those two are what you want open before writing a line of Lua, because they show the live object graph of the running game, and without them a script is a guess at names and fields. The repository also carries a csharp-api/ directory, so a C# surface sits alongside the C++ core, and examples/ holds two worked plugins, example_plugin and weapon_stay_big_plugin, which are the shortest way to see how a mod attaches itself. None of this is a no-code route. Every mod in the list was written by a person, and the framework is the platform they wrote it on rather than a catalogue that adapts itself to your game.

Building it is a Visual Studio, CMake and submodule job

The build system is Windows-shaped and says so in the file names. At the root sit build_vs2022.bat, build_vs2022_noautogen.bat, build_vs2026.bat and MakeCommitHash.bat, driven by a CMakeLists.txt with CMakePresets.json and cmkr.cmake, and formatted by .clang-format and .clang-tidy. The tree also carries a .gitmodules file and a dependencies/ directory. COMPILING.md is the document to read before you start. The primary language is C++ and the licence is MIT, with LICENSE in the root of the tree, and the reverse engineering work has its own reversing/ directory next to include/, shared/ and src/. For most readers those batch files are irrelevant, since the release zip is the supported way in, but they explain why there is no single cross-platform build command to copy.

What the framework will not do for your game

Three limits deserve to be stated before you extract anything. Coverage is per title, not per feature, and the bundled fixes are narrow and named: an RE8 startup crash, RE8 stutters when killing enemies or taking damage, and MHRise and RE8 crashes caused by third party DLLs. Nothing in that list makes an unlisted game supported. The developer tools are off until you enable them, so the object-level inspection modders depend on is something you switch on rather than something you get. And a VR install extracts the whole zip over your game directory, which is a wider change than the one-file non-VR path and the reason the VR troubleshooting FAQ is a separate document. Against those, the foundation is broad: the same all-games tier, the Lua API and the 6DOF VR layer apply whether you own Resident Evil 2, Devil May Cry 5, Street Fighter 6, Kunitsu-Gami: Path of the Goddess or Ghosts 'n Goblins Resurrection. The platform is uniform, the per-game mods are not.

Editorial conclusion

Adopt REFramework if your game is on the supported list and what you want is VR, a free camera, or a Lua surface to write your own mod on, and expect to install a nightly build rather than a tagged release. Do not adopt it for a title whose only listed mods are the generic ones, or to make an unsupported game work. Verify first which channel your game needs: install the stable zip, and if the title does not appear, move to the nightly repository before writing any Lua.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes