Regarding contributing to the project..

[MechanosG]

Hello. I have a few questions, and I'm hoping this is an OK spot to ask. I am interested in contributing to the project. Are contributors welcome? I have a lot of experience with a handful of scripting languages, including lua. But I'm guessing I would need to learn some c++ to be able to help with plugins, which is what I'm particularly interested in. I have no experience with lower level/compiled languages, but I would like to, at some point, attempt a labor related plugin that mimics the optimization plan functionality of dwarf therapist, except automated like autolabor. I want to accomplish the same goal as vanilla work details, inside DFHack (not necessarily using the work detail system btw), so players can automate choosing skilled dwarves for jobs - something I find very cumbersome in vanilla when my fort gets to 100-200+ dwarves, and I start not bothering to check immigrants for better workers. Or even just repeated new games or random dwarf injury/moods, and not wanting to assign labor.

Would such a project be welcome? And if yes.. do you have any advice on where I should start? I assume there isn't enough exposed to lua to be able to make such a plugin in lua alone? If there was, I'd definitely go that route (and would love to hear about it!). Assuming not, would I need to learn c++ before considering anything else? Despite not having used c++ previously, I can pretty much read and understand most of https://github.com/DFHack/dfhack/blob/develop/plugins/autolabor/autolabor.cpp and some other plugins, so I'm not a completely lost. But that's where my starting point would be.

Thanks for any advice/answers you can give me.

[myk002]

tl;dr: welcome aboard!

I myself became a regular contributor because I had a project idea (quickfort) and no experience. I didn't even know Lua was a language at that point, so you're ahead of where I was.

Anything that runs in the background at high frequency is usually implemented as a C++ plugin for performance reasons, but functionality-wise, anything you can do in C++ you can also do in Lua. Our C++ API is directly exposed to Lua. If you look in existing scripts, calls to dfhack.something.something are calling into C++.

Also, C++ plugins have Lua extensions that are considered part of the plugin. The C++ and Lua code call each other freely.

What you are describing could be written in Lua alone (most anything can, really). However, I'd expect it to eventually be integrated with autolabor as its mechanism for choosing which labors to assign to which dwarves. (as the primary author of autolabor, @ab9rf might have some thoughts and opinions here)

So this is what I'd suggest:

1. Prototype in a standalone script. Write it in Lua. You're more familiar with the language, all the capabilities are there, and you're more likely to get an exception instead of a crash when you make a mistake. A standalone script will give you the flexibility to explore whatever you need to without existing structure to constrain you. Also, scripts are auto-reloading, so you can make live changes and then just disable/enable to load the new code. Reloading plugins takes more steps. If there is existing code inside autolabor that you want to reuse, you can make it accessible to Lua (example).
2. once you get the basic features working to your liking, let's discuss how it might be integrated with autolabor.
3. GUI support

The prototype will likely follow the pattern of emigration, which uses dfhack.timeout to do regular state inspections and modifications. That script will also give you a lifecycle architecture you can copy so you can enable/disable it with standard commands and keep persistent state.

You'll also eventually want a GUI so the player can inspect and modify labor assignments manually. We have something like this planned anyway for manipulator, and that can integrate with what you're writing (and with autolabor in general).

[ab9rf]

just some assorted observations here:

the original prototype of labormanager (which was itself a redesign of autolabor) was written entirely in Ruby, and then rewritten in C++ for performance reasons. if you can figure out a way to allow the "expensive" parts of the tool to run infrequently, writing most or even all of it in Lua should be practical

i do not know what the future of autolabor is. the labor system in dwarf fortress is under a fairly high degree of stress right now, and i am expecting significant changes to it over the next year or so, largely as putnam tries to mitigate the so-called "general strike" bug and otherwise deal with issues introduced by toady's effort to make labor management less tedious as part of the premium release. because of this, i am reluctant to try to write anything that hyperoptimizes labor assignments because any such algorithm will almost certainly be deeply dependent on details of how the base game handles labor allocations, which are (as previously discussed) not likely to remain stable. i'm therefore taking a "wait and see" attitude toward this area with regard to my personal energy, which is why autolabor has not been materially updated (by me, at least) for v50