Post 1.0 Planning Update

Anything related to PR, release planning and any other non-technical idea how to move the project forward should be discussed here.
Chris
Posts: 1386
Joined: 04 Sep 2011, 08:33

Re: Post 1.0 Planning Update

Post by Chris » 06 Apr 2018, 03:14

NullCascade wrote:
06 Apr 2018, 02:31
But if in a few days I could add Lua scripting overrides to MWSE, without any source code, just how big of a project do you possibly think it could be to do it to OpenMW?
To create a Lua script that will run every frame, like a normal Morrowind script, start off by creating your vanilla script. [...]
I don't think this is the kind of hack-kneed support we'd want for Lua. If and when we support Lua, it should be a first-class scripting language that is correctly integrated into the engine. Such a thing will take time to do properly. And even with proper Lua support, there are still benefits to providing some improvements to mwscript as well.
NullCascade wrote:
06 Apr 2018, 02:31
Do you have any actual factual backing to this? Lua is sandboxed. Lua is shipped in major PC (and console/mobile) games. Where's this giant scandal that Lua is insecure?
Again, you're conflating two separate arguments. No one in this thread has argued against Lua support (Zini has been outspoken against it in the past and prefers to extend mwscript, but I don't imagine he'd ignore if there's a huge push from modders for it). What people have been arguing against is allowing scripts to call system APIs directly, instead of remaining fully sandboxed.
NullCascade wrote:
06 Apr 2018, 02:31
So let me get this straight. Instead of giving modders enough power that they can in in 30 minutes or less create a Discord RPC mod like I did with MWSE 2.1, you're advocating... some generic API?
Like I said:
Sometimes it'll take a bit more work to achieve, and sometimes it'll come with compromises, but if the result is a secure, stable mod that everyone can use and will still work in 10 years, then IMO that's better than giving them arbitrary code access that can get it done faster while locking out systems the modder doesn't care about and exposing the mod and users to potential future problems the engine can't help with.
Providing short-term gains (implemented in 30 minutes or less, or your money back!) at the cost of long-term stability (we now have a bunch of mods that don't work on various systems that we can't do anything about, are causing crashes we can't prevent, and there's some running around with viruses and trojans) isn't conducive to the longevity of a project.
NullCascade wrote:
06 Apr 2018, 02:31
You can't. You have to, at some point, have someone, somewhere, write native code.
OpenMW would implement the necessary native code to talk to Discord. OpenMW would also implement an abstract interface for mods to use. Mods would make the necessary calls to the abstract interface, and OpenMW ensures the appropriate native code runs to have the desired effect. Presuming Discord integration is something modders and users truly want anyway, and not stop caring about the feature after a year or something.

NullCascade
Posts: 42
Joined: 16 Jan 2012, 07:58
Github profile: https://github.com/NullCascade/

Re: Post 1.0 Planning Update

Post by NullCascade » 06 Apr 2018, 03:40

Chris wrote:
06 Apr 2018, 03:14
I don't think this is the kind of hack-kneed support we'd want for Lua. If and when we support Lua, it should be a first-class scripting language that is correctly integrated into the engine. Such a thing will take time to do properly. And even with proper Lua support, there are still benefits to providing some improvements to mwscript as well.
You're completely missing the point and ignoring what I said.
You don't have to do hacky things or do any reverse engineering, just basic data binding and script calls.
Same with some of your other arguments. It's really not as hard as you think. It's way harder to find someone with the expertise and willingness to make mwscript a first-class language than it is to find someone that can make Lua OpenMW's first-class language.

Lua has sandboxing. Lua has ease of implementation. Lua has features. Lua has speed. Lua is cross-platform. Lua has a stable history. What box does it not check? Let people use it, first-class, then let people toggle on features that are't enabled by default. All problems solved. Boom.
MWSE 2.x lead.

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

Re: Post 1.0 Planning Update

Post by AnyOldName3 » 06 Apr 2018, 04:04

Lua FFI does not have sandboxing. People are only arguing against Lua FFI, not against Lua itself.

Regarding what Chris has been saying, though, I don't see how we could have the Discord plugin without either the whole thing being included in OpenMW or allowing OpenMW mods to call external code. Discord provide both a DLL/unix library and source code which expose some functions which need to be passed some data. This isn't written in MWScript, so it can't be made into a mod through some fancy interface unless that fancy interface allows arbitrary code to be called.
AnyOldName3, Master of Shadows

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

Re: Post 1.0 Planning Update

Post by Chris » 06 Apr 2018, 04:25

AnyOldName3 wrote:
06 Apr 2018, 04:04
Regarding what Chris has been saying, though, I don't see how we could have the Discord plugin without either the whole thing being included in OpenMW or allowing OpenMW mods to call external code.
What do you mean? I presume Discord integration works by making appropriate IPC/RPC calls to an external Discord process depending on what you want to do, and watching for IPC responses to see what happens. Or is it that an app is expected to contain its own implementation of Discord or something?

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

