The new MWSE-Lua interface

Everything about development and the OpenMW source code.
User avatar
Capostrophic
Posts: 454
Joined: 22 Feb 2016, 20:32

Re: The new MWSE-Lua interface

Post by Capostrophic » 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.
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.
shitty lingua anglica grammar ftw

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

Re: The new MWSE-Lua interface

Post by SeaFox » 06 Oct 2018, 23:11

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.

User avatar
Capostrophic
Posts: 454
Joined: 22 Feb 2016, 20:32

Re: The new MWSE-Lua interface

Post by Capostrophic » 06 Oct 2018, 23:17

and will be protected from binary plugins.
They won't use such plugins either way! :|
shitty lingua anglica grammar ftw

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

Re: The new MWSE-Lua interface

Post by SeaFox » 06 Oct 2018, 23:18

Capostrophic wrote:
06 Oct 2018, 23:17
and will be protected from binary plugins.
They won't use such plugins either way! :|
Not sure what your point is.

User avatar
Capostrophic
Posts: 454
Joined: 22 Feb 2016, 20:32

Re: The new MWSE-Lua interface

Post by Capostrophic » 06 Oct 2018, 23:25

I reiterate upon a sandboxing toggle being completely useless.
shitty lingua anglica grammar ftw

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

Re: The new MWSE-Lua interface

Post by SeaFox » 06 Oct 2018, 23:38

Capostrophic wrote:
06 Oct 2018, 23:25
I reiterate upon a sandboxing toggle being completely useless.
No it's not. Because the purpose of sandboxing is to protect your computer from malware. Malware is software created by malicious hackers to do nasty things to you. The whole purpose of sandboxing in OpenMW is thus to protect users from malware in your mods. Many people want such protection, but others do not. They are willing to take a small risk so that they can make use of mods with binary plugins, which can be very powerful.

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

Re: The new MWSE-Lua interface

Post by Chris » 07 Oct 2018, 00:45

SeaFox wrote:
06 Oct 2018, 23:38
No it's not. Because the purpose of sandboxing is to protect your computer from malware.
That's only one (actually small) facet. And while it's certainly an issue to take seriously, there are more issues than that. To go over it again:

Compatibility. When you have native code, it can rely on whatever it wants from the system. Make a call to CoCreateInstance, and suddenly it's Windows-only, and no Linux, Mac, or Android system can use the plugin. Make some DX12 call, and it's Windows 10-only, no Win7 or Win8 support. Such plugins would be distributed as shared libraries, which inherently embed platform-specific data and code, meaning even if you personally don't make any system-specific calls, you still have to build and provide multiple shared libs, one for each platform you want to support. You can also look forward to different CPUs. A plugin for 32-bit OpenMW and a plugin for 64-bit OpenMW, for each supported OS. Then you can look forward to different CPUs, some OSs supporting ARM (32-bit and 64-bit flavors).

With sandboxed-only code, we can ensure a script that works on one system can work on the others, no extra work on anyone's part to support. The same mod and same code would work everywhere. But as many other projects have shown, most people have a habit of just targeting the system they use which is likely also the most widely used, because it's easier to use what they're already familiar with (for most developers, non-portable Windows code) than to look for or request something new. So even though there are people using other systems, they'd be locked out from using those mods.

Stability. When the engine oversees everything a mod does, it can ensure correctness, warn of and workaround problems, and just generally handle errors gracefully. When a mod can call out to native code, the engine has no say in anything that goes on. The mod may work 95% of the time, so it's not a deal breaker but has an annoying tic. Add another mod that also works 95% of the time, and another. Then people complain how the engine is so unstable, while the engine can't do anything to fix the problems because it has no control over what those mods are doing.

Forward compatibility. Make a non-sandboxed plugin now, you can obviously only target systems that exist now because you can only build for systems that exist. When mods only use sandboxed code, any platform OpenMW itself can be ported to in the future will automatically inherit all existing mods. Even if the modder is long-gone, no changes are needed to the mod to support new systems.

Backwards compatibility. Systems aren't static, and code is not always bug-free. It's not hard to find cases where some code works while inadvertently relying on a bug or undefined behavior in the system. The system updates, and even though neither OpenMW or the mod changed, the plugin stops working because the undefined behavior changed. With sandboxed code, only OpenMW is responsible for ensuring the plugin works, so if a mod stops working, we can pinpoint what in OpenMW changed to make it stop working, and provide a built-in fix or some other workaround.

So 20 years down the line, when you want to revisit that old mod you remembered having a lot of fun with, you can be relatively sure it'll work regardless of all the system and engine updates that've occurred since the mod was last updated. And if there is an issue with the mod, you can report it to whoever's working on the engine to get it fixed and make it work again.

Or if you're getting fed up with whatever OS you're currently on, you don't have to be concerned about your mods being compatible with other platforms you're thinking about changing to.

Or if you hear about an awesome new mod coming out, you don't have to wonder if it'll support your system.

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

Re: The new MWSE-Lua interface

Post by SeaFox » 07 Oct 2018, 01:49

Chris wrote:
07 Oct 2018, 00:45
SeaFox wrote:
06 Oct 2018, 23:38
No it's not. Because the purpose of sandboxing is to protect your computer from malware.
there are more issues than that.
Perhaps. But none of the issues that you list change my argument that an option should exist for disabling sandboxing for those who wish to do so.

User avatar
AnyOldName3
Posts: 1121
Joined: 26 Nov 2015, 03:25

Re: The new MWSE-Lua interface

Post by AnyOldName3 » 07 Oct 2018, 02:18

If you want sandboxing, then you can simply just not download any mods which require unsandboxed access (provided they're labelled) and get exactly the same effect. Having an option to disable sandboxing is functionally identical and has all of the same problems as having no sandboxing. Your average not-particularly-savvy user is just going to see 'make sure to change this ini setting' in the installation instructions for a mod and not consider that there's a reason the setting started off disabled, just like how every Fallout 4 mod says to make sure you've changed a particular ini setting before installing it (as Bethesda decided that loading mods should be disabled in the ini by default) and users do that.

The discussion should be moot at this stage anyway - if sandboxing genuinely causes problems, it can be removed fairly easily, but if it's not there, it can never be added as that's breaking backwards compatibility and we'll lose compatibility with a load of mods which used native code even though they didn't strictly need to and also never be allowed to put that update on any debian-based Linux.
AnyOldName3, Master of Shadows

mychaelo
Posts: 10
Joined: 08 Aug 2014, 10:55

Re: The new MWSE-Lua interface

Post by mychaelo » 07 Oct 2018, 12:42

So I was bored on a train and read this entire thread, and I didn't see one good example of why would you need to turn off the sand box in OpenMW-lua. I get why you would need to do that in Morrowind - you can't do crap about it since it's an untouchable blob of copyrighted bits, so instead you hack around, hook it up and beat into submission.

But why would you program a C code around OpenMW instead of pull-requesting the API stuff you need, or feature-request it, and then code the stuff that uses it in LUA? Isn't writing C for existing codebase a lot easier than making a renderer hook from scratch?

Give me one example of a mod that cannot be done in openmw-lua, even with an augmented API

Post Reply

Who is online

Users browsing this forum: No registered users and 8 guests