How is it limiting the engine to add built-in support for something that everyone can use, rather than relying on specific mods to use architecture-specific native code that hooks into platform-specific libraries? Especially as stability issues inevitably arise, if the handling is built-in then the engine has room to fix it, but if it's external, the engine is basically prevented from fixing the problem.NullCascade wrote: ↑15 Jun 2018, 21:57Regarding native extensions, you'll never have 100% support everywhere, and that's fine. There's no entitlement or expectation for your Raspberry Pi build of Morrowind to be able to have touch pressure sensitivity with jerry-rigged hardware, and it's not worth limiting a game engine for the one guy that wants to do that.
I think you're over-estimating the need for native code for mods. Native code is only needed when the engine doesn't have built-in support for something, and if there's something mods need, the engine would be knee-capped by not having built-in support for it.If the project's goal is to be a modern, open source game engine in general, it's kneecapping itself compared to any competitor.
It's interesting the doomsday scenarios people make over not supporting native code, that it'll fracture and kill the community with millions of forks, and not supporting native code will kill all enthusiasm for the engine. But we can look at the Doom community to get an idea to see how it works out. When the Doom source code was originally released, a ton of forks popped up, all focusing on adding different features that people wanted. Some added OpenGL, some added room-over-room ("true 3D" maps), some added true-color visuals, some added scripting, most added different editing capabilities, etc, almost all of them incompatible with each other. However, rather than being the death of Doom modding, the different forks started adding compatibility between them for common feature sets that people found most useful/desirable. Mods that once required a specific fork would work with others. One fork, called Boom, had a feature set that became so ubiquitous that mods sticking to that feature-set are known as Boom-compatible mods. Some forks even sprung up that focused on maintaining a 100% authentic vanilla experience with no additional features and little bug fixing (just better compatibility with newer systems).
One fork to pop up did actually implement native code extensions, ironically called Doomsday. It did become popular at one point, because it had graphical flair, a decent feature set, and modders could add whatever more they wanted. However, because of people regularly trying to use native code for their super-important feature, it constantly had stability and compatibility issues. And as other engines gained built-in support for similar features, the player base started getting annoyed that they had to use that specific unstable engine to play specific mods, instead of being able to use their engine of choice with the mod made in a more compatible manner.
Doomsday no longer holds the popularity it once did. These days, GZDoom is among the most popular forks (it's even used in some commercial games). And it is so without supporting native code extensions, instead focusing on adding built-in features that modders need while maintaining stability and compatibility. Windows, Linux, macOS, 32-bit, 64-bit, x86, ARM, it's all supported, and you can pick out any mod the engine supports without any worry if it'll work on your platform.
If you're capable of coding in a desirable feature, why make a fork for just that feature instead of contributing the code to OpenMW itself? By contributing to OpenMW, you can also get discussions on how to not only better implement want you're trying to do, in some cases you may even find out you don't need new features at all and can instead use existing capabilities to do the same thing.