Plugin Integration
RPGReact works by replacing significant portions of the RPG Maker MZ core engine functionality with React-driven equivalents. Because of this architectural choice, there are specific considerations when using it alongside other plugins (like VisuStella, Yanfly, etc.).
The Nature of Overrides
Many of the core scenes in RPGReact (e.g., Scene_Map, Scene_Battle, Scene_Menu) are replaced by overrides that do not always delegate back to the original core engine methods.
For example, in override_scene_map.js:
Scene_Map.prototype.initialize = function() {
Scene_Message.prototype.initialize.call(this);
// ... custom initialization
};In this case, the standard Scene_Base.prototype.initialize (which Scene_Map normally calls) is bypassed in favor of a direct call to Scene_Message, or it might skip the chain entirely.
Why this happens
RPGReact often needs to suppress standard RPG Maker window creation or input handling to allow the React UI to take precedence. "Hard" overrides ensure that standard windows don't flicker or consume input when they shouldn't.
Common Conflict Symptoms
Functionality Breaks: A plugin that expects to add a window to
Scene_Mapmay fail because RPGReact has rewritten thecreateorstartmethods without calling the "original" version where that plugin's hook lives.Input Hijacking: Other plugins that hook into
InputorTouchInputmight find their logic bypassed if RPGReact's overrides prevent the engine from processing those events in the standard way.React UI Breaks: If another plugin is placed after RPGReact and it also performs hard overrides, it might break the connection between the engine and the React bridge.
Best Practices for Integration
1. Understanding Plugin Compatibility
There is no "magic bullet" plugin order for RPGReact. Because it overrides core methods, you must investigate any plugin you intend to use alongside it to understand what it modifies and whether those modifications conflict with RPGReact's overrides.
2. Recommended Plugin Order
While ordering alone isn't a guarantee, the following general guidelines apply:
RPGReact first: Other plugins should generally live downstream (after) RPGReact in the plugin list. This allows downstream plugins to potentially override RPGReact's behavior if needed, rather than RPGReact unconditionally overwriting them.
Core Libraries above RPGReact: Essential libraries (like
PluginCommonBase.js) should remain above RPGReact.
3. Load Ordering and Timing
RPGReact loads its overrides asynchronously after the React application has initialized. This typically happens during or after Scene_Boot.
Implications:
Even if RPGReact is high in the plugin list, its actual method overrides may be applied after other plugins have already initialized and performed their own hooks.
If a downstream plugin relies on hooking a method at boot time, it may find its hook replaced by RPGReact once the React bridge is ready.
4. Modifying RPGReact Overrides
If you find that a critical plugin is broken because RPGReact doesn't delegate a method, you can modify the stock overrides or add a custom override to restore the delegation chain.
Standard Pattern (May break React UI):
Note: Be careful when doing this. Calling the original method might instantiate standard MZ Windows that RPGReact is trying to hide.
5. Using Custom Overrides
Instead of modifying the core RPGReact.js or stock override files, use the Custom Overrides system. You can create a custom override that hooks into the methods needed by your other plugins and ensures the delegation chain remains intact.
Known Incompatibilities
Heavy Scene Overhauls: Plugins that completely replace
Scene_MaporScene_Battlelogic will likely conflict with RPGReact's goal of moving that UI to React.Alternative Input Managers: Plugins that take exclusive control of keyboard/mouse input may prevent the React UI from receiving focus or interaction.
Getting Help
If you encounter a conflict with a popular plugin, please check the Troubleshooting guide or reach out with the specific plugin name and the nature of the error.
Last updated