The new MWSE-Lua interface

[NullCascade]

Giving people more slack to do anything they want sounds all fine and dandy, until they get enough slack that they end up hanging themselves.

You're probably right. I went and exposed the Morrowind scene graph to people, and they went and did the worst shit, like releasing weapon sheathing and state-based models for meshes that change depending on time of day. All this capability to innovate will be the death of modding. Think of what people could truly accomplish if they had a well-regulated interface, or had to fork the entire engine instead.

[psi29a]

I went and exposed the Morrowind scene graph to people, and they went and did the worst shit, like releasing weapon sheathing and state-based models for meshes that change depending on time of day. All this capability to innovate will be the death of modding. Think of what people could truly accomplish if they had a well-regulated interface, or had to fork the entire engine instead.

If Morrowind had a well-regulated, open and evolving interface, then MWSE wouldn't need to exist to create great mods.

That is what OpenMW is supposed to provide.

That being said... while you're off doing awesome things with MWSE, OpenMW is still busy adding features and squashing bugs to reach 1.0

I can only assume that you'll just keep adding features, which is cool. Don't let us stop you.

[akortunov]

You're probably right. I went and exposed the Morrowind scene graph to people, and they went and did the worst shit, like releasing weapon sheathing and state-based models for meshes that change depending on time of day. All this capability to innovate will be the death of modding. Think of what people could truly accomplish if they had a well-regulated interface, or had to fork the entire engine instead.

There were not complaints about GUI and scene graph, there was only one complaint about loading custom libraries and executables (because such approach is a hell to maintain in a cross-platform opensource project and because of security issues) and unlimited access to filesystem.

You can just implement OpenMW-Lua without this feature first and then return to sandboxing question. More likely native code execution will not be needed at all for most of mods (or for all mods). IIRC, even mentioned mods use only Lua, right?

[Cammera]

...Seriously? You guys actually saying it's easier to learn C code, then OpenMW's code internals, then edit the code and reocmpile it hoping the edits don't break the everything? Modding is a much better alternative to forking for mods. I can run multiple mods at once. I can't run multiple forks at once, not without posibly editing C, which I shouldn't need to say is terribly unfriendly to the end user.
At this point, honestly, this argument sounds more like a mentality were OpenMW is your sekrit klubhouse only kool kids can enter.

These days, Doomsday is rarely used. ZDoom* is what many modders target, because it offers a wealth of modding extensions and continues gaining new features that modders want. It developed compatibility with certain features of other source ports where it could (Doomsday's hi-res texture pack and model support, Doom Legacy's custom FraggleScript, etc). The engine is very stable, the vast majority of mods made for it continue working, new features are still being added, and it all works for everybody regardless of their preferred system. The engine's even been used in some recent commercial games.

It's more of "Graff is a massive autist and thus the only one still maintaining a stable doom sourceport, especially one as incredibly messy as gzdoom". That doesn't speak at all about the quality of Doomsday VS G/Zdoom, just of the persistence of their developers, nor does it about their approaches, and I am saying this as a linux user that's happy I don't need crusty dlls compiled in 2002 to play old doom mods.
And I could argue GZDoom's quality (The guy has so many autistic fits his title in doomworld is Saltyman, and needed opengl 3.0 to implement features prboom had implemented a decade earlier in software mode) but that's completely besides the point.

[akortunov]

...Seriously? You guys actually saying it's easier to learn C code, then OpenMW's code internals, then edit the code and reocmpile it hoping the edits don't break the everything? Modding is a much better alternative to forking for mods. I can run multiple mods at once. I can't run multiple forks at once, not without posibly editing C, which I shouldn't need to say is terribly unfriendly to the end user.
At this point, honestly, this argument sounds more like a mentality were OpenMW is your sekrit klubhouse only kool kids can enter.

If you read this thread carefully, you can notice that it is actually what NullCascade wants - modders should learn C\C++ to create and maintain custom executables or libraries, which OpenMW should load by his design. He even suppose that it is a killer-feature.
We try to convince him that better leave Lua for modders, and leave C\C++ code for MWSE\OpenMW developers. In this case if MWSE\OpenMW does not support feature which modder wants, he should create a feature request and allow coders to implement it.

[Cammera]

If you read this thread carefully, you can notice that it is actually what NullCascade wants - modders should learn C\C++ to create and maintain custom executables or libraries, which OpenMW should load by his design. He even suppose that it is a killer-feature.

Nnnnnot really. He wants to let them, which isn't a requisite.
You guys are the ones saying fork or perish.

[akortunov]

Nnnnnot really. He wants to let them, which isn't a requisite.
You guys are the ones saying fork or perish.

