Thatās pretty much an impasse, Iām not interested in dda as an engine per se. Iām happy to add data-driven behavior, but only to the extent that it improves dda-the-game.
Thatās probably weeks to months of work you just outlined. The basic data bindings arenāt that bad, but all the querying and injection of callbacks and overrides is, and as you say, this is just a start.
Iām not following you, what I mean is every change needs to be scrutinized for āis this going to change how any of the LUA interfaces work?ā. This means that someone intimately familiar with the bindings has to review every code change. Alternately, we donāt do that, and the LUA bindings break constantly.
That doesnāt meaningfully change anything, someone still has to manually update those text entries every time a bound method is changed. Someone still has to be watching for those changes in the stream of PRs. Someone still has to write helper methods any time an API canāt be exposed as-is.
I donāt have numbers, but itās enough to be problematic. Also remember that the benefit to the project is roughly 0, so Iām not willing to tolerate much.
Youāre arguing for exposing an absolutely massive amount of game state via scripting bindings, thatās somehow totally fine despite a total lack of feedback about what parts are being used, but exposing actual data-driven bindings is somehow too much? The coordination and synchronization problems are present either way, the problem size is similar, the main difference is one you can implement blindly and the other requires design.
The difference is that data-driven design has been working and supplying benefits to the project incrementally. If anything, the existence of LUA bindings has been interfering with it by applying shortcuts.