Union mod support is absolutely possible

[illnyang]

Union exposes its own API as C-style exports. Your README.md states that Union mods are impossible to support, which is not true — it's perfectly possible, but tedious to do. You 'just' need to reimplement the entirety of Union API, which in turn means reverse-engineering their modified engine binaries. You could add a note to README.md acknowledging this; Maybe one day someone crazy enough will read that note and send you a pull request — no one will even consider this possibility if you keep README as is.

[Try]

Hi, @illnyang ! I love your enthusiasm, yet there a bit more problems with UNION:

1. UNION plugins are *.dll (windows, 32bit, x86) based.
   1.1 OpenGothic is 64bit only (and there is no plans of downgrading), what make impossible to link this *.dll as-is even on windows.
   1.2 Load arbitrary *.dll from game folder is bad in terms of security, ideally this code should be sandboxed somehow.
2. UNION enables direct memory access to engine objects
   Since OpenGothic and vanilla gothic aren't written in same way direct byte access won't make any sense.
3. UNION plugins often times are using windows-api, what raises more issues on non-windows platforms.
4. UNION provides access to DirectX7 api, so DX has to be emulated as well.

In short UNION implementation will require full x86-windows32 emulation with extra hooks in memory-mapping-unit.

[illnyang]

Thanks for the clarification :) I will try to address the aforementioned issues to the best of my abilities:

1. This could be mitigated by manually loading said DLLs, although I'm not sure whether mode-switching (think wow64) would be a viable option in this case.
2. Unfortunately, the only solution I can see are 'gateway structs' that match UNION's ABI... Extremely infeasible, not to mention the added cost of struct translation.
3. Hooking import address table should do it: hook new methods as needed (that is, do not hook any import unless it is seen out in the wild in some mods). Perhaps libwine could be used instead?
4. Same as above...

In the end, it seems that reverse-engineering UNION plugins/mods and recoding them from scratch is much more feasible. How does OpenGothic compare to UNION, feature-wise?

[Try]

1. Wow64 works per-process, so load Win32 dll into win64 process is not an option
   1.1. Even with "manual" loading it's still far from possible - loaded code wont be able to reference most of application address space due to pointer size difference.
2. There is no such thing as UNION API - they seems to reverse engineered most of vanilla game classes and expose them.
3. Yep, basically we would have to provide build-in wine, in order to make this part work.
   3.1 Even, if it's gonna work, should we? WinApi will allow access to users file system, hardware, network and much more...
   3.2 32 vs 64 problem is also here - what, if some call to win-api will result in pointer higher then 0xFFFFFFFF, what is not representable in 32bit mode?
4. Who is going to implement DX7 (in a way to make it interacts with current engine)? Not me - that's for sure :)

How does OpenGothic compare to UNION, feature-wise?

Afaik UNION is a plugin system to original game, and OpenGothic - is a new engine/ I'm not aware of what technical decisions we made in vanilla game, so there is 99% change that's code-base is non-compatible at all.

[czarnyafgan]

And what about the NINJA packet compatibility?

[kirides]

There is nothing to add for Ninja compatibility.
Ninja is just an engine extension that allows you to load arbitrary scripts from VDF files.

Most Patches use Ikarus (and often LeGo) which by itself is not that big of an issue.
BUT most patches that use Ikarus also make use of engine hooks and/or direct memory access to override functionality or add functionality.
This in turn makes most of the currently implemented patches incompatible with OpenGothic.

OpenGothic could try to make atleast some parts of LeGo work, by providing it's own implementation of Ikarus.
But that wouldn't help as much as one would think.

it'll be better to focus OpenGothic more towards scriptability of all the game mechanics (e.g. Toggling a "barrier", customizing each stage of Damage calculation as well as target acquisition for area of effect spells (and melee/ranged hits...?)

so that new mods could take advantage of running in OpenGothic.
Sure, old mods would'nt run in it, but new mods could take full advantage of the open source engine.

[Try]

And what about the NINJA packet compatibility?

Sorry for late answer, but yeah - I'm not completely sure how Ninja. By then look of things - it's not just a loader, but a proper DMA wrapped with *.dll. Probably won't work.

Most Patches use Ikarus (and often LeGo) which by itself is not that big of an issue.

Basically, yes - plan is to implement a LeGo/Ikarus entry-points, maybe a faked virtual memory heap, but not state access
https://github.com/Try/OpenGothic/blob/master/game/game/compatibility/ikarus.cpp

e.g. Toggling a "barrier", customizing each stage of Damage calculation as well as target acquisition for area of effect spells (and melee/ranged hits...?)

Proposals, with C++ implementation are welcome ;)

[Nindaleth]

it'll be better to focus OpenGothic more towards scriptability of all the game mechanics
so that new mods could take advantage of running in OpenGothic.
Sure, old mods would'nt run in it, but new mods could take full advantage of the open source engine.

This is how OpenMW (and also Daggerfall Unity AFAIK) went, they also have issues supporting all the original mods. The remakes had to get to a rather complete state first, but now they're very much superior to the originals and so it makes sense for the modders to focus on them.