Remove LUA infrastructure.

[kevingranade]

This will require just a few pieces, though the line count will be rather large.
Step one is rewrite StatsThroughSkills, FasterZombies, or any other LUA mods to be defined in json.
Step two is to remove LUA from the build, process, and dismantle any lua infrastructure in the code.
To avoid potential disruption to the upcoming release, this should be put off until after 0.D is released.

Fixes #26964
Fixes #26745

[PlasticPhoenix]

Interesting development. I tend to use the LUA interface alot myself, though I know most folks don't. Will json-based mods be able to do some kind of logic then? I use LUA to create and track custom variables, items & armor that have an active effect over-time when put on/taken off, etc. I am curious to the full capability of the json mods. It would be great to get everything on one format and not have to do my little song and dance for my current item effects. Is the LUA code just becoming too old and stale to be maintainable? Or is it a decision to simplify things and remove something clunky that really isn't used much?

[jzambo]

Please don't. I grew to appreciate LUA for writing custom logic. My reason is mainly for iteration speed during development. Unless I'm missing some existing code-swapping capabilities, touching .h files or game.cpp is too slow.

With LUA, I can update and reload code every turn, I also use a "scratch.lua" file for ad-hoc debugging or fix-ups that would not be possible with debug menu.

Also, provided stable API, I have less merge conflicts and it will allow me to publish customizations that do not fit the vanilla game. Actually, for any non-trivial customizations, I'm considering dispatching to a new LUA handler in order to override existing logic and stop recompiling.

[Maddremor]

While I have no meaningful attachment to Lua, it is still worth considering the role it fills. Is there a way to have some kind of framework that, while still more easier maintained than Lua, allows modders and mod users to create/install things beyond the scope of existing JSON without recompiling the entire game? Said mod could still be compiled individually, but should in that case retain their "drop in mods folder" nature for casual users (in my opinion).

[jzambo]

One of reasons LUA is not used is because it's immature. You simply can't do much as an end-user.
Regarding requestes for examples, here's list of extensions (in C++) I made for my own modding needs:

• ability to iterate over active NPCs (otherwise you can't call methods on them, duh)
• ability to load LUA from LUA itself (hot-reloading game logic during play)
• on_hurt hook for custom effects (e.g. hit to the head can make you, or NPC unconscious)
• angering NPCs from player actions coded in LUA (menu is still in C++, but I plan to move it)
• morale and effect handlers (grappling, robbing, infection form bleeding wound)
• logging from LUA (to file)

[kevingranade]

@jzambo sorry, but your argument is not compelling. I can't afford to keep investing in LUA support on the basis of modders that don't contribute their changes back to the project. From the project point of view, "I need this for a private mod" is indistinguishable from, "I theoretically might need this, but I'm going to say I'm actually using it to make my argument stronger". If you need LUA support for a private fork of the game, it's on you to maintain it.

Unless I'm missing some existing code-swapping capabilities, touching .h files or game.cpp is too slow.

That's a matter of refactoring the c++ modules. There's no technical reason that incremental compilation has to take more than a handful of seconds.

Also, provided stable API, I have less merge conflicts and it will allow me to publish customizations that do not fit the vanilla game.

Your changes should be factored out into their own modules in c++, in which case the rate of merge conflicts should be very low, we don't generally have a lot of churn in class interfaces, and when we do it bubbles down into LUA anyway. (and no, maintaining a stable LUA interface in the face of c++ interface changes is simply not an option.)

One of reasons LUA is not used is because it's immature.

This is typical of requests for keeping LUA, it's not just a matter of maintaining the current functionality, it's a request to speculatively invest still more in LUA integration because at some undefined point in the future, after a lot more integration work, there will start to be benefits of that work. At no point has there been a credible argument along the lines of, "If you support a, b and c, you will gain benefits x, y and z, just repetition that "more" work will lead to "improvements".

it is still worth considering the role it fills.
create/install things beyond the scope of existing JSON without recompiling the entire game?

No, LUA is literally the lowest-overhead option for doing this, it's what it's designed to do. It's the integration of LUA into the game that's the problem, not LUA itself.

This issue isn't the place to discuss whether this should happen or not, that is http://smf.cataclysmdda.com/index.php?topic=14231.0If you have further concerns, post them there.