Lua scripting in OpenMW

Everything about development and the OpenMW source code.
User avatar
heilkitty
Posts: 158
Joined: 11 Aug 2011, 07:57
Location: Vivec City, MW
Contact:

Re: Lua scripting in OpenMW

Post by heilkitty »

urm wrote: 29 Dec 2020, 22:59 There were some talks about adding Python scripting to OpenMW-CS, which personally I find a bit weird since we do seem somewhat commited with the Lua API for the main game.
That's for automating OpenMW-CS itself, e.g., bulk creating/editing objects. Many popular tools, such as Blender and GIMP, have Python automation, so it's quite logical actually.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Lua scripting in OpenMW

Post by AnyOldName3 »

There are a lot more data processing libraries out there for Python than Lua, and Python has a choice of well-tested, actively developed Qt bindings, including official ones. Sandboxing is less of a concern for the CS, and also native code is less problematic, too - if you want a native-backed Python library in your OpenMW-CS plugin, then just reference a pip package, and there'll be a native version for most platforms and a pure-Python fallback for the others.
ptmikheev
Posts: 69
Joined: 01 Jun 2020, 21:05
Gitlab profile: https://gitlab.com/ptmikheev

Re: Lua scripting in OpenMW

Post by ptmikheev »

ptmikheev wrote: 29 Dec 2020, 00:37 List of things that should be done next:
  • Saving/Loading scripts state (it will affect saves format).
  • Get a list of global scripts to run from omwgame/omwaddon (currently "test.lua" is hardcoded). Data files format will not change - I am going to reuse the same way how MWScript stores list of global scripts for auto start.
  • Extend current "minimal API" to "minimal valuable API" (just a few commands, but something useful).
  • Write documentation for Lua scripting.
When all of this is done, it will be possible to discuss merging it into master.
It is time for a next progress report.
  • Saving/Loading scripts state (it will affect saves format). - Done
  • Get a list of global scripts to run from omwgame/omwaddon omwscripts files. - Done
  • Extend current "minimal API" to "minimal valuable API" (just a few commands, but something useful). - In progress
  • Write documentation for Lua scripting. - Done
Also a first Lua mod is ready for testing. Can be found in my Lua MR.
ptmikheev
Posts: 69
Joined: 01 Jun 2020, 21:05
Gitlab profile: https://gitlab.com/ptmikheev

Re: Lua scripting in OpenMW

Post by ptmikheev »

AnyOldName3 wrote: I don't really see why it's fine to run MWScript before the cull traversal, but Lua needs to be done in parallel and then applied to the frame after. Lua should be faster than MWScript. Also, as the rendering guy, that's when I want the entire CPU available to me and no one else so I don't get other threads booting me off my core, so even if we did have to have a frame of latency wherever we put it, I see in parallel with the cull traversal as the single worst place.
I think that Lua will be used much more extensively than MWScript, especially after dehardcoding MWMechanics. So it can affect performance. As I understand OpenMW currently doesn't fully utilize all cores of modern CPUs. For me it looks reasonable to put Lua into a separate thread. I do it in parallel with the cull traversal, because
  • Cull traversal takes a lot of time.
  • Cull traversal affects only scene graph and scripts can safely work with RefData at the same time.
Do you mean that in parallel can somehow become slower than sequential?
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Lua scripting in OpenMW

Post by AnyOldName3 »

On plenty of machines, the cull traversal is the slowest thing. If we have other intensive things happening on another thread, then we're at the mercy of the OS scheduler deciding one of those things should get a time slice on the core doing the cull traversal. There are lots of machines our users use which don't have enough cores to avoid contention, especially when things like async physics are involved, so there will be times when doing scripting in parallel with the cull traversal ends up taking as long as doing scripting first. That means the advantage of doing things in parallel with the cull traversal doesn't always exist.

The disadvantage, i.e. that the results of Lua scripts aren't displayed for a whole frame after they happen, does always exist, though. For lots of game mechanics, that won't matter, but for others, it will.
ptmikheev
Posts: 69
Joined: 01 Jun 2020, 21:05
Gitlab profile: https://gitlab.com/ptmikheev

Re: Lua scripting in OpenMW

Post by ptmikheev »

