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

Re: Post 1.0 Planning Update

Post by Chris »

DestinedToDie wrote: 08 Apr 2018, 19:29 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.
Keywords being "comfy to use". Even with the things vanilla does, there are a multitude of ways scripting can be improved to be less of a hassle, both in regards to functionality (functions and event callbacks, to avoid making each script its own finite state machine that's wasting CPU cycles 99% of the time) and syntax (clearer method handling, logical operators, etc). Even without exceeding what vanilla scripts do, it could be made much simpler and compact, with clearer reasoning and fewer bugs, with an improved scripting language.
LoneWolf
Posts: 138
Joined: 26 Sep 2017, 19:13

Re: Post 1.0 Planning Update

Post by LoneWolf »

I have done some modding for Oolite in the past, and i think morrowind / TES3MP / OPenMW modding community has a bigger problem then choosing a scripting language .

Currently there's a lack of mods with licenses that encourage code re-use & sharing.
example :
yesterday i looked for a beast race mod, found one which description looked promising.
I went to the site of the author, they only allowed 2 locations to provide a download.
One location stopped hosting mods, the other is some forum that requires registration.
I like my privacy, so didn't register.
That mod has a very small chance to still exist in a few years.

Oolite solved these issues by encouraging modders to use free filehosters (like box.com) and debate which licenses were suitable.
CC-by-SA (often with non-commercial added) is* the license most used for oolite mods.
That license allows copying , distributing , modifyingetc yet at the sametime makes sure the original author name stays with the code eternally .
(every new author adds their name ofcurse).

There are oolite mods that have a long copyright list with many names on them.
Even if all the modders active now neglect that mod, all it takes to revive the mod is one person that steps up and takes over maintenance.
That's the benefit a good license brings.

* been 3+ years since I did any oolite modding, no idea if "was" is more appropriate here.
User avatar
Shnatsel
Posts: 64
Joined: 31 Oct 2014, 01:06
Location: Moscow
Contact:

Re: Post 1.0 Planning Update

Post by Shnatsel »

I can see at least three distinct desirable features for OpenMW scripting:

1. Support for legacy mwscript+MWSE mods in some form, or at least easing conversion of legacy mods to work on OpenMW.

2. Easing creation of OpenMW-specific mods and exposing additional capabilities to modders.

3. Providing a unified modding API for Morrowind that is supported by both OpenMW and MWSE 2.x

NullCascade, I find it hard to believe that someone would oppose a pull request that creates a unified modding API supported by both MWSE 2.x and OpenMW, even if it uses a scripting language other than the one used to solve point 2. Well, provided that it actually works out, and doesn't end up in an endless cycle of subtle incompatibilities between OpenMW and MWSE implementations. Which, knowing the history of JavaScript and web browsers, it will. But I'm all for it anyway.

So guys, you can stop arguing now and actually get down to integrating Lua and investigating the incompatibilities between OpenMW and MWSE implementations of the unified API. Once it is demonstrated to work identically on both ends and provide important capabilities beyond that of vanilla mwscript, not even Zini would get away with rejecting a PR with it. ;)
NullCascade
Posts: 121
Joined: 16 Jan 2012, 07:58

Re: Post 1.0 Planning Update

Post by NullCascade »

Shnatsel wrote: 09 Apr 2018, 02:33NullCascade, I find it hard to believe that someone would oppose a pull request that creates a unified modding API supported by both MWSE 2.x and OpenMW, even if it uses a scripting language other than the one used to solve point 2. Well, provided that it actually works out, and doesn't end up in an endless cycle of subtle incompatibilities between OpenMW and MWSE implementations. Which, knowing the history of JavaScript and web browsers, it will. But I'm all for it anyway.

So guys, you can stop arguing now and actually get down to integrating Lua and investigating the incompatibilities between OpenMW and MWSE implementations of the unified API. Once it is demonstrated to work identically on both ends and provide important capabilities beyond that of vanilla mwscript, not even Zini would get away with rejecting a PR with it. ;)
People have done expanded scripting APIs and MWSE support in the past, and were not merged. I'm not going to do all the work, if Zini is just going to ignore it. I've made the offer to make MWSE's new Lua scripting/event system/dehardcoding try to work to be compatible with OpenMW. The ball is in his court, but he just doesn't seem interested in playing.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Post 1.0 Planning Update

Post by AnyOldName3 »

You've spent the whole thread putting words into his mouth, so I imagine he's got less patience to discuss it than he might otherwise have.

The plan has always been for 1.0 to be released, then for Zini's design document outlining his vision to be revealed to Scrawl so he can pick holes in it, and then to the rest of us. That's when we get to tear it to shreds. The previous discussion on extended scripting capabilities has always been that Zini is unconvinced of a need for scripts to execute native code, and would rather we at least tried to make MWScript not suck before abandoning it, but he's never said he's not open to having a secondary scripting language available if it's what the community needs.

