Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

workflow: some resumed jobs are ignored by dwarves #487

Closed
kimitsu opened this issue Jan 12, 2015 · 15 comments
Closed

workflow: some resumed jobs are ignored by dwarves #487

kimitsu opened this issue Jan 12, 2015 · 15 comments
Labels

Comments

@kimitsu
Copy link

kimitsu commented Jan 12, 2015

There seem to be a situation for some jobs: a job that gets resumed (after item constraint check) is ignored by dwarfes - it shows up as resumed in workshop, but never gets active. Manual suspending/resuming does not resolve the issue, using "now!" or moving jobs around in the list does nothing too. Marking workshop for removal and stopping removal, after which jobs get restored in suspended state, and then resuming them manually doesn't seem to reliably solve the issue. Canceling repeat, cancelling the job and then adding the job back manually solves the problem for time being.
Example save (dfhack 0.40.23-r1): http://kimitsudesu.net/files/df/region1.zip
On level -4 there is a clothier's workshop with bunch of resumed jobs that are ignored even though most of the dwarfs have that labor active. Note that there is another clothier's workshop to the left of it. It had the same set of jobs and they were supposed to work in parallel, but in fact only one of them worked and the other got stuck. To isolate the issue I cleared all jobs from the one workshop that worked.

@expwnent expwnent added the bug label Jan 28, 2015
@lethosor lethosor changed the title workflow: some resumed jobs are ignored by dwarfes workflow: some resumed jobs are ignored by dwarves Mar 31, 2015
@acwatkins
Copy link
Contributor

Also having this issue on dfhack develop branch, with 0.40.24, all over the place. Removing repeat, canceling, re-adding, and re-repeating the top stuck item seems to fix it temporarily for the entire list. Just canceling and letting repeat readd it doesn't work. Removing some other item doesn't fix the issue. So something seems to be up with the job that would be active itself.

I initially wondered if it was the newish priority code, somehow the unsuspended job has the lowest priority or something Disabling all other labors and hauling, leaving the dwarf with nothing to do doesn't help.

@melkor217
Copy link
Contributor

Setting job field unk_v4020_1 to -1 fixes the job. Or causes game crash sometimes.

@acwatkins
Copy link
Contributor

Odd since most items are -1 and that is its init value. I've investigated some, and the items that are stuck have different values for the unknown 40.20 field.

Below are two jobs that are stuck, note their odd unk_v4020_1 value.

Job 15876: MakeArmor (repeat)
material: any (cloth)
item: vest ()
Input Item 1: cloth; quantity=10000; min_dimension=10000
flags2: plant
unk_v4020_1: 6
Constraint ARMOR:ITEM_ARMOR_VEST amount 10 (gap 5)
items: amount 0; 0 stacks available, 10 in use.
Job 16490: MakeArmor (repeat)
material: any (yarn)
item: dress ()
Input Item 1: cloth; quantity=10000; min_dimension=10000
flags2: yarn
unk_v4020_1: 162

acwatkins added a commit to acwatkins/dfhack that referenced this issue May 23, 2015
Fixes DFHack#487

* This doesn't fix existing stuck jobs, in order to fix, remove repeat, cancel, add, repeat
* Most workshops worked great after this, however, I noticed my bone bolts and wood bolts still got stuck, not sure if it is the same issue

* The unk_v4020_1 field was not being reset to -1 when resuming the job.
* Updated to be reset only when the job is being resumed
** Setting it to -1 without checking sets this field on all workflow jobs, which causes a crash
* Made other calls to suspend call set_resumed rather than setting the suspend field

This is the behavior I saw for the unk_v4020_1 field:
Suspended jobs: -1
Jobs not in the top of the list but not suspended: -1
Jobs at the top of the list to work next, not suspended: A positive integer (priority of job?)
@acwatkins
Copy link
Contributor

I've tested for a few days, it seems solid except for making bone bolts still getting occasionally stuck on me, not sure if it is related. Please test for stability, as setting to -1 in the past caused a crash. The if check to see if it needs to be suspended seems to have fixed that issue, though it would be good to get more people testing it. (Hopefully it isn't just less likely to occur)

Also note, existing stuck jobs wont be unblocked by this change. This change is only for newly resumed jobs. So, for existing stuck jobs, you must cancel them as before.

@melkor217
Copy link
Contributor

Yaaay, such fix!

@argh226
Copy link

argh226 commented Jul 3, 2015

I do have the same issue with loom, leatherwork, smelter, etc.

Is there a fix for this? I do not understand the "unk_v4020_1 value"

:(

@melkor217
Copy link
Contributor

@argh226, do you use master branch?

@lethosor
Copy link
Member

lethosor commented Jul 3, 2015

The master branch is identical to the latest release; the develop branch contains that change, but you'll have to compile it from source for now.

@argh226
Copy link

argh226 commented Jul 3, 2015

No I'm using the one with df2014 with newbpack.

@lethosor
Copy link
Member

lethosor commented Jul 3, 2015

It should be fixed in DFHack 0.40.24-r4 (presumably), but isn't fixed in the most recent DFHack release.
Just so you know, "the one with df2014 with newbpack" isn't enough for us to be able to tell what you're using - your platform and DFHack version (which is displayed when running help in the DFHack console) are more helpful.

@argh226
Copy link

argh226 commented Jul 3, 2015

I'm using newbpack which is 40.24-r3.
That would certainly mean that I'm 1 version behind :)

@lethosor
Copy link
Member

lethosor commented Jul 3, 2015

r4 is the next version (i.e. not yet released) - you're using the latest version.

@argh226
Copy link

argh226 commented Jul 4, 2015

Btw, you guys did a really nice job with these hacks. They are extremely useful.
👍

@argh226
Copy link

argh226 commented Jul 6, 2015

Maybe its obvious, is there any release date for the R4 ?

@PeridexisErrant
Copy link
Contributor

If 772ad03 fixes the problem, can the issue be closed?

@lethosor lethosor closed this as completed Nov 8, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants