Lua may be getting axed, how many people care?

[kevin.granade]

Well reasoned argument, but it’s simply not compelling.
I have personally spent dozens to hundreds of hours on LUA support, a number of other very productive developers have spent far more time than me. In addition, LUA support makes builds harder for everyone, representing a drag on the entire project’s productivity. The sum easily represents over a thousand dev-hours of time spent on this feature. The lua bindings themselves are 24,000 lines of C++.
On the other hand, we have what you see listed in this thread, an extremely meagre list of features, that in most cases would have been quicker to develop in C++, totaling something like a few dozen hours worth of development. There’s something like 2,000 lines of LUA that have been written for this project.

This ratio just. does. not. make. sense.

@JT

the problem is that everyone’s doing stuff in the native code when they shouldn’t.

That’s a really hard sell in a project like this, I’m not about to tell people that they MUST code certain things in LUA, regardless of whether they know the language or not. That literally means refusing contributions in some cases.

@JT

Things like door pulleys, etc. should be externalised as a matter of best practice.

If we’re talking converting existing functionality to LUA, I’m sure as hell not going to shoulder the overhead of rewriting tens of thousands of lines of code* in a scripting language purely in the name of “correctness”. For that matter, I don’t want to review tens of thousands of lines of LUA code that don’t add functionality to the game, but instead just move it elsewhere.

[quote=“JT, post:37, topic:13488”]Lua would also be pretty much essential for NPC behaviour and dialogue,
…
Lua is the glue that affixes the game to the sandbox.
…
the only meaningful way of introducing dungeons, conversations, quests, and unique artifacts will be with a script engine.[/quote]
This assertion doesn’t follow, you can obviously do anything in C++ that you can do in LUA. There is some kind of dynamic in games development where LUA or other scripting languages are preferred over coding things directly in C++, but it just hasn’t surfaced in this project. We seem to have very little LUA expertise, even though a number of people have stated it’s the "right thing to do.

@JT

Thus, my “time” argument is not based on “give it time”, but rather “wait for the time where it becomes relevant”. No one will use the Lua functionality right now because the game just isn’t far enough along for it to matter, but that’s no incentive to get rid of it… that’s incentive to keep it in now so it doesn’t become an absolute bitch to bring back in later.

I disagree, we ether have zero interest in writing meaningful features in LUA, or we have deeply disfunctional LUA integration, such that people interested in using it flee in terror immediately. In either case, the solution is to get rid of the disfunctional integration and then bring it back when it is needed AND someone (frankly, not me, I have no idea how that sort of integration should work) has a plan for supporting scripters other than “expose a bunch of internal game state to LUA”. Basic LUA integration is extremely simple (though it does add some complexity to the build process), so it’s fairly trivial to restore, it’s the infrastructure to expose engine internals to LUA that’s a PITA, and that’s what hasn’t proven successful.

*You might think I’m exaggerating, but check the main targets for this. iuse.cpp ~8,000 lines of code, mapgen.cpp ~10,000 lines of code, mapgen_functions.cpp ~5,000 lines of code, iexamine.cpp ~3,500 lines of code, monattack.cpp ~4,500 lines of code.