Re: The new MWSE-Lua interface
Posted: 09 Oct 2018, 03:52
All the more reason to ensure mods are given an engine where they can remain stable and compatible long after work on them stops.
All the more reason to ensure mods are given an engine where they can remain stable and compatible long after work on them stops.
That's not how I mean it at all. They are simply both very good examples of each end of the spectrum. I'm sure that NullCascade plans many of his features extensively, but his driving principle is to get modders tools now rather than later. Reverse engineering the preexisting engine and hacking into it has proven a successful strategy for a great number of features, which the current modding community has benefited from. But there will come a time when OpenMW finally exceeds MWSE's functionality, it just takes a lot longer because we have to build the whole engine from scratch.
I think this may be the source of our disconnect. First, forking a project is not as horrible as it sounds and we have all been using it in different contexts. Apologies if you know all this already, but hopefully this will clear some stuff up. In Git, it just means you've copied the project to your own directory so you can work on it without screwing with the master branch. It's literally required for any contributor to fork the project, it's just that the devs fork with the intention of working on features that will immediately be integrated back into the master branch upon completion. This is where the rapid prototyping happens! (We are 100% in agreement on this being a beneficial development strategy)SeaFox wrote: ↑08 Oct 2018, 23:03 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.
I think we all understand the distinction you're trying to make. And I think we all believe in options as much as possible! I even saw a post from Zini elsewhere saying more options are generally better! It's just that the option of sandboxing is tacitly the same as having no sandboxing at all. Some people have argued that "just because some stupid people will screw things up doesn't mean we should block other people from using it". But this is not precisely what we're trying to do. We have plenty of settings people can change that will fuck up their setup, and they do! We (generally) try to help as best we can, but explaining for the 10th time that trying to load every object in a 20 cell radius will lower your FPS gets tedious, so sorry if we come off a little short sometimes
Just because we understand the need to take things slow to keep things organized doesn't mean we have to be happy about it!
Do you (or others) mind explaining a little bit more what exactly you mean by a native code plugin? Can you also say what precisely sandboxing will block or rather, what unsandboxing will allow over a sandboxed option. I think I understand for the most part but want to make sure I understand when I'm explaining elsewhere. Does sandboxing keep you from accessing just system files? Third party programs? Both? The discussion on this thread has been somewhat... disjointed in it's explanations.