openmw.org

Let's first define the terminology. There are 4 separate things: 1) Engine API - Lua code calls C++ functions. 2) Engine handlers -- C++ code calls Lua functions. 3) Events -- Lua to Lua communication. One script sends, another script receives with a delay. 4) Interfaces (not implemented yet) -- Lua...

Thanks a lot!

These headers, lib51.lib, and lib51.dll are exactly what was needed.
*.lua files are not necessary, I don't know what they are needed for.

Now I have some compilation errors due to differences in compilers, I'll will investigate it tomorrow.

Progress report A month ago I turned from discussions about Lua to the actual coding. Now it is time to talk about the progress. Most of the main concepts (sandboxing, global/local/player scripts, handlers, events) are already implemented. I think I've managed to build a clean and flexible basis th...

Lua scripting examples: https://gitlab.com/-/snippets/2041757

cc9cii wrote: ↑

16 Nov 2020, 06:18

EDIT: would you have an example of a global script?

Sorry for delay with the answer. Still thinking how the API should look like. On the weekend I'll write an example with both local and global scripts.

I'm intrigued by this - would you mind adding some commentary on each bullet point to explain the thought behind them? Is this geared towards multiplayer setup? My aim is to develop a universal scripting system that will be convenient for both singleplayer and multiplayer. Also it should allow to d...

AnyOldName3 wrote: ↑

15 Nov 2020, 19:18

We're already processing the world state during the rendering of the previous frame. If scripting happens then, too, then it's necessarily ignoring that frame's world state changes.

Could you point me to the place in the code where it is happening?

Extracting the whole scripting to a separate thread is more important than multithreaded scripting. It should be safe because rendering and scripting work on different data. I'm not convinced this has been thought through. Rendering works on the world state after all processing has been done, so yo...

I've written some ideas in a google doc . Open for comments. Key points about threads and events: Extracting the whole scripting to a separate thread is more important than multithreaded scripting. It should be safe because rendering and scripting work on different data. Local scripts are always syn...

Personally, I think a combination of 1 and 3 is the way to go. We could have local scripts run on the main thread, and delegate to them features which are necessary to run every frame (e. g. smooth UI animations, or manipulating actor positions in a very specific way). Since there was some misunder...