The new MWSE-Lua interface

Everything about development and the OpenMW source code.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: The new MWSE-Lua interface

Post by AnyOldName3 »

I think there's a pretty good chance that we'll have a system for attaching physics objects to character meshes eventually - if we don't all die of old age by the time we add Fallout 4 support, we have to do it in order to support the hair physics, and then non-hair body parts can just use that system. I think you've accidentally picked an example where the potential fan backlash and technical justification both mandate that the feature happens eventually.

There's a good chance people will want systems in place to mod things which are unfeasible to maintain, but in reality, they're likely to be pretty few and far between - bear in mind that after Morrowind's done and things have been de-hardcoded, we're hoping that all subsequent Bethesda Gamebryo/Creation Engine games can eventually be supported, ideally with all differences between their engines managed by scripts. That's almost certainly going to force us to open the engine up to modification in ways which surpass almost anything any modder could need.
User avatar
Ravenwing
Posts: 335
Joined: 02 Jan 2016, 02:51

Re: The new MWSE-Lua interface

Post by Ravenwing »

Petethegoat wrote: 08 Oct 2018, 01:00 But there's this assumption that anything a modder wants to use that isn't supported or exposed in the engine, will and should be integrated into the core engine.

It seems really obvious to me that this won't be what happens in practice, as some desirable features for modders are just too specialized and specific to be integrated while keeping the engine maintainable. While jiggling titty physics might be more generally useful for procedurally animating cloth or making wobbling netch jelly, it's not obvious to me that it'd be merged into the main branch just because a curvy body mod wants it.
That's a reasonable concern to have and I can see how some of our arguments have sounded that way. I won't say there is absolutely no possibility of this ever happening, however, I think even most niche/specialized needs are actually things that require a much more generalized solution. Your example of the jiggling titties is the niche need, with (apparently) physics objects to meshes being the general solution. I'm sure the vast majority of seemingly niche needs can actually be solved with generalized solutions. As I say here:
Ravenwing wrote: 08 Oct 2018, 00:07 Either the feature is implemented universally in the engine, allowing other modders to benefit from the framework as well, or the modder has to cobble together something for their mod only.
So the best approach is for someone, either the mod author or the devs, to submit a pull request implementing physics objects attached to meshes. Now any modder can use the supported framework to make jiggling titties, jangling wangs, long flowing hair, or just cool fabric banners, whatever floats their boat. There has been some discussion that modders shouldn't be expected to know how to modify the code base for a pull request. The thing is, if they were going to go with the unsandboxed route, they'd already have to have the level of knowledge required to implement their own separate feature. If they don't, they were already at the mercy of someone else doing it for them, so it's really a moot point.

Now for the cases where the devs don't really feel something can be reasonably maintained.

First, it's the modder's responsibility to be at least somewhat convincing in asking for a new feature if they can't make it themselves.
If Mr. Jiggling Titties just goes on the forum and shouts, "I WANT JIGGLING TITTIES!" And the devs say, "lol y tho." And Mr. JT says, "BECAUSE I WANT THEM! ALSO ZINI IS AN EVIL DICTATOR AND YOU GUYS ARE ALWAYS MEAN" I think the devs have every right to say, "nah, you're an idiot."
If instead he says "Yo, I think jiggling titties would be cool, plus we could make all kinds of jiggly other things" the devs are much more likely to realize there's a nifty general solution and help the guy out.

Second, if, even after a thorough and convincing argument about how great a feature would be, the devs still say they won't merge something, forking isn't the most horrible other thing to happen. Look at TES3MP, it's a fork of OpenMW. Multiplayer is a specifically post-1.0 thing that Zini would never allow to merge as it stands. But davidcernat gets along well with the core project and keeps his branch updated with each version of OpenMW proper. Now it's influencing the main project (a large reason we decided on Lua) and has even become our goal to merge for version 2.0 (I believe). This is perhaps not the best example because multiplayer is obviously a seriously cool, highly desired feature. It is also not ideal to have people making forks left and right just to allow their pet mods, because ain't nobody got time for that. However, this is a great way to show rather than tell the devs, hey look, I've got a cool thing going, maybe this should be merged into the master. Even if the mod authors don't want to support the mod themselves, the mod author who forked it can do the maintenance they'd have to do anyway for a binary solution and just keep the two projects synced.

