-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
QModManager 4.0 - Migration to a BepInEx plugin #155
Conversation
At this time, it seems this method is not viable. The proof of concept attached and developed in this PR does work under some circumstances, but is failing for many mods - specifically mods loading assets like textures or assetbundles. @PrimeSonic and I attempted to find a workaround for several hours and were unsuccessful. I'm going to investigate the possibility of working with our own doorstop so that we are not using BepInEx, but get most of the same advantages. We won't be able to interop easily with BepInEx plugins, but we should be able to exist alongside many of them without issue, which is still a win. Closing the PR. |
…not needed for QMMLoader
… use that as our entry point to avoid issues with loading assets, which was previously caused by QMMLoader running patch methods and loading QMods during UnityEngine.CoreModule's Application constructor, which was too early.
This PR is not dead after all! It turns out, BepInEx was initialising our plugin using For now, instead of altering the BepInEx config, I think it is wiser to instead use a Harmony patch on The .zip in the initial comment above outlining the proposal has been updated with a build reflecting these changes. Re-opening PR! Have fun testing :) |
…ily understandable what's going on. Also added [Obsolete] attribute where appropriate, in a similar manner to QModManager's entry point.
…e mod.json weren't being considered by the validator or the factory's ValidateDependencies method." This reverts commit 2eb96fa.
…ins from QMods and vice versa via a patcher. QMods generate BepInEx plugin components which expose their IQMod metadata for easy BepInEx use.
Added preliminary BepInEx plugin <-> QMod mod interop. BepInEx plugins can depend on QMods: [BepInDependency("SMLHelper")]
[BepInPlugin("MyCoolPlugin", "My Cool Plugin", "1.0")]
class MyBepInExPlugin : BaseUnityPlugin {
// ...
} QMods can depend on BepInEx plugins: "Dependencies": [
"RuntimeUnityEditor"
] Works with versioned dependencies too, as well as load after/load before. However, due to the nature of how QMods waits until Build attached for testing. |
…need to verify game files/reinstall game.
…eDir\qmodmanager_log_{process}_{timestamp}.txt`
BZ Experimental [branch]
SN1 and BZ |
BZ Experimental [branch]SN1 and BZAt this point I'm calling this done except for bug fixes. |
Downloads for Beta Testers
BZ Experimental
SN1 and BZ
Proposal: Migrate to a BepInEx plugin for loading QModManager rather than making permanent patches to the game files.
BepInEx makes use of a doorstop approach for running entry points. It relies on Harmony, Mono.Cecil, MonoMod among others, and from my testing for the past few weeks it appears quite mature. BepInEx is currently used as the primary modding framework for Risk of Rain 2 and Outward, among others.
Advantages
Disadvantages
Implementation
This PR is a proof of concept and potential initial release for this proposal. Notably, I've added three projects:
QMods can continue to be developed as they were before, bundled up and put in the QMods directory. QModManager takes care of all of their dependencies as it always has.
In my testing I have so far not identified any mods that cause issues, but I'm only one guy and I can't test every QMod that exists. Please see the attached QModManager_Setup.zip at the bottom for a build if you want to give it a whirl without compiling it yourself. Zip includes installer built with Inno Setup, which handles migrating from previous QModManager and installing BepInEx.
Thoughts, concerns? Lemme have it.