DFHack and DF+Lua

[sgayda2]

Given the recent announcement about having native Lua support within DF I was wondering what that means for DFHack? Can it, would it, and should it, build on top of the native Lua interface exposed by DF. Presumably this would effectively remove many or all of the C++ memory hacking parts and instead become a collection of cool/useful/interesting mods?

[lethosor]

Nope. The Lua interface provided by DF is entirely separate in scope, and primarily for creating "content" mods, not behavioral mods. It's the same language, but not used for the same thing.

Also, at least at the moment, DFHack is using Lua 5.3 built as C++, and DF is (or will be) using Lua 5.4 built as C. So they would not be able to interoperate as it stands. This is why we renamed our Lua library to lua53 recently.

[sgayda2]

I see, do you see a future, where DF would expand their Lua interface to encompass more of the behavioral mod needs? Similarly what about being able to interoperate by having either DF or DFHack update to the same Lua version and language?

Does that even make sense? Could i write a single Lua script that talks to both DF and DFHack interfaces (if they were the same version)?

[lethosor]

Even if DFHack and DF used the same Lua version, the way they interface with DF is entirely different and not compatible (not only different names for some things in DF, but different ways of accessing those things. DF has access to the DF source code; DFHack largely does not.)

[ab9rf]

Given the recent announcement about having native Lua support within DF I was wondering what that means for DFHack? Can it, would it, and should it, build on top of the native Lua interface exposed by DF. Presumably this would effectively remove many or all of the C++ memory hacking parts and instead become a collection of cool/useful/interesting mods?

No, not at all. DF is going to be using Lua as an alternative to static "raws" to describe content in the game. We use Lua for entirely different purposes. DF's Lua environment will not (at least as is being explained by Putnam at this time) offer any ability to alter the behavior of objects (once instantiated) during play, nor to alter the user interface in any way. It is, at least initially, going to be limited to inspecting a relatively small slice of game data (a far more narrow access to game data than what we make available to Lua scripts running within DFHack) for the specific purpose of providing a "raw" description of one or more objects, primarily during worldgen. From what I've been able to gather from the conversations I've seen (and had) with Putnam, DF's inboard Lua scripting environment will not be able to modify other aspects of the game environment the way ours can.

It is possible that we may be able to invoke DF's Lua engine from DFHack, but this will most likely be accomplished using a call gate implemented using a C++ std::function object in a readily discovered location, the same way we access other functionality that Bay12 has explicitly exposed for our use in DFHack.

The community is, as it is wont to do, overreacting to this announcement. Yes, it's an interesting expansion to the way DF uses its "raw" language to specify in-game content, but that is all it is. In reality it's almost orthogonal to what DFHack does.

I see, do you see a future, where DF would expand their Lua interface to encompass more of the behavioral mod needs? Similarly what about being able to interoperate by having either DF or DFHack update to the same Lua version and language?

I don't see either of these being likely, at least in the short term.

Does that even make sense? Could i write a single Lua script that talks to both DF and DFHack interfaces (if they were the same version)?

I'm not seeing how this would be useful, even if it were possible.

[sgayda2]

Thank you for the quick replies and for all the information!

Hopefully this discussion will be discoverable so that others can get a real expectation of what this means and not just an overreaction to the announcement.