The new MWSE-Lua interface

Everything about development and the OpenMW source code.
User avatar
akortunov
Posts: 433
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation
Github profile: https://github.com/akortunov

Re: The new MWSE-Lua interface

Post by akortunov » 06 Oct 2018, 12:52

SeaFox wrote:
06 Oct 2018, 12:21
Two good examples of the benefits of using a plugin architecture are web browsers and Blender. They all use plugins extensively:
Firefox Add-ons

20 Free Blender Add-ons
Actually, they are bad examples: Firefox WebExtensions use JavaScript, and mentioned Blender plugins from your link use Python scripts.
No binary files, since both mentioned apps are cross-platform.
Also FireFox uses access rules for plugins - there is no full trust to 3d-party scripts.

User avatar
SeaFox
Posts: 34
Joined: 29 Feb 2016, 17:30

Re: The new MWSE-Lua interface

Post by SeaFox » 06 Oct 2018, 13:19

akortunov wrote:
06 Oct 2018, 12:52
SeaFox wrote:
06 Oct 2018, 12:21
Two good examples of the benefits of using a plugin architecture are web browsers and Blender. They all use plugins extensively:
Firefox Add-ons

20 Free Blender Add-ons
Actually, they are bad examples: Firefox WebExtensions use JavaScript, and mentioned Blender plugins from your link use Python scripts.
No binary files, since both mentioned apps are cross-platform.
Also FireFox uses access rules for plugins - there is no full trust to 3d-party scripts.
The point is extensibility. To empower mod creators, you need to give them the power to extend the core functionality of the base application. The more power you give them, the more they can create.

CMAugust
Posts: 118
Joined: 10 Jan 2016, 00:13

Re: The new MWSE-Lua interface

Post by CMAugust » 06 Oct 2018, 13:46

As a user, I've always enjoyed Blender's plugin system - especially how there are already a lot of very useful ones packed-in. With the eventual dehardcoding and lua implementation, OpenMW would virtually have its equivalent, wouldn't it?

User avatar
akortunov
Posts: 433
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation
Github profile: https://github.com/akortunov

Re: The new MWSE-Lua interface

Post by akortunov » 06 Oct 2018, 13:49

SeaFox wrote:
06 Oct 2018, 13:19
The point is extensibility. To empower mod creators, you need to give them the power to extend the core functionality of the base application. The more power you give them, the more they can create.
Again, your examples do not extend "core functionality". Program provides a framework, which can be used to change its behaviour, keeping its core intact.
You still limited by bounds, which authors of core program consider as reasonable because of program architecture, supported platforms, maintainance issues, security reasons, etc. You can not do everything on target machine just because you want to do it.
The same thing with OpenMW: Lua scripting can be considered as a such framework, and it does not means that this framework should not have its bounds.
Native code execution and direct access to filesystem are out of question because of project architecture and list of supported platforms, not by developers evil will.
The other components can be implemented, but on a low level OpenMW is a completely different program from original Morrowind.
So low level API more likely will be incompatible with MWSE anyway. The only way to keep a compatibility - a high-level API instead of direct access to low-level and/or platform-specific stuff, what we try to explain for months.
Also a high-level approach allows to do not rewrite plugins every time when developers change something on low-level in OpenMW.

The one example of such high-level API - using a virtual filesystem, provided by OpenMW, instead of basic Lua IO stuff.

User avatar
sjek
Posts: 425
Joined: 22 Nov 2014, 10:51

Re: The new MWSE-Lua interface

Post by sjek » 06 Oct 2018, 14:29

akortunov wrote:
06 Oct 2018, 13:49
Again, your examples do not extend "core functionality". Program provides a framework, which can be used to change its behaviour, keeping its core intact.
same seems to be target in design doc. you can create own skills and then define the script that covers that skill and events are handled with engine defined hooks. this seems reasonable as defining the event in every frame would be a killer. some sort of timer is surely quickly done if and when needed. it's good to have structured data format.

