Re: Post 1.0 Planning Update
Posted: 05 Apr 2018, 20:58
I think there's confusion here about what would and wouldn't be possible with Zini's envisioned OpenMW version.
There'll definitely be improvements to the scripting system, so things that were never possible with MWScript will be doable in OpenMW, and it's likely that either there'll be a scripting language available other than MWScript or via some futuristic magic, somehow MWScript will become good. Adding Lua has been discussed before and wasn't completely dismissed as a possibility, but including parts of Lua's standard library that allow 'dangerous' things like networking was declared a bad idea.
The not-'calling arbitrary C functions from within OpenMW scripts' comment was specifically regarding MWSE's support for DLL-based mods and for Lua FFI support. His belief is that any mod should be possible without doing this as stuff that was a DLL mod in the past can be implemented into the engine.
Either way, the scripting situation will be improved, so if the mod can be made for Morrowind (with or without MWSE) without a DLL, it will become possible to make it for OpenMW.
My disagreement is because I think there are things that would have been a DLL-based mod before that wouldn't be integrated for whatever reason. I don't think it's going to be stuff like making extra functions callable from scripts as provided they're not stupid, that kind of thing is likely to be merged, and if it is stupid, then people shouldn't ever need to call it from a mod. It's going to be something like, for example, completely replacing the combat system so that when you're wearing your VR headset and flailing your arms around (or just repeatedly clicking the mouse), if you hit an enemy's exposed skin a bloody cut appears, and when you hit their armour it gets scratched and armour only affects damage resistance if part of the armour mesh instead of the body mesh gets hit so suddenly a deadric bikini stops being useful. This is the kind of mod that people might actually want to use but would have sweeping changes to how the game was supposed to be played and to balance, so wouldn't necessarily get merged. If someone then decides to release it as a separate fork, everything's fine until someone wants to use it in conjunction with TES3MP or some other mod that's also its own fork. Suddenly, users who don't want to compile their own engine have to pick which single overhaul mod they most want to use.
It's possible that there's some way around this problem, such as Zini being much more open to weird and wacky engine features being added post-1.0 or exposing so many extra functions to scripts that something link this becomes feasible to create via a regular mod as long as the engine has a more basic VR implementation built-in or even that no one with the desire, ability and time to create such a thing exists, so no such mods were ever going to be made anyway. I don't know if a less contrived example mod can be thought up. Without non-contrived examples, Zini's vision is probably fine.
There'll definitely be improvements to the scripting system, so things that were never possible with MWScript will be doable in OpenMW, and it's likely that either there'll be a scripting language available other than MWScript or via some futuristic magic, somehow MWScript will become good. Adding Lua has been discussed before and wasn't completely dismissed as a possibility, but including parts of Lua's standard library that allow 'dangerous' things like networking was declared a bad idea.
The not-'calling arbitrary C functions from within OpenMW scripts' comment was specifically regarding MWSE's support for DLL-based mods and for Lua FFI support. His belief is that any mod should be possible without doing this as stuff that was a DLL mod in the past can be implemented into the engine.
Either way, the scripting situation will be improved, so if the mod can be made for Morrowind (with or without MWSE) without a DLL, it will become possible to make it for OpenMW.
My disagreement is because I think there are things that would have been a DLL-based mod before that wouldn't be integrated for whatever reason. I don't think it's going to be stuff like making extra functions callable from scripts as provided they're not stupid, that kind of thing is likely to be merged, and if it is stupid, then people shouldn't ever need to call it from a mod. It's going to be something like, for example, completely replacing the combat system so that when you're wearing your VR headset and flailing your arms around (or just repeatedly clicking the mouse), if you hit an enemy's exposed skin a bloody cut appears, and when you hit their armour it gets scratched and armour only affects damage resistance if part of the armour mesh instead of the body mesh gets hit so suddenly a deadric bikini stops being useful. This is the kind of mod that people might actually want to use but would have sweeping changes to how the game was supposed to be played and to balance, so wouldn't necessarily get merged. If someone then decides to release it as a separate fork, everything's fine until someone wants to use it in conjunction with TES3MP or some other mod that's also its own fork. Suddenly, users who don't want to compile their own engine have to pick which single overhaul mod they most want to use.
It's possible that there's some way around this problem, such as Zini being much more open to weird and wacky engine features being added post-1.0 or exposing so many extra functions to scripts that something link this becomes feasible to create via a regular mod as long as the engine has a more basic VR implementation built-in or even that no one with the desire, ability and time to create such a thing exists, so no such mods were ever going to be made anyway. I don't know if a less contrived example mod can be thought up. Without non-contrived examples, Zini's vision is probably fine.