The new MWSE-Lua interface

Everything about development and the OpenMW source code.
CMAugust
Posts: 285
Joined: 10 Jan 2016, 00:13

Re: The new MWSE-Lua interface

Post by CMAugust »

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: 899
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation

Re: The new MWSE-Lua interface

Post by akortunov »

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: 442
Joined: 22 Nov 2014, 10:51

Re: The new MWSE-Lua interface

Post by sjek »

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.
User avatar
lysol
Posts: 1513
Joined: 26 Mar 2013, 01:48
Location: Sweden

Re: The new MWSE-Lua interface

Post by lysol »

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.
User avatar
psi29a
Posts: 5355
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: The new MWSE-Lua interface

Post by psi29a »

SeaFox wrote: 06 Oct 2018, 13:19The 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 »

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: 1625
Joined: 04 Sep 2011, 08:33

Re: The new MWSE-Lua interface

Post by Chris »

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 »

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.
User avatar
Capostrophic
Posts: 794
Joined: 22 Feb 2016, 20:32

Re: The new MWSE-Lua interface

Post by Capostrophic »

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.
Chris has just explained why that is not a real compromise. You either have sandboxing or you don't. Having some sandboxing or conditional sandboxing is still having sandboxing. Then he explains the reasons why not having sandboxing is in a way a compromise with the modders.
At this point he told you twice that such an option would be useless because either the users wants to use sandboxing (and has to enable the setting to use the desired mods) or the user doesn't (and doesn't enable the setting, and couldn't ever actually utilize it by not installing plugins that have native code) so having it solves nothing.
User avatar
SeaFox
Posts: 34
Joined: 29 Feb 2016, 17:30

Re: The new MWSE-Lua interface

Post by SeaFox »

Capostrophic wrote: 06 Oct 2018, 22:33
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 either have sandboxing or you don't.
Yes. With sandboxing, binary plugins don't work. Without sandboxing, they do.

People who want sandboxing, should have sandboxing and will be protected from binary plugins. People who don't want sandboxing should have the option of disabling sandboxing so they can use mods with binary plugins.

With this compromise, everyone gets what they want. People who want protection from binary plugins will have it, and people who want to use binary mods will be able to do so. You obviously can't be protected prom binary plugins and still use binary mods at the same time. That is the choice that each individual should be able to make for themselves.
Post Reply