State and plans for this project

[HerrNamenlos123]

Hey there, I figured this would be the smartest way to reach out to you. I got very interested in G3 Modding (but on a fundamental level, not just adding quests).

I am new to G3 modding and so I don't know what the current best tools are and what is already possible, and what still needs to be done. I did a lot of reverse engineering and Decompiling using Ghidra, and additionally using Microsoft Detours as a Hooking library to redirect function calls between the DLLs.

Just like that I was able to:

• Intercept any Genome-Engine-Internal function call
• By redirecting it back to for example measure the time every call takes without changing the effect
• or return early, and thereby changing engine internal stuff. I was for example able to block all animations from being played.
• Knowing the internal memory layout of their classes. I can intercept calls, print the content of their private members or change them
• I am working on getting Animations to work (custom .xmot files)
• e.g. I also found and intercepted the eCVirtualFile::open() function that loads the packed files from the .pak archives. If I am able to change the result I might get G3 to load the raw files from disk instead of the virtual fs, eliminating packing completely for modders. Modding would be as simple as placing the raw file in a folder. Also, hot-reload would be possible.
• Additionally, since I can intercept calls and call functions myself, I am thinking about adding lua scripting, thereby creating a modkit with the shortest possible iteration time.
• Actually, my dream goal would be to improve combat mechanics and add combat levels like in G1 and G2, but it turns out it currently isn't possible because nobody can reverse engineer the .xmot file format. I hope to do it by decompiling the decoding algorithm itself and I am very close I think. Well, that's where I am right now.

Now, I did all if that without your repo. I just found it and saw you have the class declarations, which makes it significantly easier for me, as well allow me to just use their classes as usual. What I have what you don't (i assume) is access to and knowledge of public and private member variables.

What I am getting at: Are you still active in this field? It turns out more things than expected are similar of what we did. And a bit of team work or at least coordination between us and others would be very helpful. I would love to make something possible that isn't yet :)

EDIT: I knew your repo, but unfortunately I did not really find a way to use it, or it did not seem that anything in it is really useful for me. I still have to take a closer look at it, so apologize if I missed some things that are already there...

[georgeto]

Hi and welcome to the wasteland of G3 modding ;)

Just like that I was able to:

* Intercept any Genome-Engine-Internal function call

* By redirecting it back to for example measure the time every call takes without changing the effect

* or return early, and thereby changing engine internal stuff. I was for example able to block all animations from being played.

* Knowing the internal memory layout of their classes. I can intercept calls, print the content of their private members or change them

Yes, such hooks and even more invasive methods (like inserting hooks/patches inside a function) are often necessary.
The gothic3sdk also provides support for these techniques, they are also used in the example projects, such as here, here and here.

---

* e.g. I also found and intercepted the eCVirtualFile::open() function that loads the packed files from the .pak archives. If I am able to change the result I might get G3 to load the raw files from disk instead of the virtual fs, eliminating packing completely for modders. Modding would be as simple as placing the raw file in a folder. Also, hot-reload would be possible.

Using folders instead of packed files is already possible, i.e. is supported by the unmodified original game.
If both a pak files (e.g. Templates.pak, Templates.p00) and a corresponding Templates folder, the folder has a higher priority, i.e. it is mapped in the virtual file system on top of the pak files (same prioritization mechanism as exists between pak files, .p00, .p01, ...).

Hot-reload, however, is not possible. But at least for textures (.ximg) I implemented hot-reload via the newly added File Reload console command. For the code that implements it see here.

---

* Additionally, since I can intercept calls and call functions myself, I am thinking about adding lua scripting, thereby creating a modkit with the shortest possible iteration time.

That would indeed be a neat thing to have!
I did something similar, a Python binding for Gothic 3 (using SWIG), but never finished/released it :/

---

* I am working on getting Animations to work (custom .xmot files)

* Actually, my dream goal would be to improve combat mechanics and add combat levels like in G1 and G2, but it turns out it currently isn't possible because nobody can reverse engineer the .xmot file format. I hope to do it by decompiling the decoding algorithm itself and I 

What I am getting at: Are you still active in this field? It turns out more things than expected are similar of what we did. And a bit of team work or at least coordination between us and others would be very helpful. I would love to make something possible that isn't yet :)
am very close I think. Well, that's where I am right now.

At the end of last year, together with another modder, we successfully implemented an experimental .xmot importer/exporter to/from Blender.
With that it was/is possible to edit animations. Unfortunately, the project fell dormant, which means we didn't continue working on it.
So it's great that you have a use case for it and seem pretty motivated about it.
This could bring new momentum to the "animation project" :)

---

Now, I did all if that without your repo. I just found it and saw you have the class declarations, which makes it significantly easier for me, as well allow me to just use their classes as usual. What I have what you don't (i assume) is access to and knowledge of public and private member variables.

The member variables, with the exception of those that are properties of property sets, are indeed very incomplete. The reason for this is that the reconstruction of these requires manual reversing enigeering, therefore I have only reconstructed them for classes or parts of classes that were of particular interest to me.

[HerrNamenlos123]

Wow, thanks for the response! I now went back from hacking into the engine, to simply decoding the good-old .xmot file format. I am writing a python converter. Would you by any chance be able to give me access to the blender importer? This would be a game-changer, since I already know quite a bit about the file format, but have no clue about the Blender API. Your experimental importer would be significant for me I assume...

EDIT: Just so you know, I am from Austria :) Grüß dich!