openmw.org

darkbasic wrote:I somehow agree with commodore256, because almost no one is playing plain old Morrowind anymore and I fear that releasing 1.0 without mod support will let you lose lots of potential users. I agree that we should definitely get a better scripting system, but support for old mods is extremely important because the gold age of Morrowind mods has passed, unfortunately.

Just want to post and say that I agree here. I downloaded 0.39, played around vanilla, then tried to play my modded setup. The loss of distant lands, MWSE functionality, and MCP features, as well as incorrectly rendered lighting/lack of shadows, means I have still chosen to stick with the "vanilla" Morrowind engine over OpenMW.

I think the project has a lot to gain by delaying the publicity-packed OpenMW 1.0 until the answer to the common "Is OpenMW matured enough to replace vanilla for my playthrough?" is no longer "Yes, but you lose out on big things like X, Y, and Z."

NullCascade wrote:The loss of distant lands and MCP features

But this WILL mean that fewer people (and importantly: programmers) will hear about the project, which will mean you will have to wait even longer for features like this. You can't just wish for fancy graphics features and they will appear, someone will have to do it and it takes time. And this time is needed to get the real core features of the engine in the game. Why let one programmer (read: scrawl) do EVERYTHING that has to do with fancy graphics, when you just can release 1.0 when the engine is feature complete like currently planned, get tons of PR (read: programmers will find out about this and join the project) and then have several programmers working on these features.

It's not so easy to just implement features fast without enough manpower.

psi29a wrote:We await your pull/merge requests.

It would be definitely funny contributing code to openmw, but I'm a full stack javascript developer so it will take much more efforts than I could afford. That's why I chosed to contribute economically instead.

Oh no worries. I wasn't calling _you_ in particular out, and I know people that can are also busy with real life and can't afford the time to commit to adding features such as MWSE.

If people want features and they are able to, then do it. There are many things implemented in OpenMW that were for post 1.0 but added because someone with the ability to add the features wanted it badly enough to implement. Big thanks to Scrawl for many of the graphical wonders.

Say, for example, that OpenMW is 'done' meaning you can play the game without bugs but no one can be arsed to work on MWSE support. Is it then wise to delay releasing OpenMW as 1.0 until someone does get MWSE support in? Be it 2 months, 5... a year? That is a bit ridiculous considering that this is a volunteer project.

The line in the sand has been drawn years ago, and moving it around is feature creep. Let us hold on to the milestone that we've set for ourselves for the time being.

Well, Scrawl has already implemented non-vanilla features like the virtual file system and Cell pre-loading.

I'm not asking for extra graphics from MGSE, that's an eye candy nicety that can be implemented later, but people will be disappointed with it lacking compatibility with MWSE. I'm not saying don't add the missing 1.0 features first, I'm saying maybe we should slightly adjust the 1.0 roadmap and get the graphical features and removing of hard coding go into OpenMW-future. I don't know, maybe we should do a poll. We could make a Google Forums survey and send it to our outreach and ask if 1.0 was released and it was incompatible with their quest mods, would they be pissed off? If a majority said "yes", what do you think we should do? Should we just add another iterative release to major Version 0 that was suppose to be 1.0 with the old roadmap or should we just ignore them and release it anyway? I know we're worried about feature creep, but we're not asking for eye candy niceties.

I'm starting to see it from the perspective of it being more convenient to be going according to plan and I'm starting to think maybe we should, but I think this thread just opened a can of worms.

Is MWSE even on the roadmap in the first place? If memory serves, previous discussions about extending the scripting language have concluded that OpenMW will eventually need feature parity with MWSE, but that compatibility with MWSE is not likely to be a goal. In other words mods that require MWSE will probably never work with OpenMW, regardless of how long 1.0 is delayed.

There seem to be some confusion regarding MWSE. We will eventually acquire most of its functionality (and in fact have done so already in some cases), but we will not directly implement it. There will be no compatibility with MWSE.

I feel like I have explained that a dozen times now and we have made it very clear that we will not directly support 3rd party tools anyway. But okay, once more:

I am kinda neutral about implementing the X-forms of existing MW script instructions simply as aliases of the existing functions. I have no intention of implementing them myself but it would be trivial. Just a bunch of copy and paste and pressing the X key. A non-coder with a working development environment could do that.

I will veto the file I/O functionality because that is a potential security risk. We could come up with a more limited implementation but honestly, I don't see the point.

The way certain other features are handled in MWSE is problematic or suboptimal. I recognise that the developers of MWSE did the best they could do with what they had, but we are in a completely different situation. That means both that we have better ways of doing things and that doing things the MWSE way would be unusually hard.

For example the reference handling feature of MWSE seems to be based on long type variables. This is just not going to work with OpenMW. We would have to introduce additional mapping data structures and a whole lot of new bookkeeping code, which may have impact on performance, saved game file size and probably other things. Just not worth it.

Bottom line, most of the MWSE functionality will be available eventually in one form or another, but existing content files based on MWSE will have to be modified or rewritten (if modification isn't possible because of license reasons).

Edit: K0kt409P beat me to it.

We need a FAQ entry for MWSE (and other third-party) as it doesn't exist here:
https://openmw.org/faq/

Both OpenMW-CS and OpenMW are written from scratch and aren’t made to support any third party programs the original Morrowind engine uses to improve its functionality.

^-- is not obvious enough.

You say that some of MWSE's features will be implemented in "one form or another". What does this mean? Will the names of the functions stay the same or be something new?

Why do we have this page on in the wiki?
https://wiki.openmw.org/index.php?title=MWSE

Should this be changed to indicate that there won't be any MWSE support? I ask this because it says:

Here is the list of MWSE functions and their current status in OpenMW. There are no plans to support MWSE before the 1.0 release, and no commands will be added until then to reduce bug fixing overhead.

This indicates that MWSE _is_ coming, eventually.

Zini wrote:existing content files based on MWSE will have to be modified or rewritten

Oh, that's a pity

I have no idea why we have the wiki page in its current form. I remember vaguely to have pointed out the MWSE situation to someone who wanted to create such a page. But apparently that person ignored my input. Or I could misremember it. That was a long time ago.

You say that some of MWSE's features will be implemented in "one form or another". What does this mean? Will the names of the functions stay the same or be something new?

Obviously The X prefix is pointless for OpenMW. As mentioned above we could add x forms as aliases, but that wouldn't do all that much for compatibility.

The reference feature is another example. As mentioned above we will definitely not use a long variable to identify references. The details aren't finalised yet, but we probably will have a dedicated type for references instead. I am also not overly fond of the way MWSE is iterating over references. I suspect we can do it better, but again the details have not been finalised yet.

One more example. Attribute functions. With the upcoming dehardcoding there is little point in adding new functions that explicitly include attribute names. Instead for future improvements the attribute will be an argument for the function.