This could be a new topic in of itself, but I figured since it is directly related to the topic of this thread it would be bad etiquette.
Anyways, I'm looking for insight and wisdom.
This script pimps out all the dwarves in a fort. Although I'm considering a mechanism for bypassing dwarves, it will likely be whether they have a custom profession set or not. The algorithm, although not yet rewritten for the new data structure, will go something like this:
Loop dwarves
>Select random "dorf_prof" entry (I will talk about this in a minute)
>>Check if there are jobs available for the required profession(s) of the dorf_prof
>>>If the required profession can be applied without issue, it is applied to the dwarf.
>>If there are more professions from the dorf_prof available to be inspected, then it starts randomly looping/selecting them.
>>>Each profession is checked for job openings, if there is a job opening then that profession is applied to the current dwarf.
This is where my issue comes in. I don't want my dwarves doing
tooo much, and I don't want to be too restrictive in what jobs a dwarf can do.. except when I don't want my dwarves doing two jobs within a dorf_prof.
So, as promised, dorf profs are
custom profession configurations custom professions, this includes required professions (ie. built-in df professions), priority professions to ensure work gets done, and then others to have variety and hit even more bases. On top of the professions it includes dorf_types, which can apply improved stat rolls for certain attributes, and even skills actually
(this was a convenient way to make soldiers, because dorf_types can proc via random chance[some anyway]).
Back to the issue though, I can't seem to make myself happy with regards to how I solve profession exclusions/restrictions. Right now I have a
'busy' field which is intended to dictate how arbitrarily busy it will make a dwarf. When the dorf is 1.0 busy with all its assigned professions, then it can't add any more, nor if the dwarf is 0.88 busy can it assign a profession which has busy=0.121 defined in it. I am thoroughly displeased with this however.
Because, in addition to already figuring out how many dorfs can be in a profession (which is most important for the required professions, but is still considered for all professions), and also at what ratios to the total population. In addition to that I have another ratio to finely tune by having the busy field.
I can think of at most three solutions:
-busy field: professions are allotted a busy score, and dorfs can't surpass 1.0 in their total busy score.
-bit flags/(or probably just shared id numbers): professions are assigned a bit in a <to be determined>-bit wide field, and then professions that overlap are thus exclusive to one another
-random chance: assign a chance to roll each profession inside a dorf_profs profession
(I'm gonna rename this to dorf_jobs after this post)1) Already hate this, because its a perplexing ratio that makes the table setup super painful!
2) This could be nice, but I don't
really~ want professions to be truly exclusive of one another. AND it could be even more difficult to setup adequately, and without major issues.
3) I kind of like this best, but it would be another ratio. It would also move all the
pain inside dorf_profs, which I am quite happy with as it is now with no changes! Maybe that is where the pain needs to be though, since dorf_jobs share some professions.
So if anybody is reading this, hit me with some opinions, ideas, or your local weather.
Author
Topic: DFHack lua script - Modifying Skills after embark (Read 3719 times)