Can I use .NET to write business logic for external function hooks?

[Albeoris]

Hi, @julianxhokaxhiu!

Hello, I would like to contribute to this project (for example, implement a turn-based combat system similar to what I did for Final Fantasy IX or loading texts from external .resjson files for easier localization).

But I am very bad at C/C++, and I also think that this is a very dangerous language for developing such mods, since it is easy to generate AccessViolation and crash the game process.

At the same time, I know .NET well and actively write game logic mods on it for various games, including games written in C/C++.

Ideological question: can I raise the .NET domain inside the game process and write hook logic in C#? This will require the .NET Runtime and will slightly increase memory consumption (theoretically, we can make mods based on .NET optional to avoid id).

[julianxhokaxhiu]

Hello @Albeoris nice to see you here :) And thanks for rising this discussion, it's a very interesting one to unpack.

While the integration can technically be done, it's not an easy one to tackle. We've done this already in 7th Heaven ( see the C++ loader that loads the .NET VM inside the native binary, the bridge between the C++ layer and the .NET layer, and finally the real .NET binary that we make use of to load mods ).

Assuming the mod will be distributed with 7th Heaven my first idea would be to see how we could extend this layer to additional external .NET libraries that might want to manipulate the game memory, which I'm not against it but I've never explored it. If you're willing to take the adventure I'll be happy to support. I think it would make an interesting use case, and would open doors to .NET mods ( as we have the VM loaded anyway ).

Let me know what you think, open for feedback! Thanks

P.S.: https://github.com/quantumpencil did start something very similar back then, his mod is named SisterRay and it was supposed to tackle exactly the same area. You might want to have a talk with him as well, although the mod is supposed to be implemented in C++. Anyway it's safe enough to try.

[Albeoris]

@julianxhokaxhiu what do you think about Reloaded Hooks project?

https://reloaded-project.github.io/Reloaded-II/CheatSheet/CallingHookingGameFunctions/

It seems to me that it copes with the task perfectly, while supporting flexible configuration of Calling Conversion and does not require writing complex logic for mapping functions.

[julianxhokaxhiu]

Looks like to be a good choice but I think you'll have to include it in your own mod, as it seems to be a framework to hook native addresses to .NET, which is something we do already in FFNx natively. On 7th the .NET integration is mostly to hook Win32 Kernel calls, but we'll have to open a bridge to load custom DLLs ( that are detected based on mods enabled ). Then what is inside the mod, doesn't really matter, you can use Reloaded Hooks or make it completely manual using C# unsafe :)

[Albeoris]

Yes, I agree with you.

There are two cons:

1. If external mods carry Reloaded Hooks with them, this may result in them trying to use DLLs of different versions.

2. External mods will not be able to interact with FFNx. To open the door to .NET modders, it seems that FFNx needs to provide a .NET API for integration.

Probably, I should try to make a prototype of such a mod and see what happens. .-.

P.S. About unsafe, yes, I also did such things using unsafe code, C++/CLI and Detours:
https://github.com/Albeoris/Septerra/blob/master/Septerra.Injection/Hooks/Septerra_DbRecord_Read.hpp

But in this case there is no static validation, marshaling has to be written manually, and AccessViolation is back in play. :'D

[julianxhokaxhiu]

Yeah, been there, done that. 7thWrapperProxy went through the same pain but I managed to abstract that quite a lot, although all the dirty work is done there to make as transparent as possible the bridge. There's no optimal way :(

Regarding point 1, yes, that's absolutely the case and you're right. Although we can hope .NET is smart enough to keep the newest version in memory despite being asked to load nth times the same DLL.

About point 2, yes also true but there's a long standing issue open that is about open APIs to external mods ( see #74 ) for ImGui, although not sure which kind of APIs you need from FFNx in this case. What did you have in mind?

[Albeoris]

is smart enough to keep the newest version

The first loaded. :)
But it'll work only if the library is a binary-compatible.
If the first mod loaded version 1 with method Do(int), and the second one trying to load version 2 where the signature of this method is Do(int,int), the second mod will fail because version 1 of the library was already loaded and doesn't contain method Do with signature Do(int,int).
So it's better to provide the single (latest stable) version of the library for external mods.

not sure which kind of APIs you need from FFNx in this case. What did you have in mind?

For example, I want to export all texts from the game in .resjson format and load them on the fly into the game. At the same time, FFNx has its own system for exporting background textures. These procedures will be completely independent and it will be impossible to combine them into a single workflow. This also works in the opposite direction. For example, FFNx has an is_game_paused API, which will not be available from an external mod.