Redforce04
commented
7 months ago With the dynamic patcher, we can actually do something like this for events. Whenever the event registers, we can store a list of the registered events, and use that to tell what events a plugin is using. It is easier if the plugin uses our system but it is theoretically possible to do for bepinex and melon plugins as well.
It gets trickier with harmony patches though. However if the patches are just transpilers / postfixes, and are implemented properly, it shouldn't still be safe for multi-plugin use.
I have considered the event priority idea. I like it but it may be tough to implement with default c# events, which is what the underlying events wrapper utilizes for core event handling. I will take a look.
Xilophor
Is your feature request related to a problem? Please describe.
TLDR: Mods need a way to de-conflict, but with so many mods modifying similar things, it becomes much harder to de-conflict
In the explosion of popularity for this game, many new people have made mods (many for their first time, myself included!) that do a wild variety of things, from new scrap pieces, new upgrades, harder difficulty, and much more. The issue is, many of the same things are targeted by said mods, especially dungeon/level generation, and many players are unknowingly slamming these conflicting mods together.
Creating code that avoids conflicts is an important standard for programming; however, it is not always possible to avoid conflict. This is where mods should label themselves as conflicting so that players don't run into issues due to conflicts. This is where the main problem lies: Many of these mods have special additions that players want to be able to use together.
Because of this, mods should try to de-conflict with each other during runtime. The issue is, there are so many mods out there it becomes impossible to de-conflict with every other mod out there - that's where I propose a solution.
Describe the solution you'd like
This API should have a method where mods can register what they modify - either specific methods (i.e. RoundManager.PlotOutEnemiesForNextHour) or more generically (i.e. dungeon generation). After all mods have specified their modified methods, the API should then send out (an) event(s) with what has been modified by multiple mods, at which point mods can de-conflict during runtime.
An optional addition is to include a priority system and send the mod with the highest priority with the events so said mod knows it doesn't have to de-conflict.
Describe alternatives you've considered
An alternative is to tell the player what mods are conflicting - although this starts to become like the BepInEx Modifiers - which can allow mods to not have to find every conflicting mod out there and instead just specify what they modify.
Additional context
Mods should only register what they modify if said modification(s) will cause conflict, not if they just modify a method.
As an example, say a mod adds a piece of scrap to the game by adding to the list/array (w/o an API/Lib, and I don't know enough about scrap to know if this is how it's done). The mod also changes the multiplier of all scrap values to be a specific multiplier.
The mod shouldn't register the method that adds a piece of scrap, as said method only adds to a list/array, but the mod should register the method that changes the scrapValueMultiplier to be a specific value. - Not a great example as there are easy ways to do this without conflict, but an example nevertheless.