openmw.org

Wouldn't it make more sense to just plop all mwscript related things under a openmw.mwscript package? I just don't see the benefit of designing new packages with support of mwscript equivalent functions in mind. Even if this approach was taken there is no reason to do it now, it would just serve as a backbone for the mwscript transpiler (to guarantee functions behaved the same). I am strongly in favor of pretending mwscript and all its quirks doesn't exist when developing the initial toolbox for modders, though you would still use it as a general reference to know what kinds of things you want exposed (like weather, audio, animations, etc...). Just my two cents.

wazabear wrote: ↑07 Aug 2021, 19:44 Wouldn't it make more sense to just plop all mwscript related things under a openmw.mwscript package? I just don't see the benefit of designing new packages with support of mwscript equivalent functions in mind. Even if this approach was taken there is no reason to do it now, it would just serve as a backbone for the mwscript transpiler (to guarantee functions behaved the same). I am strongly in favor of pretending mwscript and all its quirks doesn't exist when developing the initial toolbox for modders, though you would still use it as a general reference to know what kinds of things you want exposed (like weather, audio, animations, etc...). Just my two cents.

I agree totally with this. I too wish to pretend that mwscript doesn't exist, but we still need it for backwards compatibility with existing mods. So we'll have to maintain this.

That being said, openmw-lua should not be "designed" to mimic mwscript and that was never implied. I only suggested, and apparently I'm not the only one, that it would be a good place to start since we have to provide enough functinality to make sure that mwscript works. It is a perfectly good use-case that exists now.

It's a bit of double-duty since mwse-lua doesn't need to worry about this either, we do.

Ideally an openmw.mwscript package that exported all the functions in mwscript would be a pure Lua module and call only public functions, just potentially in dumb ways in order to replicate the quirks.

Just figured I'd say this, in case one of the devs notices this. But you can actually simplify the scripting just a bit with a few tricks.

The first is saving Lua's Variables. This mechanism leads to some easy to make human errors. Which might not mean anything, but you'd be surprised.
Instead of having explicitly defined "OnSave" and "OnLoad" functions that a user will call, you can instead try this out, which is similar to the mechanism used in Legend of Grimrock.

Every Script has a meta table. In that metatabe, you have a reference called _ENV which by default points to the global table for the entire application _G. When loading or instantiating scripts, you can give each script their own environments, making their data no longer global.

With this new table, lets call it "_LENV", not only does it prevent the code from accessing elements of code it has no business accessing. You can also write the metatable to allow people to read from the global table, but not write to it. As well as force any new globals that are defined to be written to the scripts environment. But you can also do things such as declaring global (scoped to the script) variables, and have it automatically be saved or loaded.

You can do this by iterating through the script's environment table, and collecting references. Or... simply by making copies and overwriting the environment.

MutedKobold wrote: ↑21 Aug 2021, 04:20 When loading or instantiating scripts, you can give each script their own environments, making their data no longer global.

Each script already has its own sandboxed environment.

MutedKobold wrote: ↑21 Aug 2021, 04:20 Instead of having explicitly defined "OnSave" and "OnLoad" functions that a user will call, you can instead try this out, which is similar to the mechanism used in Legend of Grimrock.
...
As well as force any new globals that are defined to be written to the scripts environment. But you can also do things such as declaring global (scoped to the script) variables, and have it automatically be saved or loaded.

The problem with this approach is that user can rely on transparent saving/loading, but actually such saving looses all local variables and all non-serializable values. Explicit "OnSave" and "OnLoad" are better because they do not confuse users.

Is there a way to modify item stats using lua? For example, I want to balance all item prices when the game starts according to certain rules, is it possible to implement in OpenMW?

Seven wrote: ↑29 May 2023, 10:02 Is there a way to modify item stats using lua? For example, I want to balance all item prices when the game starts according to certain rules, is it possible to implement in OpenMW?

Item stats are stored in ESM records. IIRC, they are considered to be immutable by Lua scripts with current design.

Can someone explain please how do I access global MWScript variable from lua script?
For example I have a regular MWScript which changes global variable my_global_variable, and I want to read it from my lua script, how do I do it?
Would be grateful for some simple example code as I've read lua documentation and found nothing.