AnyOldName3 wrote: ↑01 May 2021, 18:10
So it will not work the same as Papyrus in Skyrim. But we will be able to use Lua coroutines in some form.
I'm aware our threading model is pretty different to that of Papyrus, but we're eventually going to need to support transpiling papyrus to OpenMW Lua (or write a Papyrus/Papyrus bytecode interpreter in OpenMW Lua). Is that something that'll be possible without a big redesign? If not, it's better that we change things now before anyone's relying on them rather than in five/ten/fifty years when we get around to supporting Skyrim.
Most limitations in OpenMW Lua come from the idea that it should work well with multiplayer and that it should be possible to process physics and most of mechanics on clients. Threading model here is secondary. Supporting Papyrus will be tricky, but, I hope, still possible. However I suspect that there will be some minor differences in behaviour (like delays after some commands), but that is the price of supporting multiplayer. I doubt that it can be redesigned to precisely mimic Skyrim without losing compatibility with multiplayer.
Coroutines and async behaviour
psi29a wrote: ↑01 May 2021, 13:35
Can you explain more about what to expect and NOT expect?
I know there was a healthy discussion about async behaviour, co-routines and threading for example.
How are currently handled when it comes to saving?
Changed save-game format?
It is important to understand that coroutines are not multithreading. It is a way to suspend a function (e.g. when it requests some async operation) and then (when the operation is finished) instead of using a callback just resume the same function from the same place. It's all happening in one thread.
With Lua it is not possible to save and restore the state of a script automatically. Each script is responsible for its saved state and should explicitly control it using handlers `onSave` and `onLoad`. It is already implemented this way and I don't see any alternatives. Saving process happens between frames, so it can not happen in the middle of a function, unless the function is a suspended coroutine. With coroutines it can be hard to write a script that properly saves its state, so modders should use them carefully and Lua API shouldn't force modders to use them if it can be avoided.
Save format is changed. As usual, there is one-way compatibility. Old saves can be opened with a new version, but not vice versa.
Lua runtime is always single-threaded. Multiple threads are possible only if some scripts work in one instance of the runtime, and some in a completely separate runtime. For example, local scripts and global scripts can theoretically live in separate threads. But all the global scripts should work in one thread because otherwise they will not be able to interact with each other.
Maybe in the future we can provide some API to run heavy calculations in a separate worker thread, but only in quite a distant future and it is not related to coroutines in any way.
OpenMW Lua will not be compatible with MWSE. At least because it would conflict with being compatible with multiplayer. To make an MWSE mod working in OpenMW all scripts have to be rewritten. Automatic conversion with some tool also will not be possible.
Despite mentioning "multiplayer" a lot, OpenMW Lua is not compatible with the scripting system that is currently used in TES3MP. Don't expect TES3MP to immediately migrate to OpenMW Lua, it requires plenty of work.
Overriding Morrowind mechanics
Overriding original mechanics in Lua will become possible only after dehardcoding them. It is planned, but not in the nearest future.
What to expect in the nearest months
I think that at first we should focus on adding features, that are not possible via MWScript. UI, camera control, custom AI.