The new MWSE-Lua interface

[SeaFox]

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

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

I wonder if it would be practical for both a sandboxed version AND a non-sandboxed version of OpenMW to be maintained officially as part of the OpenMW project. This would make many people happy, allow for using and experimenting with a larger number of mods, and would possibly allow for a staged introduction of new features to the sandboxed version.

Risky new features could first be introduced as a MWSE plugin for the non-sandboxed fork, and if they prove themselves to be useful and desireable, would then be ported to the sandbox version.

[AnyOldName3]

Risky new features could first be introduced as a MWSE plugin for the non-sandboxed fork, and if they prove themselves to be useful and desireable, would then be ported to the sandbox version.

Implementing something as a non-sandboxed MWSE-style plugin is always going to be harder than just implementing it in OpenMW directly, so there's absolutely no benefit to this approach.

[SeaFox]

Implementing something as a non-sandboxed MWSE-style plugin is always going to be harder than just implementing it in OpenMW directly, so there's absolutely no benefit to this approach.

I can see how that would be true for an OpenMW programmer. But most modders are not OpenMW programmers. For them, it may be far easier and less time consuming to create a simple pluggin than it would be to recompile the entire OpenMW project.

[sjek]

if it would be GUI framework it would be some sort of like mygui's editor i suppose.
http://mygui.info/images/screenshots_3.2.1/3.png

The question is how much the scripting is wanted like filtering by magic school.

if it's not changed, MWSE still go trought the whole spell list and sorts them accordingly maybe in the moment that icon is pressed .?
Openmw would then have list saved first to GMST or variable and that is shown to the player .?

On little opposite side the gui would be needed to be customisable on the fly or some pointer to right splot on the gui?
How MWSE currently does that ?

edit: further reading is good usually

The only feature that UI Extensions and OpenMW have in common (AFAIK) is the spell search. This shows another benefit, as talked about on Discord with, I think, Capostrophic. UI Extensions ships assets. In my take of the spell search option, you can not only search by spell name, but also filter by school. OpenMW can't offer that option in a desirable way, because it can't rely on or ship new assets. This is why UI Extensions has placeholder text (requires new GMST) and new icons (requires new assets) while OpenMW's hands are tied to a single blank box.

so it would be kinda same on that take that mod will ship the assets. how would it be possible for openmw to use them. Which ones myGui will allow.

[psi29a]

I can see how that would be true for an OpenMW programmer. But most modders are not OpenMW programmers. For them, it may be far easier and less time consuming to create a simple pluggin than it would be to recompile the entire OpenMW project.

If the plugin is simple, then shouldn't it be easy to just implement it using OpenMW's Lua implementation?

In the case where a plugin is not simple and requires non-sandboxed environment to run, then isn't better to then implement the feature in OpenMW itself or ask for the API to be available in OpenMW's Lua implementation so that it could be a simple plugin?

[SeaFox]

In the case where a plugin is not simple and requires non-sandboxed environment to run, then isn't better to then implement the feature in OpenMW itself or ask for the API to be available in OpenMW's Lua implementation so that it could be a simple plugin?

Yes. Ideally OpenMW's Lua implementation should be improved to the point where MWSE plugins are not necessary. That should be the long-term goal. But until OpenMW's Lua implementation reaches such a state of perfection, the ability to make use of MWSE plugins for situations where the Lua implementation is not good enough would still be of great value.

[Chris]

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

Ideally, rather than single-handedly working on a fork, they'd work with OpenMW to get the feature in mainline. Then they don't have to maintain anything, and they get help developing the feature.

I can see how that would be true for an OpenMW programmer. But most modders are not OpenMW programmers. For them, it may be far easier and less time consuming to create a simple pluggin than it would be to recompile the entire OpenMW project.

"I want a hack done now" vs "I want a proper implementation done in a little bit". A typical developer conundrum. The latter is almost always the better option for anything that's to continue working into the future and potentially be expanded upon.

Yes. Ideally OpenMW's Lua implementation should be improved to the point where MWSE plugins are not necessary. That should be the long-term goal. But until OpenMW's Lua implementation reaches such a state of perfection, the ability to make use of MWSE plugins for situations where the Lua implementation is not good enough would still be of great value.