Re: Post 1.0 Planning Update

Post by AnyOldName3 » 06 Apr 2018, 05:04

You have a library (either as source or precompiled) and it exposes about five functions. Calling these with the data you want to give Discord as an argument makes the library magically make Discord have the data. I don't know if it works by creating a network connection and RPCing the data to Discord's servers or if it puts it in an HTTP GET or POST and delivers that or if it works by passing the data onto an already-running Discord process on the same machine, and the documentation doesn't go into detail with this as it's not something a user of the API is supposed to concern themselves with. As the library is MIT/Expat licenced with the source available, you could look through the source and figure out some other way of implementing it, but if it works by RPC or HTTP then our magic non-discord-specific API would have to allow partially programmable network access (which could be abused) and if it works by sending data to a local process, it would have to allow partially programmable data to be sent to a plugin-specified process (which could also be abused).
AnyOldName3, Master of Shadows

NullCascade
Posts: 42
Joined: 16 Jan 2012, 07:58
Github profile: https://github.com/NullCascade/

Re: Post 1.0 Planning Update

Post by NullCascade » 06 Apr 2018, 05:14

AnyOldName3 wrote:
06 Apr 2018, 04:04
Lua FFI does not have sandboxing. People are only arguing against Lua FFI, not against Lua itself.
FFI is a library like everything else. You have to opt in to it. You can have LuaJIT without FFI. And you can have a config option allow enabling FFI.

You're dead on about Discord and capabilities though. I think Discord does use IPC/RPC but that's not really the point. Opening up those is going to cause potential abuses that aren't worth guarding against. And there's plenty of other APIs that don't use IPC/RPC. What about interfacing with those?
MWSE 2.x lead.

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

Re: Post 1.0 Planning Update

Post by Chris » 06 Apr 2018, 05:40

AnyOldName3 wrote:
06 Apr 2018, 05:04
I don't know if it works by creating a network connection and RPCing the data to Discord's servers or if it puts it in an HTTP GET or POST and delivers that or if it works by passing the data onto an already-running Discord process on the same machine, and the documentation doesn't go into detail with this as it's not something a user of the API is supposed to concern themselves with.
For other apps that integrate with Discord, do they have a discord process running in the background? Though given that the library is open source under a permissive license, I can't foresee much of an issue with OpenMW integrating whatever code it needs to.

davidcernat
Posts: 32
Joined: 19 Jul 2016, 01:02

Re: Post 1.0 Planning Update

Post by davidcernat » 06 Apr 2018, 06:51

First off, the starting point for any conversation should be unconditional and utmost respect for Zini. Here is someone who took what was then a completely dead project and sacrificed 8 years of his life on turning it into one of the most impressive open source engine recreations of all time. Without his constant capable leadership, we wouldn't have people come in and complain about their inability to script in anything they can think of in OpenMW... we just wouldn't have an OpenMW for people to complain about. He deserves both the benefit of the doubt and that of a measured, respectful discussion that always keeps everything in its proper perspective.

My own two cents are that, if OpenMW's ambition is greater than just recreating Morrowind and extends to allowing anyone to create Morrowind-like games, such ambition would benefit from having some form of multiplayer built in, which in turn would require a serverside scripting system. Scripts written for multiplayer work out-of-the-box in singleplayer (on a single person server), while the reverse is not true, with singleplayer-specific scripting systems causing endless problems in a multiplayer context.

If we really don't want to split up the modding community, then MWSE is not the answer, because it will never have multiplayer, which many are really attracted to. TES3MP isn't the answer either because it doesn't have the high standards of OpenMW.

The real answer, in my opinion, is an OpenMW that takes in parts of TES3MP and does them better.

User avatar
scrawl
Posts: 2148
Joined: 18 Feb 2012, 11:51
Contact:

Re: Post 1.0 Planning Update

Post by scrawl » 06 Apr 2018, 22:08

Well, this thread turned into a trainwreck. I think I agree the most with Chris' train of thought. Sandboxing is important. Lua, (with the dangerous extensions taken out and not optionally enable-able, because if you let people shoot themselves in the foot, they will) sounds good. Binding the currently available mwscript functions to lua should be quite easy and that alone will make scripting with lua a rather nice quality of life improvement. Anything beyond that will need to be considered more carefully. That doesn't mean that super crazy mods that call arbitrary programs or talk to internet servers can't possibly be made, just that they're not our problem.

User avatar
DestinedToDie
Posts: 1104
Joined: 29 Jun 2015, 09:08

Re: Post 1.0 Planning Update

Post by DestinedToDie » 08 Apr 2018, 19:29

The LUA stuff seems quite utopian, even so that I am starting to dislike the idea. For me, scripts are simple short code snippets that make simple things happen in the game. I don't think I'm supposed to go full programmer on them. Just extend the functions and make it more comfy to use. I don't even want to see the capability to program sentient AI with LUA scripts on what's supposed to be a simple first person RPG engine.

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests