REFramework: Install, Proton Setup and Troubleshooting

What REFramework provides

REFramework is a mod loader and scripting environment for supported RE Engine games. It supplies a foundation used by community scripts and plugins rather than acting as an official CAPCOM utility. Installing the framework prepares that environment, but it does not automatically install the gameplay feature from every mod that depends on it.

Keep the loader and each dependent download separate in your installation plan. A script can have its own files, configuration and compatibility requirements in addition to needing REFramework. Understanding that relationship makes it easier to identify whether a missing feature comes from the loader setup or from the individual mod's instructions.

Choose a release for the correct game

Use the maintainer's release history and instructions when selecting an archive. The README also links nightly builds when a newer supported build is needed. A package for another RE Engine game should not be assumed to be the correct package for Dragon's Dogma 2 merely because the framework supports both titles.

Read the current release information before replacing an existing DLL. The appropriate choice depends on the support described for the game version you have installed. A newer upload date can be useful context, but the version's documented scope is more important than simply selecting the largest archive or copying a file from an unrelated tutorial.

Normal non-VR installation

The maintainer's normal non-VR instruction is to extract only dinput8.dll from the appropriate release archive. Place that file in the game folder, beside the executable. This placement is specific to the loader and should not be generalized into a claim that every script or mod archive belongs in the same location.

Confirm the destination before copying the file, especially if you maintain more than one game installation. An archive sitting in a downloads folder is not the same as the DLL being beside the game executable. After installing the loader, follow the chosen mod's instructions for the rest of its files rather than guessing a universal folder layout.

Proton and Linux launch option

The documented Steam launch option is WINEDLLOVERRIDES="dinput8.dll=n,b" %command%. The maintainer uses that instruction for loading the DLL through Proton. Preserve the spelling and quotation marks when entering it, since a descriptive paraphrase of the setting is not the same as the actual launch option.

This instruction establishes the loading step, not a guarantee that every third-party script works on Linux or Steam Deck. Review the individual mod's requirements as well as the framework documentation. If the unmodified game works but a particular script does not, investigate that script's supported setup rather than treating the DLL override as a universal compatibility switch.

Install scripts and plugins separately

Once the loader is installed, return to the dependent mod's author instructions. Different downloads can require different files, directories or supporting components. The framework README explains the loader, while the individual project explains how its own feature should be installed into that environment.

Add one documented component at a time so you can check the result of each installation. Keep the downloaded archive and the instructions available while testing. If a feature fails to appear, compare the actual file placement and dependency versions with the author's requirements before changing unrelated game settings or adding another mod.

REFramework and Fluffy have different jobs

Fluffy Mod Manager handles supported packaged replacements, while REFramework provides a loader and scripting platform. One tool does not replace the other just because both are used in PC modding. A specific download may need one or both, depending on the way its author packaged and implemented it.

Use the PC mod guide when deciding which workflow a download expects. If a replacement is managed through Fluffy, enable and disable it through that workflow. If a script requires REFramework, meet the loader requirement and follow its separate file instructions instead of attempting to treat the script as an arbitrary replacement archive.

Troubleshooting after a game update

If the game stops launching after an update, test the unmodified installation first. Temporarily remove the framework DLL and any added plugins, then check whether the base game starts. This separates the updated game's behavior from the extra components that were installed against an earlier version.

When the unmodified game works, reinstall a framework build documented for the current game and reintroduce dependencies one at a time. Test after each addition so the component associated with a returning failure is identifiable. A previous working setup is useful history, but it does not establish compatibility after official files or interfaces change.

Removing extra files versus repairing official files

Keep track of the DLL and plugin files you added manually. Repairing official files does not necessarily delete third-party files that were never part of the game installation. A loader left beside the executable can still affect startup even after a file-verification operation completes successfully.

Use the installation record and the project's removal instructions when preparing a clean test. Move the added component aside rather than losing the information about where it came from. Once you have a working baseline, restore only the currently supported pieces required for the feature you are trying to use.

Graphics tutorials and current official options

Older tutorials may use REFramework-dependent mods to provide graphics features. The current game has official graphics additions, so an old tutorial is not automatically a requirement for obtaining a similarly named option today. Compare the official settings available on your hardware with the particular mod's purpose before installing it.

The patch guide separates PC graphics additions from platform-specific console changes. It does not establish a performance benchmark for your machine, and neither does the presence of a framework DLL. Decide based on the documented feature and supported setup rather than a universal promise of improved frame rate.

A repeatable setup check

Verify the game version, choose the appropriate maintainer release and place the non-VR DLL beside the correct executable. On Proton, check the documented Steam launch option, then install the particular script according to its own instructions. Test the result before expanding the setup with another dependency or plugin.

If a later update breaks that setup, return to the unmodified baseline and repeat the supported-version checks. The release history establishes available builds, while each mod author establishes the instructions for that mod. Keeping those responsibilities separate is the most useful way to install REFramework without assuming that one working loader proves every dependent feature is ready.

Common questions

What is the normal non-VR loader file? The maintainer instructs users to extract the appropriate archive's dinput8.dll beside the game executable. This is the loader placement, not the universal destination for every dependent mod file. Follow the individual script's instructions afterward rather than dropping all of its archive contents into the same folder by assumption.

Does the Proton override guarantee script support? The documented override establishes how the DLL is loaded through Proton. It does not certify every script or plugin for Linux or Steam Deck. Check the dependent project's instructions and supported version before treating a successfully loaded framework as proof that its entire mod ecosystem works on your setup.

What should I test first after an update breaks startup? Temporarily isolate the framework DLL and added plugins, then test the unmodified game. Restore a supported loader and dependencies one at a time after establishing that baseline. This identifies the addition associated with a returning failure without assuming every crash comes from the same file or has one universal fix.