That's a bit self-defeating, though. If a modder wants feature X which they believe needs non-sandboxed code, and they go ahead and make a non-sandboxed mod while OpenMW works on an "official" sandboxed option, then the sandboxed option will go unused since the modder will have their non-sandboxed mod working already. Maybe if the modder rewrites their mod later to use the sandboxed option, but that's a big maybe (unless they perceive something to be a serious flaw, people don't have a habit of rewriting what works for them and most users). And in the mean time, there'll be a mod that a number of players can't use because it wasn't written to be compatible with their system.

[SeaFox]

"I want a hack done now" vs "I want a proper implementation done in a little bit". A typical developer conundrum. The latter is almost always the better option for anything that's to continue working into the future and potentially be expanded upon.

I agree. But that does not imply that quick hacks have no value and should never be used. On the contrary, Quick hacks using plugins can prove very valuable as a demonstration to prove the usefulness of some change in game-play. If many people like the change, then a more proper implementation with better long-term potential can be made later.

That's a bit self-defeating, though. If a modder wants feature X which they believe needs non-sandboxed code, and they go ahead and make a non-sandboxed mod while OpenMW works on an "official" sandboxed option, then the sandboxed option will go unused since the modder will have their non-sandboxed mod working already.

I disagree. As you have stated above, quick hacks do not have long-term viability. That is why they will eventually need to be re-implemented properly with long-term viability as a priority.

[Chris]

On the contrary, Quick hacks using plugins can prove very valuable as a demonstration to prove the usefulness of some change in game-play.

Quick hacks on the source would be more valuable, since it would also give an idea of what would need to be done, not just if it could be done. It would also help give an idea of whether specific features would be worth immediately exposing to scripts, or hardcoding initially and make more moddable over time.

I disagree. As you have stated above, quick hacks do not have long-term viability. That is why they will eventually need to be re-implemented properly with long-term viability as a priority.

Don't overestimate the amount of work people will be willing to put into something that already works for them. Unless something actually stops working, and the modder is still around and willing to fix it, I wouldn't rely on modders redoing work that's already been done and works for 90% of players.

As it is, OpenMW has already made improvements for the way mods can work (saner behavior for certain script functions, proper bump-mapping, etc), since the old ways were less than ideal. But old scripts work just fine with vanilla and old bump-maps work fine with MCP, which most people use, and few people want to fix it to be more correct. And when third parties do come in to fix or improve existing mods (for mods that allow other people to edit them), the fixes have trouble getting traction over the existing mods. So we still have people coming in with new releases of OpenMW saying that mod XYZ doesn't work right, when a fixed version of the mod has been available for some time.

[SeaFox]

Quick hacks on the source would be more valuable, since it would also give an idea of what would need to be done, not just if it could be done. It would also help give an idea of whether specific features would be worth immediately exposing to scripts, or hardcoding initially and make more moddable over time.

That may be true, but few people have the skill to do so. Making an MWSE plugin requires much less skill, and thus greatly increases the potential number of people who are able to contribute changes to the game.

Don't overestimate the amount of work people will be willing to put into something that already works for them. Unless something actually stops working, and the modder is still around and willing to fix it, I wouldn't rely on modders redoing work that's already been done and works for 90% of players.

That may be one reason why not everyone uses OpenMW instead of MWSE. But other factors include the fact that MWSE makes it easy for low skill mod creators to make changes. Changes that OpenMW programmers may or may not have time to make in the immediate future if ever.

As it is, OpenMW has already made improvements for the way mods can work (saner behavior for certain script functions, proper bump-mapping, etc), since the old ways were less than ideal. But old scripts work just fine with vanilla and old bump-maps work fine with MCP, which most people use, and few people want to fix it to be more correct. And when third parties do come in to fix or improve existing mods (for mods that allow other people to edit them), the fixes have trouble getting traction over the existing mods. So we still have people coming in with new releases of OpenMW saying that mod XYZ doesn't work right, when a fixed version of the mod has been available for some time.

But old mods often don't work well with newer mods, or with the improved systems of OpenMW. Therefore, people who wish to use newer mods will eventually be forced to give up the older mods for the improved versions.