GCC appears to be optimizing the call to `cancel_job()` to use the stub in
*DFHack's* job_handler vtable, which is a no-op. Lua was unaffected because it
invokes vmethods through method pointers (without knowing the target instance at
compile time), so use a similar approach here for now.
As mentioned by @ab9rf on Discord, we should pursue an alternative like asking
Bay12 to expose the relevant code through a global `std::function` instead of a
vmethod.
* don't delete general refs from jobs that we cancel
though we still disconnect the refs if we can
* get job remove working in all cases
we apparently need to manually handle DestroyBuilding jobs
everything else we should let cancel_job handle
* update changelog
* ensure job items are disassociated from the job
when the job is removed. the new df-provided ``cancel_job()`` doesn't do
this for us whereas the old custom implementation did.
ref: #2028
* remove trailing whitespace
* Clean up general refs before removing job
Because the game method doesn't do it itself
* Fix typo in var name
* clean up code
* update changelog
Job remove eliminates a job's worker & holder references, if any, puts
the worker on cd, if appropriate, removes the job's postings, eliminates
the job from the global linked list, and then finally deletes it. This
code was tested by incorporating it into autochop and it does make the
plugin work. However, chop jobs don't have holder building references,
and anyway, with DF being 90% edge case by volume, this could use a heck
of a lot more testing.
I saw elsewhere code that prevented worker removal if the job was a
special job, and that made me feel funny so I made the job remove method
not work if the job is a special job.
if job cannot be done right now, game puts it in df.global.world.job_postings
when job finally can be done, game removes job from postings and clears posting_index
that index should not be cloned by job-duplicate(new jobs(added by vanilla way) have that value -1 always anyway)
cloning posting_index into the new job causes that job to be ignored
Without removing postings correctly, it was possible to end up with
multiple workers assigned to a job that workflow had suspended
multiple times, which caused crashes if more than one worker was
assigned to the same job by DF.
This adds an additional command, fix-job-postings, that runs
automatically when loading a world and fixes:
- Multiple job postings that point to the same job
- Job postings that point to a job where posting_index == -1
(i.e. jobs that should have no posting assigned)
Fixes#741
The threshold is set at the level when they start to blink - normally
they would continue on with the job until they get a thirsty/hungry
thought, but immediately run off to eat if they lose the job (thus
refusing to load the engine after firing it). The code checks for
active sieges and whether there is a free replacement unit.
For more flexibility, the base api is split into 3 phases:
alloc, setSize, and construct. No support for non-actual
buildings like stockpiles and activity zones at the moment.
This is an incompatible change to the plugin ABI.
The Console is not thread-safe unless used indirectly
via color_ostream_proxy, so everything should use their
per-thread stream.