Once we actually get to the point where people want to be merging things that would best be left out of the core project, it's entirely possible that Zini will want a more generalized plugin system that makes everyone happy. If he doesn't he probably has a damn good reason for why and it would be a much more productive discussion at that time.
User avatar
Jemolk
Posts: 237
Joined: 20 Mar 2017, 02:12
Location: Sadrith Mora

Re: The new MWSE-Lua interface

Post by Jemolk »

Thanks for the calm reasoning, guys. I don't know about any of the others who ended up contributing to this becoming a firestorm, but I really appreciate it. And taking a step or two back, I can see why I felt that way, and also why it's not exactly useful or even reasonable. I'm really stressed right now, and due in no small part to that, it feels like things are taking an absolute eternity to me. But I can see the merit in what you all are saying. I just wish this eternity would hurry up and pass already. Part of it also is that I just don't have the skill to help, despite really, really wanting to, and with my current classes, I don't feel like I have enough free time to learn. :(
User avatar
psi29a
Posts: 5355
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: The new MWSE-Lua interface

Post by psi29a »

Jemolk wrote: 08 Oct 2018, 07:42I'm really stressed right now, and due in no small part to that, it feels like things are taking an absolute eternity to me. But I can see the merit in what you all are saying. I just wish this eternity would hurry up and pass already. Part of it also is that I just don't have the skill to help, despite really, really wanting to, and with my current classes, I don't feel like I have enough free time to learn. :(
Many people feel this way. Some of us dealing with classes, work, family, kids, commitments and more which limit people in contributing more time to whatever project they want to work on. So having these kinds of discussions, while important in trying to address the issues, can sometime draw away from everyone's time which would have been better spend actually working on the project.

The good news is, we'll be releasing a statement and updating the FAQ accordingly to help users, modders and developers with where OpenMW is going, how they can help and how we can help them.

That way, when future discussions happen, no one has to repeat themselves and we can jump right into the technical issues and how best to deal with them. Players, modders, game makers and content creators are 1st class citizens, they are the people we want to help create great things. :)

As cliche as that sounds, help us help you. We have a commitment to ourselves to try to help, where we can, be kind and patient. We ask that also in return. If we feel that that is being abused, then we'll stop providing help. This is our hobby too. We'd hope that this would go without saying, but sometimes it needs to be reiterated.
User avatar
silentthief
Posts: 456
Joined: 18 Apr 2013, 01:20
Location: Currently traversing the Ascadian Isles

Re: The new MWSE-Lua interface

Post by silentthief »

psi29a wrote: 08 Oct 2018, 08:46 As cliche as that sounds, help us help you. We have a commitment to ourselves to try to help, where we can, be kind and patient. We ask that also in return. If we feel that that is being abused, then we'll stop providing help. This is our hobby too. We'd hope that this would go without saying, but sometimes it needs to be reiterated.
Best advice right there. I have as much passion and excitement over this project as any - even though I lurk and don't get too much into the debates. I have seen more than one project get halted due to developers deciding that (due to arguments and/or unsatisfied users asking for more features) it simply was more trouble than its worth.

I saw the progress from where this was barely above an ESM world viewer where the character model was a ball that flew around showing the features of Vivec, and none of the NPCs could be interacted with. This was prior to the rewrite from D to C. There have been trolls (and no - under no circumstances should the arguments for or against sandboxing be considered a troll. Passions fly for a game we all love - but we all share the same ultimate goal). There has been people who came and then said after a few weeks "This project is dead". And still - the devs have continued to deliver even when real life is a pita. TY to you devs for continuing with this

ST - the MW fan, the MSWE fan and the openMW fan
User avatar
Jemolk
Posts: 237
Joined: 20 Mar 2017, 02:12
Location: Sadrith Mora

Re: The new MWSE-Lua interface

Post by Jemolk »

psi29a wrote: 08 Oct 2018, 08:46As cliche as that sounds, help us help you. We have a commitment to ourselves to try to help, where we can, be kind and patient. We ask that also in return. If we feel that that is being abused, then we'll stop providing help. This is our hobby too. We'd hope that this would go without saying, but sometimes it needs to be reiterated.
Of course! I meant my post by way of explanation rather than excuse. And it's great to hear the reassurances. Thanks. And sorry for adding fuel to that rather...explosive fire. You guys all do great work, and I do appreciate it. Stress just can bring out the worst in me, as there. I do try to do better, but, well.... Obviously it doesn't always work as well as I'd like. Mea culpa.
User avatar
SeaFox
Posts: 34
Joined: 29 Feb 2016, 17:30

