Closed AMacro closed 7 months ago
I will have to review and confer with some other people before this can be merged. Additionally there are merge conflicts that need resolving prior to merge.
I believe I've fixed the conflicts in my branch, the remaining ones may be due to folder structure changes.
I will only say to this extent that there is the potential of an official mod loader in the works. From what I hear the modloader will be more similar to how Harmony patches mods then how unity mod manager patches mods.
Just letting you guys know that your mod does NOT work. Does not install a "Plugins" folder into the BepInEx folder after launching the game then closing it again. #broken mod.
Just letting you guys know that your mod does NOT work. Does not install a "Plugins" folder into the BepInEx folder after launching the game then closing it again. #broken mod.
@Tex5021, This should have been raised as an issue, not a reply to a Pull Request.
Having said that, I had the same "issue", and just manually created the folder... but, that's not the mod's fault, that's BepInEx's fault. BepInEx is the mod manager/loader and the plugin folder belongs to it. You can put multiple mods in the plugin folder and BepInEx will load them all.
I will only say to this extent that there is the potential of an official mod loader in the works.
Official mod support would be awesome, but not going to get my hopes up until I see it; a few games have had it on their roadmap, but it's always right at the bottom and I'm yet to see any of them implement it :( (I suppose it has a high pain/gain ratio).
From what I hear the modloader will be more similar to how Harmony patches mods than how unity mod manager patches mods.
As far as I can tell both BIE and UMM do the same thing - i.e. both use doorstop to get themselves injected into the game, then they inject each mod using Assembly.Load() from System.Reflaction. Once loaded, mods targetting either framework use Harmony to patch the game.
The only real difference I can see is UMM appears to be more end-user friendly (the Derail Valley modding community switched from UMM to BEI, but ultimately switched back to UMM due to user complaints).
Anyway, that aside, in the proposed changes I removed the logger and settings modules from the core and implemented interfaces to allow the BepInEx and UMM loader stubs to expose their own methods - this allows each stub to implement the corresponding mod-loader's framework features (e.g. settings management and logging), but does mean having to maintain the settings code and logging code in two places. If it is preferable, I could rework this and implement a settings GUI, then only the logging interface would be required; this would be better for maintainability and useability.
Ultimately, it's your mod and your choice if you want to support UMM or not; I'm happy to work with you to make it happen, but I won't be hurt if you choose not to support it.
Merged into experimental UMM Branch.
I copied and renamed the Directory.Build.Targets.example to Directory.Build.Targets but something does not seem correct. I am getting several reference path property failures. I am a bit unfamiliar with this type of project setup.
@AMacro I am sure I am just overlooking something simple.
@AMacro Sorted it out there was something going on with visual studio until I ran clean build.
Split mod loading functionality into 2 separate projects.
Core mod functionality is stored in RouteManager, whilst RouteManager.BepInEx contains the interface for BepInEx and RouteManager.UMM contains the interface for Unity Mod Manager.
Post-build the core RouteManager and the interface (BepInEx/UMM) assemblies are merged to produce a single self contained assembly for each mod loader.
If the Build Config is set to Release then zip files containing the assemblies and any supporting files will be generated in the root\Release folder.
Custom game paths should now be set in Directory.Build.targets.
Mod version should now be set in RouteManager\Properties\AssemblyInfo.cs and will automatically flow to the loader assemblies at build time.