fezmodding / hat Goto Github PK

Currently, only the main game's loop is properly handling exception (by having everything enclosed in one giant try-catch with logging on exception by default). However, HAT does some initialization before this block is reached. In order to properly log issues on mod initialization, it should be enclosed in a similar try-catch block as well.

One of binaries used for generating common hooks library (most likely FEZ.exe) relies on Steamworks.NET.dll on Steam version of the game, which, as you may guess, is not present on other versions of the game. However, MonoMod requires it during patching process as a dependency because Hooks library is dependent on it.

Solution is quite simple: exclude Steamworks.NET.dll dependency from the hooks library. Not sure how; I'm hoping there's a way to do it at any stage of hook library generation (HookGen or ILRepack). If not, I might need to get crafty... or just use non-steam FEZ version to generate the library lol

Presumably isolating FEZ.Hooks.dll into a separate file wasn't the greatest idea - the game is unable to load the library properly when any mod is requesting its usage.

Not sure how hard it is right now, but custom code implemented in the game components of the mod should be able to easily identify themselves. This can be done by returning a mod structure when given specific component to a static instance of HAT, but there might be a more elegant solution. Having such simple identity system might help us create a configuration system, because then such configurations could be stored in the mod structure itself, and could be easily accessible by the mod at any point (related to #10)

MonoMod gives a way of making private/protected stuff from original binaries public. We should take advantage of that and make menu functions and structures open for modders. This would make creating custom menus for mods significantly easier.

The idea is to allow modders to load both packed and converted content for a sake of easier modding process and efficient distribution. Here's a mini-roadmap:

• Finish FEZRepacker's base (maybe even look for optimizing memory usage).
• Implement Repacker into HAT.
• Add ability to load PAK packages named "Assets.pak" if present.
• Add ability to load converted assets (like PNG files, FEZAO file bundles etc.) instead of converted XNB files.
• #17

MonoMod has a neat thing called HookGen that we should totally take advantage of. It generally feels like a safer alternative to Detours in this multi-mod environment, as all hooks are handled by a centralized system instead of each mod having their own independent detour handler, which can cause an issue if we happen to mess with them dynamically during runtime.

The idea is to generate MMHook library for every (or at least the most useful ones) FEZ binaries and merge them together with il-repack, then include the binary as part of HAT. Optionally, it would be nice to have it as a compilation process in case the game ever happens to update for whatever reason.

These informations should be save somewhere in a common file for HAT to determine how to handle mods:

• enabled state of the mod (whether the mod should load or not)
• mod version to load (by default, loads the newest one)
• custom ordering of mods (a secondary, after dependency priority, user-based ordering for resolving asset conflicts)

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.

It would be nice if HAT exposed an easy way to save and load configuration files for mods, based on some structure defined by individual mods.

HAT could take advantage of such configuration system itself, storing some basic configuration options like custom logo text.
Heavily related to #3 and #4.

Tested on release v1.0.2

Steps to reproduce:

1. open HAT modded FEZ
2. load a save slot
3. go to "help & options" > "save management" > "change slot"
4. select a different slot
5. press enter to advance past the "HAT" logo

Currently, mods aren't ordered by their dependencies, which means a mod which is dependent on another mod can execute before its dependency, which could cause unwanted and unpredictable behavior. Additionally, current dependency loop detection isn't fully functional (can't detect loops of more than 2 mods). This needs to be fixed.

Implement advanced asset manager which will properly cache assets and convert/load them only when necessary.

Currently, HAT doesn't check if metadata file doesn't exist in a mod directory, which is stupid, because that's how mod loader should recognise a directory as being a mod in the first place lol