AnyOldName3 wrote: 04 Apr 2021, 13:22 On plenty of machines, the cull traversal is the slowest thing.
It is exactly the reason why it is important that Lua can work in parallel with it. It is the only way to support heavy scripts without affecting frame rate.
AnyOldName3 wrote: If we have other intensive things happening on another thread, then we're at the mercy of the OS scheduler deciding one of those things should get a time slice on the core doing the cull traversal. There are lots of machines our users use which don't have enough cores to avoid contention, especially when things like async physics are involved, so there will be times when doing scripting in parallel with the cull traversal ends up taking as long as doing scripting first. That means the advantage of doing things in parallel with the cull traversal doesn't always exist.
Well, I can add a setting that enables/disables the separate scripting thread. But I am pretty sure that in most of the cases (probably except some low-end mobile devices) the separate thread makes sense.
AnyOldName3 wrote: The disadvantage, i.e. that the results of Lua scripts aren't displayed for a whole frame after they happen, does always exist, though. For lots of game mechanics, that won't matter, but for others, it will.
From the game logic perspective running it at the end of a previous frame is completely equivalent to running it at the beginning of a new frame. The only effect is a minor delay of processing user input, but it doesn't affect basic player controls, only key bindings, that are processed in Lua. I think it is a reasonable cost for the possibility to have heavy scripts and high FPS at the same time.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Lua scripting in OpenMW

Post by AnyOldName3 »

If a script controls something like a UI element changing colour when you hover over it (not the best example as that'll probably stay MyGUI's job for the foreseeable future, but there's plenty that's analogous to that in a game), a user will absolutely notice one frame's delay in scripts processing their input. I imagine there's a bunch of other stuff we'll want to dehardcode where the results will need to be available in the same frame.
ptmikheev
Posts: 69
Joined: 01 Jun 2020, 21:05
Gitlab profile: https://gitlab.com/ptmikheev

Re: Lua scripting in OpenMW

Post by ptmikheev »

AnyOldName3 wrote: 05 Apr 2021, 20:46 If a script controls something like a UI element changing colour when you hover over it (not the best example as that'll probably stay MyGUI's job for the foreseeable future, but there's plenty that's analogous to that in a game), a user will absolutely notice one frame's delay in scripts processing their input. I imagine there's a bunch of other stuff we'll want to dehardcode where the results will need to be available in the same frame.
It is true, it is a disadvantage of my approach. Maybe if for some mechanics it will be essential, I will need to add some workarounds.
But anyway I think that the performance benefit of multithreading is more important.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Lua scripting in OpenMW

Post by AnyOldName3 »

I don't think it necessarily has a performance benefit if you look at it in terms of responsiveness. Let's say it's 15 ms per frame in parallel with cull and 25 ms per frame in parallel with something like physics so the script can receive input and affect the same frame. In that case, it's 30 ms before a script's response to an input can be displayed with your approach, but only 25 ms with the one where it can be done in the same frame. Sure, the framerate's significantly lower, but it's still more responsive, and we need to strike a balance - we could have tens of thousands of frames per second if the game just rendered a static image of the main menu repeatedly and never had to respond to anything.

If we could trust mod developers, maybe we could let them flag stuff as either needing handling in a hurry, or being handleable at the engine's convenience, and do the first category for the same frame, but defer the other category until whichever point in the frame it fit best, even if that added latency. I suspect a lot of functions would be tagged as the first sort for no reason, though.
ptmikheev
Posts: 69
Joined: 01 Jun 2020, 21:05
Gitlab profile: https://gitlab.com/ptmikheev

Re: Lua scripting in OpenMW

Post by ptmikheev »

AnyOldName3 wrote: 07 Apr 2021, 22:02 If we could trust mod developers, maybe we could let them flag stuff as either needing handling in a hurry, or being handleable at the engine's convenience, and do the first category for the same frame, but defer the other category until whichever point in the frame it fit best, even if that added latency. I suspect a lot of functions would be tagged as the first sort for no reason, though.
It is similar to what I meant as a workaround, but mod developers don't need to tag it explicitly.
Local scripts on NPCs don't have access to UI and inputs. The same applies to global scripts (as in multiplayer they are server-side, delays are unavoidable). So the input latency is important only for the scripts attached to the player. To solve the problem it should be enough to process some specific input handlers in the main thread rather than in the lua thread.

I can formulate it this way: every command in Lua API should be implemented in such a way that it is safe to run it in parallel with the cull traversal. And in order to force it I started development from creating a separate Lua thread. But it doesn't mean that we will not be able to run some of the commands from the main thread.
Post Reply