The biggest hurdle to all of this, though, is that Zini seems to be busy. That's the most likely reason why you've not got the detailed reply that you want.
NullCascade
Posts: 121
Joined: 16 Jan 2012, 07:58

Re: Post 1.0 Planning Update

Post by NullCascade »

AnyOldName3 wrote: 09 Apr 2018, 22:41You've spent the whole thread putting words into his mouth, so I imagine he's got less patience to discuss it than he might otherwise have.
That's the problem with not having open discussions about things. We both have limited information so we're filling in with our own wants/fears. You've "put words into his mouth" claiming things will be supported that he hasn't said he would be. I've "put words into his mouth" claiming he's against something because he's spoken only negatively about it, and positively about the alternative. We're both talking out of our ass, because we don't have concrete statements from him to work with. Which is why the ball is in his court.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Post 1.0 Planning Update

Post by AnyOldName3 »

Except I'm not saying anything will be supported except for things he's said will be supported in other threads where the topic has come up. I have specified what I think is likely or unlikely based on things he's said in other threads, which I suppose could be classed as interpreting what's been said, but I'm pretty sure that nothing I've said is wrong and that everything I've said could be backed up with quotations were I to go through the entire history of every thread I've read here in the last few years. I'm not going to do that, though, as it would be a colossal waste of time.

The gist of things is that I trust Zini not to let scripting suck forever, and even the event that we end up iterating through a bunch of prototypes as his original ideas were crap, the end result will be good. When the full version of the design document is released to the public, that's the time to pick holes in it as that will be the first non-vague statement that holds any weight.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Post 1.0 Planning Update

Post by Zini »

Just skimmed through the thread. Just for the record, my absence from the discussion is less an issue of time. I don't see how anything useful could be gained from continuing the discussion. Everything that needed to be said has been said already and continuing would just mean beating on each other with ever increasing hostility without achieving anything. Sometimes one has just to agree to disagree.

As mentioned before (and probably drowned out by all the noise) there will be a separate discussion about the choice of language before we get started on the design document; but just the language, the question of sandboxing is not open to discussion. As you have seen by now every single OpenMW dev who posted in this thread insists on it.
User avatar
Shnatsel
Posts: 64
Joined: 31 Oct 2014, 01:06
Location: Moscow
Contact:

Re: Post 1.0 Planning Update

Post by Shnatsel »

Okay, does this sound an actionable plan that we can all agree on?

1. Wait for 1.0 to be released (or help it along ;) )
2. Discuss and pick a course of action for supporting legacy MWSE/mwscript mods (with "not supporting them" also being a valid course of action)
3. Explore the desirability and viability of a unified OpenMW/MWSE 2.x modding API. I imagine some prototyping will be in order.
4. Discuss and pick a course of action for improved scripting in OpenMW-specific mods. This will be likely affected by the results from point 3.
5. Iterate on the implementation of all of the above
6. Stabilize the implementation and turn it on by default in stable releases of OpenMW
User avatar
Jemolk
Posts: 237
Joined: 20 Mar 2017, 02:12
Location: Sadrith Mora

Re: Post 1.0 Planning Update

Post by Jemolk »

Zini wrote: 10 Apr 2018, 08:40 Just skimmed through the thread. Just for the record, my absence from the discussion is less an issue of time. I don't see how anything useful could be gained from continuing the discussion. Everything that needed to be said has been said already and continuing would just mean beating on each other with ever increasing hostility without achieving anything. Sometimes one has just to agree to disagree.

As mentioned before (and probably drowned out by all the noise) there will be a separate discussion about the choice of language before we get started on the design document; but just the language, the question of sandboxing is not open to discussion. As you have seen by now every single OpenMW dev who posted in this thread insists on it.
I have to admit, I do still think your worries about sandboxing are working off an unrealistic and frankly beyond extreme threat model that we would never actually experience, ever. But if you're so dead-set on this, then so be it. I merely hoped to persuade, and that's failed. I'll admit defeat on that point.

If NullCascade can create a LUA implementation that would be broadly compatible with the MWSE API for the features of LUA that are adequately (in your view) sandboxed, would you consider merging it? That is, such that mod scripts that were not adequately sandboxed wouldn't function properly, but most would transfer just fine? If NullCascade is willing to volunteer to maintain that portion of the code as well, I see no real downside from the standpoint of OpenMW, and this would go a long way towards making OpenMW the definitive engine. This would also make LUA probably the best option for scripting, since we have a volunteer already available to work on it, and it can be sandboxed in the way you want. An answer from you specifically, Zini, on this particular question, I think, would be very meaningful indeed.
Post Reply