Something that came up... while I was swimming...
In Reloaded-II have the concept of shared libraries (dynamic linking - but in .NET).
We also have the ability to unload/load/reload mods at runtime.
However, in order to support unloading, a mod must explicitly opt-in, and manually handle the Unload event to e.g. uninstall hooks.
That could be error prone at scale, for instance; for very big mods; the feature also saw very little adoption as the ability to load/unload was hidden behind a hard to find location (clicking on process label in list).
6 years of experience with R2 mods however reveals, that in most cases, the only thing that needs to be 'undone' for unloading is hooks. Not too many mods do direct code patches.
Therefore; by tracking state (i.e. hooks) inside the shared library, and by providing an abstraction over patching game code with raw bytes (or asm); we should be able to automatically undo changes made by a given mod. i.e. Automated unload implementation more-less.
Something that came up... while I was swimming...
In Reloaded-II have the concept of shared libraries (dynamic linking - but in .NET).
We also have the ability to unload/load/reload mods at runtime.
However, in order to support unloading, a mod must explicitly opt-in, and manually handle the
Unloadevent to e.g. uninstall hooks.That could be error prone at scale, for instance; for very big mods; the feature also saw very little adoption as the ability to load/unload was hidden behind a hard to find location (clicking on process label in list).
6 years of experience with R2 mods however reveals, that in most cases, the only thing that needs to be 'undone' for unloading is hooks. Not too many mods do direct code patches.
Therefore; by tracking state (i.e. hooks) inside the shared library, and by providing an abstraction over patching game code with raw bytes (or asm); we should be able to automatically undo changes made by a given mod. i.e. Automated
unloadimplementation more-less.