So in future openmw.cfg can contain:
Code: Select all
# Defines morrowind-style mechanics, distributed with OpenMW (as well as skyrim-shim.omwgame and others). content=morrowind-shim.omwgame # Original Morrowind content, obviously not distributed with OpenMW, user should buy it. content=morrowind.esm ...
We have completely different views on how OpenMW Lua should look like. I don't agree that my approach is less safe or less compatible. We can spent a lot of time arguing on what is better, but there is an important technical detail that makes such discussion almost useless:Chris wrote: That's basically what I'm aiming for. The issues I responded to in this post, I'd have thought, are reasonable steps to ensure compatibility (i.e. not moving everything to be "built-in Lua mods" that mods can replace willy-nilly, and not allowing modded scripts to do everything a built-in script could), and pointing out that some of the ideas presented are a bit too general (making a plan to dehardcode any given function, when the way to dehardcode something will very much depend on the behavior being dehardcoded).
Essentially, I'm saying dehardcoding doesn't have to come in the form of "turn C++ functions into Lua functions/scripts that mods can replace", or that "in the end there will be no internal API at all and built-in scripts will not have any "special powers" comparing to normal mods". I don't think it's an unreasonable effort to temper that expectation. There will always be internal APIs that built-in scripts can use and mods can't (unless we want to limit what scripts can do, so that built-in scripts can only do the things modded scripts can, which I doubt was the intent), and that modded functionality won't always (if not will rarely) come in the form of replacing built-in scripts, compared to utilizing hooks provided by built-in scripts and various engine components.
I started designing OpenMW Lua almost a year ago and the whole design is based on my view. It seems to you that your ideas are easier in implementation, but in fact they are not compatible with what is already done. I respect your opinion, but implementing your ideas would mean throwing away most of my work, so it is not an option for me. Even if you convince others that your approach is better, you would need to find someone to redesign the whole scripting system from scratch.
Now I will try to explain why in the current concept first steps of dehardcoding are so essential and has high priority. Actually it is exactly to ensure compatibility:
- C++ and Lua are completely different languages and interaction between C++ part and Lua part can not be as flexible as interaction between Lua scripts.
- Since modders should be able to change game mechanics in any way they want, these mechanics should be implemented in Lua. It means dehardcoding, at least in future.
- Interactions Lua <-> C++ and interactions between Lua scripts are implemented in different ways:
- C++ -> Lua: Engine handlers. Lua scripts can subscribe to events that come from C++. C++ can not call Lua functions directly.
- Lua -> C++: API packages. Lua calls C++ functions.
- Lua -> Lua: Extensible script interfaces and event system.
- If we expose something via API packages, then later dehardcoding will break mods that depend on it.
- So in order to ensure compatibility we need to think about dehardcoding first and provide most of functionality via wrappers in built-in scripts (i.e. using Lua-to-Lua interaction). Then the API can be stable from the beginning and we will not need to change it during dehardcoding.