Multiple independent sets of work management settings per map

[Lomztein]

Multiple independent sets would open up some new possibilities, and in theory shouldn't be too difficult to implement. Basically, rather than the single set we have right now, consisting of work specs, pawn settings, resolve frequency, ect, we could have multiple.

Each set could be accessible through tabs at the top of the window, with the current "default" set being the first. These sets should be able to be named and ordered as desired. When the alternative layout mentioned in #37 is added, the layout could be set per tab.

This would allow for extended management options, including having separate tabs for managing work, roles, weapons, prisoners, whatever the user would want. Roles and weapons could be resolved every month only, while work could be resolved daily.

On the technical side, it would be a drastic refactor of the MapWorkManager class, but complexity should be limited. All fields and methods unique to each setting set would basically be moved to a separate class, something like "WorkManagerConfiguration", with the MapWorkManager then containing a list of said configurations. Whether only data access methods should be moved over is, with functional methods such as the assignment algorithm and work resolver, staying in MapWorkManager, is debatable.

[devdave]

That makes sense, so more of a documentation issue, but also seems like an unfortunate consequence that there is no mechanitor skill except for its implant.

What threw me off is that I have the default provided construction group, which only has 4 out of 11 slots due to the "require full capability" check. An easy fix, as you said, is to restrict the work group count to the current number of mechanics and only increase the count when I add more.

Also just wanted to thank you for this project, it has been very helpful, plus the interweave priorities was a great fix to creating unwanted "hotspots" at the cost of the other tasks.

[Lomztein]

If you just want to assign all mechanitors to the work spec, then you can check for the mechlink health condition. That's what I usually do. It might be good to add an "is mechanitor" condition though, just to make it a little easier.

But yes, I agree that this is a documentation issue. Work has gone into this, but it is currently limited and hasn't really been a priority. I'll keep this issue open as a reminder to improve the documentation regarding the min worker count.

[devdave]

No rush as documentation is the bain of coding. I tried one of those "AI" code documenting tools, and it did a really great job hallucinating an entire suite of functionality the project didn't actually have.