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.