Handle dependency bullshittery
Closed this issue · 1 comments
Currently, I've made FEZRepacker repacking (ironic) as a HAT's build process, so that all Repacker's dependencies are stored as a single assembly file. For whatever reason, it is actually required - deploying individual assemblies into the game's main directory works at first, but breaks at some weird circumstances (for instance, SDL library cannot be loaded but only for Textures converted by Repacker?!). This should be investigated further.
Additionally, the repacking process isn't the most elegant, as it's just repacking every single assembly except the HAT's one, which will no longer work properly if additional dependency is introduced into the system. A better method has to be checked out.
Dependencies are now handled by DependencyResolver.cs. Both Repacker and MonoMod dependencies are now expected to be in isolated directories inside "HATDependencies" directory ("FEZRepacker.Core" and "MonoMod" respectively). I am yet to configure the build process to automatically dump the dependencies into required directories.
On top of that, HAT should now be able to load additional dependencies from specific mod directories if a mod requests them, although this features has not been tested yet.
As a side note, SDL library not loading was the game's fault. There was an issue with loading Repacker's dependencies before, which caused incorrect conversion of a file. The game tried to load incorrect texture file and triggered a section of a code for raw texture loading which I did not know about. However, this piece of code doesn't work, which is usually fine since the game doesn't normally use it.
In any case, now incorrect assets should hopefully be filtered properly, so that won't be an issue anymore.