Nope, we say "send a pull request or create a feature request, if you can not implement this feature yourself".
He says that there is no point to implement Lua scripting at all without ability to load custom binaries.

[TheGrimblade]

Outdated, but a good starting resource. Pretty easy to follow and understand. For your edification:
http://lua-users.org/wiki/SandBoxes
It seems to me that the best way to move forward is to have the following design ethos in regard to scripting for OpenMW:
1. Continue support of oldscript - whatever happens shouldn't break vanilla behaviors.
2. Develop LUA post 1.0. Work can begin now, but it should not be implemented before 1.0.
3. It would be ideal to sandbox LUA -> start by developing an API centered around a sandboxed implementation.
4. Use cases that would not work through sandboxed LUA scripting, and would thus require more advanced knowledge or branching should be considered as exceptions to the design philosophy.
4a. If someone has the capability, it would be most desirable to simply branch off and modify the code, adding in the necessary features and improving the feature base for the whole engine, not for just the one mod's use case.
4b. Alternatively, an open LUA script could be developed by whoever was willing to do so, though this would likely have to be a separate project from OpenMW.
5. Finally, if and only if, some vital feature is not achievable with a sandboxed implementation, and there is widespread demand, after 1.0, and likely 1.1 after that, official support for a non sandboxed implementation as part of the core project makes sense.

As I see it, Morrowind is a 15 (or so) year old game. People are playing the game now more than they have in years, largely due to landmass mods finally reaching major milestones. I believe that people will continue to play Morrowind for a great number more years, and while it would be nice to have cool new features now, it won't hurt to wait a few more for a proper implementation. Besides, OpenMW is not intended to *just* play Morrowind. It is supposed to be an open source engine that could be used to develop completely new games, and it could feasibly be advanced to run other BGS titles in a few years.

But that is just my take. I am not a contributor to the project, but I have a decent understanding of software development. So take this with a grain of salt.

Also, great work guys. You do a fantastic job with this project. And I would say the same of NullCascade and his work with MWSE. Nobody is making you do this work, and I don't think any of you would be discussing this if you didn't care. It's unfortunately a pretty thankless job, so from me to you: thank you.

[psi29a]

...Seriously? You guys actually saying it's easier to learn C code, then OpenMW's code internals, then edit the code and reocmpile it hoping the edits don't break the everything? Modding is a much better alternative to forking for mods. I can run multiple mods at once. I can't run multiple forks at once, not without posibly editing C, which I shouldn't need to say is terribly unfriendly to the end user.
At this point, honestly, this argument sounds more like a mentality were OpenMW is your sekrit klubhouse only kool kids can enter.

Nothing sekrit about OpenMW, it's not developed in a vacuum. I believe there are many knee-jerk reactions here _or_ that reading comprehension skills need sharpening.

NullCascade wants you to learn C or whatever so that you can create mods that by-pass the sandbox Lua scripting language in OpenMW, that you can.

OpenMW takes the approach that mods should keep to the sandboxed Lua scripting language that can and will evolve over time to expose more features as modders and developers need them.

Is there something wrong with this approach above? Isn't that easier than learning C and C++?

The 'evolve over time' is important here because this is where people are getting confused again:

You guys are the ones saying fork or perish.

Anyone that wants to extend the functionality that OpenMW offers is free to either:
1) Create a feature-request ticket and discuss it in the forum so that developers can work on it.
2) Create a PR/MR (aka fork) where you created it yourself if you are capable of doing so.

The point is, modders shouldn't need to learn C or C++ in order to create mods for OpenMW. Anyone telling you differently is trying to sell you something. If modders want to get their hands dirty and help develop OpenMW, great! It isn't a requirement but everyone will be appreciative and supportive. At that point, they are not really modders but developers.

[NullCascade]

If you read this thread carefully, you can notice that it is actually what NullCascade wants - modders should learn C\C++ to create and maintain custom executables or libraries, which OpenMW should load by his design. He even suppose that it is a killer-feature.

This is false.

He says that there is no point to implement Lua scripting at all without ability to load custom binaries.

This is also false.

Cammera has my views right so far.

Modders don't have time to learn C, learn OpenMW's internals, deal with draconian Linux-hyperfocused practices, or be professional developers in their spare time. They want to connect some APIs to cobble together their mod, pull in any libraries to do what OpenMW doesn't do out of the box, and ship their mod in a reasonable time frame. Forks and pull requests are not the way to create mods, and OpenMW's design decisions continue to be utterly baffling. It's literally a meme at this point, software that gets made fun of in chat rooms, instead of the golden bastion of modding that it could be if it stopped shooting itself in the foot. You guys have way more potential with this project than I'll ever have with MWSE. Stop making us facepalm.