MWSE, Lua and OpenMW compatibility

[Zini]

Actually, we could add a large percentage of MWSE even before 1.0, but that only applies when we define percentage based on keywords. I am still unsure about how useful that would be, because that will most likely leave out most of the interesting stuff; meaning that most existing content depending on MWSE would probably still not work with OpenMW. I am only guessing here though. I don't know what subset of MWSE typical content makes use of.

[NullCascade]

* There are some aspects in MWSE that trigger my security alert. That makes these aspects a complete no go. This is the one point where I take a hard stance. I do not compromise on security and there is nothing more to discuss.

I won't try to convince you. This is a travesty based on no evidence, but you're going to have your hard stances. I'll only point out that it's because of modders having more power than the original developers wanted that we have such a vibrant modding scene in Bethesda games.

* Some parts of MWSE seem to be incompatible with current OpenMW or enhancements planned for the future. I don't remember what the problems are anymore. Its been a long time when I last looked at MWSE.

I can't respond to that unless you provide something? Obviously the source wouldn't port directly, I don't think anyone expects that. But every feature in MWSE should be capable to be done in OpenMW.

* Some other parts of MWSE would require large scale enhancements that go beyond the plan for OpenMW 1.0. Also a no-go for now, but may reconsider after 1.0.

For example? The way we add strings and references to the mix? Yeah, it'd be a bit dirty, but worth it for a decade of modding to not be invalidated. I think you underestimate just how many mods use MWSE.

* And finally there remains a subset of MWSE that could be added without causing us problems now or further down the line. I just don't know how useful such a subset would be. I don't have a firm opinion on this point.

Again, example? I don't really know what you're talking about. I can't respond to vague statements like this. If you can give me something concrete I'll work with it.

