dfhack
dfhack copied to clipboard
DFHack
labormanager: add option to use a specified labor as an ignore marker.
Any labor can be specified for use as an ignore marker. When specified, any dwarf with that labor enabled will be treated as always busy using the same logic as burrows or military activation. This is easier to manage than burrows for people using Dwarf Therapist, and makes combining automatic and manual job assignments easier (in combination with Dwarf Therapist and the disable labor option in #1386).
If ival(n) defaults to -1 (like the corresponding language_name fields do) then I'm pretty sure it should work.
I don't see anything in what you've provided to prevent labormanager from setting the marker labor on one of the dwarfs it is managing.
True, if only there were some system that allowed one to disable a labor from being managed entirely :) I made the changes you requested in the other PR that does provide this functionality, if/when that goes in I can piggy back it to make setting a disablemarker imply disabling that labor from management. Until then I will hold off on this, or I will be making conflicting changes.
handle the situation where there is a persisted configuration that was saved by a prior version of this plugin.
Yeah I thought I had confirmed that the data was always initialized but a second look gives a different impression. So I could bump the minor number of the existing storage and copy the known values over, or I could just use different storage (although I guess it is more polite to be optimal with storage, I don't know how much there is?). Which would you prefer?
/edit Just saw @lethosor comment, I guess this is what I must have seen when I checked first time then (and I missed it this time around!), so hopefully that will work out okay?
Here is the line that does the -1 init
@BenLubar and I were talking yesterday about redoing the way persistent storage is implemented (see #955). I'm not sure what the best approach is. However, I think @lethosor is probably correct about uninitialized ivals defaulting to -1, which is what NONE is mapped to, so that will probably be ok. You still need to address excluding the "marker labor" from being managed.
Be aware that I am seriously reconsidering a major refactoring of all three automatic labor managers (autolabor, autohauler, and labormanager). All three share a ton of common code, and someone should only run at most one of them at a time, so combining the three of them into a single framework, with selectable submodules, is likely the trajectory we're heading on here.
@billw2012 Coming over here from the issue that was commented on. Has any thought been put into having a custom defined role be the indicator for the dwarf to not to be utilized, because using alchemy would break eventually once that is put in place. Though, that may be less of a concern because of things breaking anyways whenever DF updates.
closing this as labormanager is being merged with autolabor, and the whole thing is due for a rewrite.