https://gitlab.com/OpenMW/openmw/blob/m ... 1.md#hooks
We provide system hooks within the namespace sys that are called in specific situations (see the section about de-hardcoding for some examples). Content developers may also provide their own hooks (user hooks).
System hooks are not added to content files, since they cannot be modified by content developers anyway. We will instead inject the system hook records on content-file load.
https://gitlab.com/OpenMW/openmw/blob/m ... ic-effects
For the existing effects, we will inject scripts that match the previously hardcoded effects when loading from an older omwgame file. This will require the addition of a significant number of new script instructions that are all trivial, since they will just call existing engine functions.
It is important to generalise as much as possible when creating these new script functions, e.g., we won't have a DivineIntervention script instruction. Instead we add a GetClosestMarker function, use existing functions for querying position and cell and, then, use the new Teleport instruction.
akortunov wrote:
06 Oct 2018, 13:49
The other components can be implemented, but on a low level OpenMW is a completely different program from original Morrowind.
So low level API more likely will be incompatible with MWSE anyway. The only way to keep a compatibility - a high-level API instead of direct access to low-level and/or platform-specific stuff, what we try to explain for months.
i think that's doable (non coder). basic idea is the same. new functions are created and values given. For vanilla combapility defaults are injected from the codebase.
The one example of such high-level API - using a virtual filesystem, provided by OpenMW
plugin architecture by the launcher ?
and separate one will be needed for openmw-cs python plugins.
"life is crazy"
"craziness has beauty which only crazies understand" some movie clip in the head.
https://wiki.openmw.org/index.php?title=Testing

User avatar
lysol
Posts: 1065
Joined: 26 Mar 2013, 01:48
Location: Sweden

Re: The new MWSE-Lua interface

Post by lysol » 06 Oct 2018, 14:43

SeaFox wrote:
06 Oct 2018, 12:21
I think the biggest problem is that people tend to take the attitude of "it's my way or the highway". There is no willingness to compromise. For example, sand-boxing (no plugins allowed) is made mandatory instead of just being set as the default behavior with some option to change that default for those who don't want sand-boxing. Again, it's "my way or the highway".
There has already been compromises: OpenMW will implement Lua scripting instead of oldscript+.

Ultimately, you have to have some form of leadership, be it a total democracy or a more traditional leader figure. OpenMW has had Zini as a leader for a very long time now, and he is in charge. So if he makes decisions you don't like, try to convince him! He already got convinced regarding Lua. And if you can't, well I'm sorry, but you'll have to fork. Obviously you can't decide what other people should do with their own project. And there will always be different opinions and you can't please them all.

Also, pro-tip to anyone trying to convince Zini: Calling his project a meme won't make the convincing easier.
Normal mapped texture replacers, exclusive for OpenMW:
My Nexus page

User avatar
psi29a
Posts: 4257
Joined: 29 Sep 2011, 10:13
Github profile: https://github.com/psi29a/
Contact:

Re: The new MWSE-Lua interface

Post by psi29a » 06 Oct 2018, 15:11

SeaFox wrote:
06 Oct 2018, 13:19
The point is extensibility. To empower mod creators, you need to give them the power to extend the core functionality of the base application. The more power you give them, the more they can create.
That is what OpenMW has been doing since day one by virtue of the fact that it is open-source and anyone can contribute.

As was said earlier, not everyone wishes to dive into OpenMW to contribute but does want to create mods with the tools OpenMW provides. At this point, we're stuck with mwscript because that is where we are at with aiming at with the 1.0 release.

After that release, mwscript is frozen and we offer a newscript based on Lua for Modders.

This is the point that we fully expect feature requests to come in, such as support for MWSE extensions so that their mods will work and new feature requests. The goal is to make sure that Modders not have to look at OpenMW to create mods beyond 'newscript', that means no C or C++ or even 3rd party libraries because the point is to be able to call the functionality needed through OpenMW's newscript. If functionality isn't there, then just like any open-source project, ask for a feature request.

As for the question of sandboxing, nothing has been said here and elsewhere that provides a good enough reason to do otherwise. So unless someone has a valid technical argument (not an ideological one) for non-sandboxing, I believe this thread has run its course.