* Lua is a completely different topic and I would prefer to discuss it another time (because that could be a lengthy discussion for which I really don't have the time right now)

The problem is that now is the time to have it. We have tes3mp working on Lua now. We have MWSE working on Lua now. If we have any hope of providing a uniform modding API that people can use between the 2-3 engines the discussion needs to happen now. In 6 months I'll be past 2.1 and have dehardcoded vanilla UI. I'll have shipped 2.1, and we'll go from ~20 mods released using 2.1 in the last month to even more. Every month that we drag our heels is another set of modders being invested in one system when they could instead become invested in a unified system.

Give me something concrete to work with, some examples. If you need me to go over the features of MWSE because you're not familiar with them, I'm happy to do so. If you need to talk in IRC, I'm happy to do so. If you want to hop in voice chat and go over things, I'm happy to do so. I'd hate to ask for a clarification on your clarification, but I feel all I heard was "no power to modders like they've had in Oblivion, Skyrim, Morrowind, and Fallout because security" and vague statements that I don't really know how to align to anything actionable. Let's talk specifics.

[psi29a]

For those things that MWSE that doesn't directly map to OpenMW 1:1, can't there be a sort of compatibility support that's there just to get mods working, even if partially?

There can be some give and take as well, MWSE 2.1 is an example of this.

[Zini]

That's the point. This is not the time. At least not for OpenMW. We have always stated that our first priority is OpenMW 1.0, a (reasonably) faithful re-implementation of vanilla Morrowind. This is our focus for now and we should avoid getting bogged down with stuff that does not fit into this category. We don't add other stuff (yet) or even plan other stuff (except for the post-1.0 design plan, which is near completion).

Only once we have a solid platform with 1.0, we will start to expand functionality (at this point rapidly though).

I can give you a quick run-down based on some of the stuff from here. But that is all I have to offer right now:

If we Just go by keywords MWSE seems to mostly consist of X-variants of existing keywords. That is the part we could handle, since our script engine supports keyword-aliasing easily. Since in OpenMW most the of limitations of the vanilla script engine don't exist anyway, making the X-variant a simple alias for the non-X-variant should do the job, example: XPosition. In OpenMW Position can take variables and even complex expression as arguments, so it should fully cover XPosition.

Generally we don't add new keywords that way (there will be a proper procedure after 1.0 for adding new keywords), but I don't think making an exception here would cause major problems.

An example for things we could add after 1.0 would be xSin (since there will be a Sin after 1.0).

Things like strings and refs we will definitely do not do the same way as in MWSE. There will be proper types.

Another issue I see right away is the xInventory keyword (there are probably others like this). It seems to return multiple values (3 in this case). That is something our script engine can not do and I have no intention of hacking it in, because that would (at best) cause us other problems further down the line or more likely break things right away.

[psi29a]

@Zini: if someone where to put the time and effort into doing a bit of this work now... pre 1.0, for example:
https://wiki.openmw.org/index.php?title=MWSE

then that's acceptable right?

When you say that some things are for post-1.0 (later, not now) you mean yourself and other openmw developers. However if someone comes along with a drive-by PR on GH and is like, here... i have shiny stuff for you, you'll at least consider it and we can have a technical discussion about it right?

TES3MP's goal is to eventually get merged into OpenMW, OpenMW wants this to happen, it's a long-term goal as stated in our FAQ and the reason why I asked TES3MP to join us here in the forums. That we get LUA along with this, at least on the server side of things, is a step in the right direction. More thought will have to go into actually bringing it into the client as well.

[Zini]

@Zini: if someone where to put the time and effort into doing a bit of this work now... pre 1.0, for example:

It is not, except for the cases where it is. As described above most of the functionality (but not the keywords) are problematic, some generally, some pre 1.0. The only thing I can see go into OpenMW right now is the X-ing of keywords. If that is actually desirable (still not sure about that), I could easily find an hour next week to put it in (if someone can provide me with a complete list of X-keywords that match existing keywords with the additional flexibility regarding arguments).

[NullCascade]

So from the sounds of it there still isn't anything actionable for me. OpenMW isn't interested in collaborating on unified API, nor is it interested in practical backwards compatibility with MWSE. This is in line with what you said before, but thank you for the clarification.

The MWSE page on the wiki does need updating, it doesn't take into account the latest updates in the 0.9 branch or the 2.0 branch.

It's my understanding that people have tried to add MWSE support in the past and not had their PRs merged. And like Zini says, without attempts to be backwards compatible with the way modders have used strings/references in mwscript for years, MWSE use is limited. You'll get some bang by aliasing x-prefixed functions that accept variables, but not anything that the major mods use.

Zini has his scripting plans that he'll one day share. tes3mp is going off in its own direction. MWSE is going on in its own direction.

[psi29a]

tes3mp is going off in its own direction.

@TeamTES3MP: care to share?

As far as I was aware, we were on the same line and the two leads, DavidC and Koncord are here on the forums. Just talked with David a few days ago about an important feature in TES3MP that would have implications for OpenMW users as well in which he also talked with Zini and we more or less hammered out something that should work. I mean, one doesn't work this closely with others only to then go off in another direction.

[NullCascade]

tes3mp is going off in its own direction.

@TeamTES3MP: care to share?

As far as I was aware, we were on the same line and the two leads, DavidC and Koncord are here on the forums. Just talked with David a few days ago about an important feature in TES3MP that would have implications for OpenMW users as well in which he also talked with Zini and we more or less hammered out something that should work. I mean, one doesn't work this closely with others only to then go off in another direction.

Didn't mean to make it sound like I was speaking for tes3mp or anything. Just that the 3 projects have 3 different ways of modding.

[Zini]

Just for the record TES3MP is not going its own direction. I am in regular PM contact with davidcernat.

But yeah, basically. I don't oppose MWSE backwards compatibility per see (except for the security relevant issues) but not at the expense of our own post 1.0 plans.

The only way I can think of to achieve (almost-) backwards compatibility with MWSE would be a translation tool that turns MWSE into OpenMW script. A Python script (because post 1.0 OpenMW-CS will use Python as scripting language) would do the job. It would have to be a fairly complex script though and that would still require running all relevant content files through OpenMW-CS once before they can be used by OpenMW.