Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Eldin00]

This is a bug that some people experience when using workflow in DFHack. I've never seen a report of it occurring from a user who could verify that they had never enabled workflow in that fort, so the bug is almost certainly in workflow, and not a DF bug. The only guaranteed solution seems to be "don't enable workflow", but anecdotal evidence suggests that the more heavily you make use of workflow, the less likely this bug is to pop up.

My suspicion is that there is some extra step beyond setting the flag that happens when you set it through the normal interface that workflow isn't doing, and that not doing that step results in jobs sometimes getting ignored.

[milo christiansen]

It is almost certainly more than just setting the flag that needs to be done. For example if you set an item's forbidden flag with DFHack it is possible that dwarves will still try to haul it away because a hauling job still refers to the item (you need to find and delete the hauling job too). I assume workshop jobs have similar hidden dependencies, it probably needs to add the job to some kind of list.

I assume that it has something to do with the job priority stuff.

[falcn]

My suspicion is that there is some extra step beyond setting the flag that happens when you set it through the normal interface that workflow isn't doing, and that not doing that step results in jobs sometimes getting ignored.

But workflow is only using DFHack API to resume tasks

Code: [Select]

    void set_resumed(bool resume)
    {
        if (resume)
        {
            if (world->frame_counter >= resume_time)
                actual_job->flags.bits.suspend = false;
        }
        else
        {
            resume_time = 0;
            if (isActuallyResumed())
                resume_delay = DAY_TICKS;

            actual_job->flags.bits.suspend = true;
        }

        want_resumed = resume;
    }

Code: [Select]

    df::job *actual_job;and it worked fine in 0.34

I think this dfhack bug. Workflow is the only popular plugin that suspends and resumes recurring tasks, thus nothing else triggers it.

[Eldin00]

My suspicion is that there is some extra step beyond setting the flag that happens when you set it through the normal interface that workflow isn't doing, and that not doing that step results in jobs sometimes getting ignored.

But workflow is only using DFHack API to resume tasks

Code: [Select]

    void set_resumed(bool resume)
    {
        if (resume)
        {
            if (world->frame_counter >= resume_time)
                actual_job->flags.bits.suspend = false;
        }
        else
        {
            resume_time = 0;
            if (isActuallyResumed())
                resume_delay = DAY_TICKS;

            actual_job->flags.bits.suspend = true;
        }

        want_resumed = resume;
    }

Code: [Select]

    df::job *actual_job;and it worked fine in 0.34

I think this dfhack bug. Workflow is the only popular plugin that suspends and resumes recurring tasks, thus nothing else triggers it.

What that code is doing specifically is using the DFHack API to set the suspend flag. My assumption is that when you suspend/resume a task via the DF interface, it does something else in addition to setting this flag, which isn't being done by the above code. And that skipping that "something else" sometimes results in the job getting stuck. The fact that simply setting the flag worked in previous versions isn't particularly relevant, since the jobs system underwent an extensive rewrite during the .40 development cycle.

[milo christiansen]

Exactly.

[falcn]

What that code is doing specifically is using the DFHack API to set the suspend flag. My assumption is that when you suspend/resume a task via the DF interface, it does something else in addition to setting this flag, which isn't being done by the above code. And that skipping that "something else" sometimes results in the job getting stuck. The fact that simply setting the flag worked in previous versions isn't particularly relevant, since the jobs system underwent an extensive rewrite during the .40 development cycle.

In my save (link in the first post) suspending and resuming task using DF interface don't make it unstuck.
My guess is that DFhack incorrectly manages tasks (partially wrong offsets or wrong/incomplete structure) and corrupts data array, thus task become stuck and survives save/load pause/unpause in this state.

[Eldin00]

What that code is doing specifically is using the DFHack API to set the suspend flag. My assumption is that when you suspend/resume a task via the DF interface, it does something else in addition to setting this flag, which isn't being done by the above code. And that skipping that "something else" sometimes results in the job getting stuck. The fact that simply setting the flag worked in previous versions isn't particularly relevant, since the jobs system underwent an extensive rewrite during the .40 development cycle.

In my save (link in the first post) suspending and resuming task using DF interface don't make it unstuck.
My guess is that DFhack incorrectly manages tasks (partially wrong offsets or wrong/incomplete structure) and corrupts data array, thus task become stuck and survives save/load pause/unpause in this state.

The flag the code sets is a single bit, the smallest piece of data a computer can recognize. If it was flipping the wrong bit, the jobs in the workshop wouldn't display a change between suspended/active, so the fact that when it suspends a job, the job shows in the workshop as suspended proves that it is in fact flipping the correct bit (at least the bit that controls the display, which is presumably the same bit as controls the actual suspension). If things are getting corrupted, it's because there is something else besides flipping that bit which needs to be done in order to make things work as they should. I don't know what that something else is, if I did, I could tell you how to fix the workflow plugin (or tell you that it's unfeasible because of the changes in the jobs rewrite, though I doubt that's the case). If I had to guess, I'd say it probably needs to update a list somewhere, but it might be something different, or there might be multiple things that need to get done but aren't.

[falcn]

Yes, this particular bit is fine, but workflow changes some other variables too, and one of them may be misplaced and cause affected task to fail some internal DF checks (something that is not visible/controlled through the DF UI).
Or maybe you right and some list have to be updated.

Anyway, I guess not much can be done without IDA at this point, and I'm not qualified

[falcn]

In the meantime, it is possible to use stockflow as replacement for workflow.
It queues tasks via manager, so it shouldn't be affected by this bug.
You have to set up dedicated stockpile for every item you want to automate.

[falcn]

This is known issue
https://github.com/DFHack/dfhack/issues/487

There is a proposed fix.