Re: The new MWSE-Lua interface

Post by SeaFox »

Ravenwing wrote: 08 Oct 2018, 00:07 The strife between NullCascade and Zini boils down to a fundamental difference of design philosophy: get modders as many tools as possible, as soon as possible using any means necessary VS spend a little more time and energy planning a more rigorous and sustainable piece of software.
That seems like an example of a false dichotomy. The end goal of a software project should, as you say, be a rigorously planned and sustainable piece of software. But the process of reaching that goal can, and should, include the use of software prototypes, such as the binary plugins within mods. The use of such sofware prototypes is part of the process of Rapid-application development (RAD). Once the prototype has served it's purpose by acting as a proof of concept, a more rigorous and sustainable piece of software can then be constructed to replace it.
Ravenwing wrote: 08 Oct 2018, 00:07 I'm confused by your response that none of these are enough to persuade you that optional sandboxing is an unacceptable solution. These are all very real and significant issues from a user and modder standpoint.
I support OPTIONAL sandboxing. I don't support MANDATORY sandboxiing.
Ravenwing wrote: 08 Oct 2018, 05:32 It is also not ideal to have people making forks left and right just to allow their pet mods, because ain't nobody got time for that. However, this is a great way to show rather than tell the devs, hey look, I've got a cool thing going, maybe this should be merged into the master. Even if the mod authors don't want to support the mod themselves, the mod author who forked it can do the maintenance they'd have to do anyway for a binary solution and just keep the two projects synced.
You seem to be suggesting that creators of mods should fork the entire OpenMW project whenever they wish to create a software prototype of some new feature which is not possible with the current code base. Binary plugins would be a far superior way of creatiing such prototypes.
Chris
Posts: 1625
Joined: 04 Sep 2011, 08:33

Re: The new MWSE-Lua interface

Post by Chris »

SeaFox wrote: 08 Oct 2018, 23:03 That seems like an example of a false dichotomy. The end goal of a software project should, as you say, be a rigorously planned and sustainable piece of software. But the process of reaching that goal can, and should, include the use of software prototypes, such as the binary plugins within mods.
But mods aren't prototypes. A mod can be prototyped, but also has official releases, just like an engine. How would you ensure official releases of mods, which are expected to work for a wide audience well into the future, aren't using native code plugins?
User avatar
SeaFox
Posts: 34
Joined: 29 Feb 2016, 17:30

Re: The new MWSE-Lua interface

Post by SeaFox »

Chris wrote: 09 Oct 2018, 01:55
SeaFox wrote: 08 Oct 2018, 23:03 That seems like an example of a false dichotomy. The end goal of a software project should, as you say, be a rigorously planned and sustainable piece of software. But the process of reaching that goal can, and should, include the use of software prototypes, such as the binary plugins within mods.
But mods aren't prototypes. A mod can be prototyped, but also has official releases, just like an engine. How would you ensure official releases of mods, which are expected to work for a wide audience well into the future, aren't using native code plugins?
Mods are generally the work of individuals who love the game and have ideas about how to improve it. They express those ideas by creating mods. They share those mods with the community as an expression of love for the game and the community that surrounds it. While these mods are not necessarily intended to be prototypes for future improvements to the OpenMW code base, they can serve that function. Mod creators obviously cannot spend their entire life maintaining that mod and providing support for it. Eventually the mod must be abandoned, and newer, better, mods will take it's place, and possibly an OpenMW developer will use the mod as a prototype for improving OpenMW.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: The new MWSE-Lua interface

Post by AnyOldName3 »

If it's something which can be done through a mod, it's probably something which should be done through a mod. This idea goes both ways, meaning we shouldn't be implementing things into the engine which work fine as a mod, and we shouldn't provide tools to let mods do things which are going to break literally everything else if they aren't handled by the engine.

A native code plugin is always going to be more work to create and maintain than a single-feature fork created with the intention of it (or a derivative of it) being merged back into master. If you want to prototype a feature, whether or not we offer unsandboxed mod support, forking is going to be easiest. The only benefit is if you want to do something which you know there's absolutely no chance you'll ever get merged, and even then, a fork might still be easier to maintain.
Post Reply