Interesting read.
I think what goes hand in hand with the scripting decision is the modularity.
Of course not of the engine code. Rather of the content.
Multiple data folders are already one of my favorite changes compared to vanilla MW engine.
No matter which scripting language, and of course limiting OS,filesystem libs makes sense for security reasons, yet it should have read only access to files.
Are JSON or XML files or file references considered?
Currently content looks bundled in ESM|omwgame, ESP|omwaddon files. Scripts can be embedded but need not necessarily, at least I remember references to external script files on the wiki somewhere. But content like which model uses which texture and which variation is not mapped. As are base skills and different predefined characters or am I wrong?
Defining content separately (in XML, JSON) sounds a bit more friendly to me for the following reasons:
- readability
- re-usability and
- version control
While we at solution C and a translator anyway, could we not generate the omw{game,addon} files via a "combinator" like tool instead of hard-coding it in a binary format. Okay, I know blender also uses binary and it has advantages but for game source files I feel like a more modular approach is more desirable.
Is there any chance on a 1vs.1 comparison that makes it easier to carve in stone that Lua is really more desirable than oldscript+? When people talk about Lua then LuaJIT for sure as without just in time compiling Lua generally falls behind highly optimized scripting languages like v8.JavaScript (due to google) or SpiderMonkey.JavaScript (due to mozilla) or PyPy.
Apart from 0 vs 1 based arrays what I like about JavaScript is
* Both the V8 and SpiderMonkey implementation are free and highly maintained.
* Javascript is everywhere there is a browser. People could test and debug their mod's logic in the browser.
* source files may be smaller in size due to {} vs begin/end
Generally I try to be neutral to Java and not join the hatred to it. I heard something good about Clojure and especially Go, but of course these are full blown languages.
Python, especially PyPy, also looks very nice and is very short syntax and well established numeric libraries numpy, grumpy, ..., but if it can not be sandboxed and this is important to OpenMW then it will - as so often and even more since Py2 and 3 mess - have less chance to be adapted than AngelScript or maybe even BASIC or hey GUI enthusiasts out there, what about Lava
.
I like Ada as much as C and Go, Python and JavaScript (yes even if object orientation is strange and debugging asynchronous code is not easy but still it gets useful tasks done, consider browser addons).
My preferred route to create using OpenMW is to code C++. I plan on content mods only and provide functionality only once the scripting side and planned API is really stable which I'm not sure when to expect, maybe post 2.0, i.e. 2.1?
Btw. anyone can explain why wrapper code and an API is strictly necessary considering that LuaJIT can hook directly into function calls if the binary is compiled as a shared library. I guess it is safety, but still, someone could provide a mod with LuaJIT calling any C++ functions of libs instead of only those in the (potentially superfluous?) wrapper code anyway (have a look at ffi).
Isn't the C++ code to be kept safe anyway? This then meant we could save developer time. No wrappers to maintain. Full freedom for modders. Or is this overly idealistic?