The new MWSE-Lua interface

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

Re: The new MWSE-Lua interface

Post by CMAugust » 02 Oct 2018, 13:41

Yeah, I mean the addition of (new) GUI icons for additional functionality (such as what appears in this mod) wouldn't be out of the question, right?

In any case, the stage 1 document shows that more GUI configuration options are definitely on the way. If the existing plans are not sufficient, perhaps they can be expanded via feedback? Failing that, the document leaves open the possibility of a full-scale GUI framework if it's needed after all.

User avatar
Jemolk
Posts: 224
Joined: 20 Mar 2017, 02:12
Location: Sadrith Mora

Re: The new MWSE-Lua interface

Post by Jemolk » 03 Oct 2018, 02:10

I will be honest, the insistence that we don't need or want to have easy compatibility with MWSE mods that don't rely on not being sandboxed annoys me to no end. Why not? If the vanilla engine + MWSE is more moddable, a tremendous amount of effort will have been straight-up wasted here. Better to allow the somewhat sub-optimal implementations for cases where we haven't yet gotten the functionality into the engine, and switch it over once we have, I say. I just...seriously, for heaven's sakes, I'm a Linux user who's becoming half inclined to run the original engine in a VM because it's feeling more and more like OpenMW is not going to be remotely as open as vanilla + MWSE even AFTER dehardcoding. What even IS this? Sure, better to have features integrated than not. Also FAR better to have them exist than not, and the latter massively overrides the former in importance for most players and modders, and is what is being denied by OpemMW until someone eventually gets around to merging a feature that was modded into vanilla with ease thanks to MWSE.

Insist on sandboxing, sure, fine. Some mods need to be changed because the vanilla compiler was bonkers and we want ours not to be, fine, sure. Going "you can't do this yet because we prohibited you from fiddling with it like MWSE allows you because you can implement it in the engine, but we haven't" is very much NOT fine, and making it more difficult than it needs to be to use the same mods on vanilla + MWSE and OpenMW despite having the same functionality is likewise NOT fine, EVEN if the reason is a better, more optimal implementation in OpenMW, because that should not preclude allowing the suboptimal implementation to at least function so we don't have to do too much screwing around and converting all the time.

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

Re: The new MWSE-Lua interface

Post by CMAugust » 03 Oct 2018, 03:26

Insist on sandboxing, sure, fine.
According to the initial discussion in this thread, isn't sandboxing the reason NullCascade did not develop OpenMW-Lua alongside MWSE-Lua?

NullCascade
Posts: 120
Joined: 16 Jan 2012, 07:58

Re: The new MWSE-Lua interface

Post by NullCascade » 03 Oct 2018, 04:14

CMAugust wrote:
03 Oct 2018, 03:26
Insist on sandboxing, sure, fine.
According to the initial discussion in this thread, isn't sandboxing the reason NullCascade did not develop OpenMW-Lua alongside MWSE-Lua?
I'm here to expand what modders can do, not tie their hands.
Jemolk wrote:
03 Oct 2018, 02:10
I'm a Linux user who's becoming half inclined to run the original engine in a VM because it's feeling more and more like OpenMW is not going to be remotely as open as vanilla + MWSE even AFTER dehardcoding.
Hit me up on Discord. We tested MWSE on Linux earlier, and it mostly comes down to some APIs related to DLL peeking and user input being blocked by wine. Should be fixable, but I don't have Linux installed anymore and could use someone to test.
MWSE 2.x lead.

User avatar
akortunov
Posts: 757
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation

Re: The new MWSE-Lua interface

Post by akortunov » 03 Oct 2018, 05:54

I am pretty sure that at least 90% of MWSE mods, which will use custom binaries, will be Windows-only anyway, even if we will not sandbox Lua.
Loading a custom executable or library on a random Linux distribution can be a hell because of software dependencies.

User avatar
psi29a
Posts: 4896
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: The new MWSE-Lua interface

Post by psi29a » 03 Oct 2018, 08:28

We've already hit the sandboxing issue in other threads and why most (all?) OpenMW developers are against it:
viewtopic.php?f=2&t=5222&p=55425&hilit=sandbox#p55425
viewtopic.php?f=20&t=5075&p=53532&hilit=malware#p53532
viewtopic.php?f=2&t=5222&p=55390&hilit=malware#p55390

Are we going to keep talking in circles here or what?

I wouldn't be surprised if someone hasn't already made attempts at getting MWSE working with OpenMW itself. ;) I admit, getting MWSE working under Wine is a great win for those wanting to play Morrowind on Linux (and anywhere wine works).

The point is, someone shouldn't have to since OpenMW can be improved (by virtue of being open-source) while Morrowind itself can't and has to rely on MWSE and tools like it.

You want to be able to modify the UI to your liking, that's pretty much the point of having the MyGUI library with the XML files available. In addition to this, I'm sure having access to the UI via newscript (aka Lua) isn't out of the question either.

There is absolutely no reason to need unfettered access to the underlying file-system for this kind of feature. I do see however that people will use any excuse, however small, to promote their anti-sandbox agenda and pass it off with 'we should trust modders to do the right thing'. That's cool and all until we get a CVE [1] telling us that we have a security exploit that threatens OpenMW with removal from BSD and Linux distributions until the problem is 'addressed'. This could be a privilege escalation bug in OpenMW itself that was triggered by a 'mod' that was injecting their own binary content into the running process. The largest target platform is still Windows, so I can imagine that it has the largest installed base but OpenMW runs elsewhere and could be targeted by anyone else.

That leads us to another point, a 'mod' that does need unfettered access then will be platform specific which is against the OpenMW ethos of being multi-platform.

The point is, OpenMW and its (future) Lua scripting environment should not even need to have unfettered access to the user's account, permissions and files as it evolves to the needs of modders.

[1] Common Vulnerabilities and Exposures - https://cve.mitre.org/

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

Re: The new MWSE-Lua interface

Post by Chris » 03 Oct 2018, 08:53

NullCascade wrote:
03 Oct 2018, 04:14
I'm here to expand what modders can do, not tie their hands.
As is OpenMW, by virtue of being open source. The scripting engine isn't the end-all-be-all of what mods can do with the engine, and even in the cases where it is what should be used, there's far better ways to deal with features than just handing modders the keys to the system. There's a difference between "not tying their hands", and giving them a gun that's permanently aimed at their feet.

User avatar
ap0
Posts: 290
Joined: 11 Aug 2011, 18:47
Contact:

Re: The new MWSE-Lua interface

Post by ap0 » 03 Oct 2018, 09:38

Speaking of being open-source, anyone is free to fork OpenMW to implement whatever they want, if they disagree with the direction of the project, it's ok :)

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

Re: The new MWSE-Lua interface

Post by Capostrophic » 03 Oct 2018, 14:11

Maintaining software forks single-handedly is a huge workload and not an easy job.

I predict this to be another drama discussion thread. :/

User avatar
akortunov
Posts: 757
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation

Re: The new MWSE-Lua interface

Post by akortunov » 03 Oct 2018, 14:23

Capostrophic wrote:
03 Oct 2018, 14:11
Maintaining software forks single-handedly is a huge workload and not an easy job.
If most of MWSE 2.x functionality will be mainline, this fork will be supposed only to disable sandboxing.
I suppose there will not be a very large amount of code.

Post Reply