Edit: Using the tool "dllexport" (https://github.com/3F/DllExport), you can create a .NET DLL that exports a function that is callable from C/C++ code. Just LoadLibrary and GetProcAddress.
Thanks to NativeAOT, though, it seems that you can do this kind of stuff without extra dependencies which is great too!
And exporting to WASM works nearly identically to DllExport.
I used that to shift all the heavy lifting to .NET 9 AOT compiled to WASM in a fun little side project I've been working on: https://evo.ryanpeden.com
I plan to put the source on GitHub shortly so others can use it as an example. Just need to clean things up a little first.
The DLL links to MSCOREE.DLL. When loaded into a process, the DLL can initialize the .NET runtime when necessary. The DLL's entry point is a jump to _CorDllMain within MSCOREE.DLL, which takes care of loading and initializing .NET if it hasn't been done before.
As for how it manages to initialize .NET from within DllMain (you're under DLL loader lock at this point), I don't know. It has to somehow get out of loader lock at some point before it loads a bunch of DLLs.
I have this idea in my head that I want this system to work even all the way up to letting people host their own servers that run their own mods without allowing them the power to do nefarious things to the clients who connect. This means a scripting language layer, most commonly LUA. For a bunch of reasons, many are vibes based, I've decided to go with a lisp instead.
After doing a bit of research I found this repo to use as a starting point.
https://github.com/microsoft/schemy
Checks all my boxes. Big ones being no new dependencies and not many lines of code. It took just a few minutes to get a handle on the whole thing end-to-end. I'm working right now on setting a little reflection metaprogramming that would expose any functions that I put an attribute above to the lisp layer.
There's a few things to delete so it's safe to serialize over the wire, but it looks like it'll enable what I'm after. I hope I can trust my serializers :D
What kinds of mods do you want to make?
I mostly do free-cameras, a way to detach the camera from the player to allow different angles that otherwise would be impossible to appreciate.
Lately I did a project to spawn lights on The Witcher 3 [1], to allow 'virtual photographers' to take some amazing portraits [2, 3], I did this by using Rust with a little bit of x86 assembly.
Rust has been neat for this, because despite working on a safety-hazardous territory, the amount of crashes has been minimal because we still have safeguards within the unsafe stuff, but sometimes I just want to not worry about lifetimes.
If you like games, you can check this amazing gallery from the FRAMED community to see the extents the people do to take amazing shots within games engines (and admittedly, external tools like reshade, mods, etc):
https://framedsc.com/HallOfFramed
[1] https://github.com/etra0/litcher
[2] https://framedsc.com/HallOfFramed/?game=The+Witcher+3&title=...
[3] https://framedsc.com/HallOfFramed/?game=The+Witcher+3&title=...
I've never done anything like that. I can imagine getting the memory offsets for things like camera transforms being reasonably straight forward with cheat engine, but mutating the values feels a like converting a train from diesel to electric while it's carrying a load. It reminds me of something Ross Scott (he makes youtube videos about games) has expressed a desire to have -- the ability to comprehensively map and record the 3d worlds of games that are going to get shut down. Admittedly I initially dismissed it a little on the grounds that if you want that, just extract the 3d model data from the client and load up blender.
Seeing what you and others have done is making me appreciate what he's after more. The whole composition, environments and characters and lighting and visual effects and post processing would not be preserved just by yanking out the .fbx files and textures. A lot would be lost. Despite being a gamedev myself, seems like I somehow lost the perspective a little.
It's awesome to see there's a community and a hobby doing what you're doing. Thanks for showing this to me.
Thanks for your kind words!
> How hard was it to get your foot in the door on having code execute on an already running process? Do you do this from a separate process at runtime or is it all modifying the executable before you run it?
All is done at runtime. By nature of how Windows DLL work, they have a DllMain that's executed every time you load a dynamic library into a running process. From there you spawn a thread and you can do pretty much whatever you want within the same memory space of the games. There are multiple ways of injecting a DLL into a running process, and since I only care about offline games, I don't have to fight against any anticheat and stuff so it is pretty straightforward, it is a very interesting topic to read about to be honest!
> I can imagine getting the memory offsets for things like camera transforms being reasonably straight forward with cheat engine
Cheat Engine is an amazing tool, for real. I remember using it when I was a kid to do very rudimentary cheating -- just scanning and changing values; years have passed and one day I opened Cheat Engine again to... skip over an annoying mechanic of a game and I noticed it can do so much more! it has a very good debugger, disassembler, memory view, you can even inject your own assembly code. It was the gateway drug that I needed to get started on everything I do.
> but mutating the values feels a like converting a train from diesel to electric while it's carrying a load
Well, compilers are pretty straightforward (at least, most of the time), it's all about memory layout.
If you have something like
struct vec {
float x;
float y;
float z;
};
And as long as you know your programming language has a stable memory layout, you can map it from your code. I even was able to map some very basic virtual class from C++ within Rust by mapping the virtual tables.
What I enjoy the most, is that I learned a lot about low-level programming, assembly, how OS and compilers work together, while having fun playing games, and developing tools that people can use to create pretty images -- it felt like the outcome was extremely positive and it brings me a lot of joy.
I guess I imagined more challenges in not getting any writes you do stomped by some other code that really wants to set a value on your vec every frame. Maybe I'm overthinking it and it's an easy happy path to get your injection to occur "at the end of the update" where your assignment actually makes it to the screen.
Cheers.