No amount of name-calling, character assassinations or discussing in bad faith is going to change opinions either. This only forms a wedge in the community and causes bad-blood between projects.

User avatar
SeaFox
Posts: 34
Joined: 29 Feb 2016, 17:30

Re: The new MWSE-Lua interface

Post by SeaFox » 06 Oct 2018, 19:30

lysol wrote:
06 Oct 2018, 14:43
SeaFox wrote:
06 Oct 2018, 12:21
I think the biggest problem is that people tend to take the attitude of "it's my way or the highway". There is no willingness to compromise. For example, sand-boxing (no plugins allowed) is made mandatory instead of just being set as the default behavior with some option to change that default for those who don't want sand-boxing. Again, it's "my way or the highway".
Ultimately, you have to have some form of leadership, be it a total democracy or a more traditional leader figure. OpenMW has had Zini as a leader for a very long time now, and he is in charge. So if he makes decisions you don't like, try to convince him! He already got convinced regarding Lua. And if you can't, well I'm sorry, but you'll have to fork.
Another good point. I personally think Zini is doing an excellent job. The only change I would make is to add an option to disable the default sandboxing mode. Sandboxing would remain the default. I simply see no good reason to require a fork to make such a small change.

Chris
Posts: 1500
Joined: 04 Sep 2011, 08:33

Re: The new MWSE-Lua interface

Post by Chris » 06 Oct 2018, 20:32

SeaFox wrote:
06 Oct 2018, 12:21
I think the biggest problem is that people tend to take the attitude of "it's my way or the highway". There is no willingness to compromise. For example, sand-boxing (no plugins allowed) is made mandatory instead of just being set as the default behavior with some option to change that default for those who don't want sand-boxing.
Turn that around, though. If OpenMW supports non-sandboxed plugins, it's supported. You can't partially support native code, so we're left at "my way or the highway". Allow modders access to the system without the engine's oversight, or else. Again, an option won't fix anything. A user that doesn't want to use non-sandboxed plugins won't download them, so it doesn't matter if it's on or off, and a user that does want to use such a plugin has already made the decision to turn it on. The option solves nothing.

Further, a modder sees the option available, they can just make a plugin and say "that option needs to be on to use this mod", and it's all back at square one; potential stability issues the engine can't fix, compatibility issues as the same native code won't work on everyone's system, plugins suddenly failing after a system update and there's nothing the engine can do, etc. A user must enable the option to use the mod, if the mod would even work on their system to begin with, or they can't use that mod or anything that relies on that mod. Where is the compromise?
SeaFox wrote:
06 Oct 2018, 12:21
Again, it's "my way or the highway".
If anything, I would say the sandboxing rule is OpenMW's way to compromise. Rather than giving modders unfettered access to the system, with all the compatibility, stability, and security issues that implies and the devs just wash their hands of the mess it causes, OpenMW provides users with a stability- and compatibility-focused engine, but as a consequence must work with modders and other devs to get features they want implemented in a stable and compatible way. Far from "my way of the highway", OpenMW would have to work with modders and other devs to hash out the best way to expose certain features in a way that's satisfactory for everyone while staying true to the engine's core goals. As it is, I'll again point out OpenMW has already changed its stance on MWSE compatibility and Lua support as a direct result of these discussions. If that's not compromise, what is?

User avatar
SeaFox
Posts: 34
Joined: 29 Feb 2016, 17:30

Re: The new MWSE-Lua interface

Post by SeaFox » 06 Oct 2018, 21:02

Chris wrote:
06 Oct 2018, 20:32
Where is the compromise?
The best compromise is to give people the choice to disable sandboxing if they want to, or to keep sandboxing, which is the default option. You may think doing that is a "very bad thing", so you would choose not to disable. Someone else who thinks it would be a "very good thing" would make a different choice. Everyone gets what they want, and everyone wins.

Post Reply

Who is online

Users browsing this forum: No registered users and 6 guests