entomb.lua Implement a function that creates a job to haul an item to a coffin.

[SilasD]

Only the function has been created; the program's UI has not been updated.

[SilasD]

Per discussion at
DFHack#1482 (comment)

Edit: to be clear, only corpse and corpse-piece items have been tested.
That discussion mentions interring arbitrary items; not tested.
That discussion mentions other scripts using this script as a module; not tested.

[SilasD]

Actually, would you put me in as a collaborator / contributor ? I'm going to archive (hopefully that will work) or completely delete (sorry) my fork of your fork, as soon as you accept or reject this pull request.

I think the way you do this is ⚙ Settings, then, over on the right left side, Collaborators, then Manage access: Add people, put in SilasD .

But I've never done it, and I seemingly can't send myself an invite to test how it works. I think it's filtering out my own account.

I'm super unhappy with GitHub right now, because I can't have two forks of the same project. So I can't have a direct fork of DFHack/scripts and a fork of your DFHack-scripts fork.

Seems like such an obvious thing to do. But no.

The error I get is: "No available destinations to fork this repository."

GitHub Copilot says:

Copilot said:
This message, "No available destinations to fork this repository," usually appears on GitHub when you attempt to fork a repository, but there are no valid accounts or organizations under your profile where you can create the fork. This may happen for several reasons:

Common Causes
Already Forked: You have already forked this repository to your GitHub account. GitHub only allows one fork of a repository per account.
(other reasons removed)

And Stack Overflow basically agrees, as does GitHub Discussions. Super frustrated, I wrestled with this for like 4 hours and kind of messed up my repositories. Anyway, I'll stop griping, you don't need to hear it.

[SilasD]

Very Important Bugfix.

Set the tomb zone field .assigned_unit to the unit.
Previously, the code only set the .assigned_unit_id, both have to be set.

If you've run a previous version of entomb on any fort you care about, go to the console,
type lua to start the Lua interpreter, then paste these three lines.
Then type quit to leave the interpreter.

BV=df.global.world.buildings.other.ZONE_TOMB
function FIX(b)print(b.id, b.assigned_unit_id);b.assigned_unit=df.unit.find(b.assigned_unit_id);end
for _,b in ipairs(BV)do if b.assigned_unit_id ~= -1 and b.assigned_unit == nil then FIX(b);end;end

[SilasD]

Another bugfix. Units keep track of the buildings (including civzones) that they own.
Update their ownership with the tomb zone.

[amade-w]

Sorry for the late reply, I've been out of town for the past few days. I'll take a look at everything today and figure out how to add you as a contributor. I'm very new to github so I have to look up everything first before I mess something up.

[amade-w]

I noticed the tomb.assigned_unit before, but they were always empty even for tombs assigned automatically by the game. Do we know what it actually does or if it's alright to leave it empty?

[SilasD]

In my current fort, I don't have any tombs that have assigned_unit_id ~= -1 and assigned_unit == nil.
They all contain (a reference to) the assigned unit.

I can check other forts if you need me to.

From the Lua console:

BZT=df.global.world.buildings.other.ZONE_TOMB
for i,tomb in ipairs(BZT)do if tomb.assigned_unit_id ~= -1 and tomb.assigned_unit == nil then print(i,tomb.id);end;end

No results in my current fort.

[amade-w]

I just noticed something: the field I find in tomb zones are *.assigned_units (plural), with a reference to an empty vector; there is no field for *.assigned_unit. I found neither in the actual coffin building itself.

I also checked *.assigned_units for other zone types e.g. assigned rooms and offices and they were always empty vectors as well.

[SilasD]

You are right. That changed between 0.51.08 and 0.51.13. Didn't know that, as I haven't bothered to upgrade my main fort for a while.

.assigned_unit was replaced with .owner_unit_cached_index which you probably should not mess with. (That's presumably the index into df.global.world.units.active or possibly df.global.world.units.all. )

Okay, reject that particular pull request.

[amade-w]

Per discussion at DFHack#1482 (comment)

Edit: to be clear, only corpse and corpse-piece items have been tested. That discussion mentions interring arbitrary items; not tested. That discussion mentions other scripts using this script as a module; not tested.

Actually, corpse and corpse-piece item haul to coffin jobs are automatically created by the game as long as:

• the unit has an assigned tomb and a coffin is built in the tomb.
• the item is a corpse, corpse_piece item, or any item gained from butchering the unit or its corpse.
• the item's ID is in the unit's unit.corpse_parts vector (as far as I can tell, only undeads need intervention for this bit).
• the item is not yet inside the coffin and can be tasked to haulers.

So a function to haul to coffin isn't necessary for items that the game would naturally put in coffins, but it would be useful for interring arbitrary items.

[SilasD]

Sure, the corpse items will get moved eventually.
This job creation code gets them interred faster because they're moved in parallel.
And, yes, I should have tested it on some bars or something.

[amade-w]

Ah yes, that would indeed be very useful.

[SilasD]

Okay, I tried interring some ballista parts with HaulToCoffin. It doesn't work. They get moved to the coffin's location, but they're left on the ground instead of being placed inside the building. Unfortunate.

Well. If you set item.flags.dead_dwarf and add the item.id to the unit.corpse_parts vector, it all just works.

Subnote: from inspection of a single slaughtered animal, unit.corpse_parts is not a sorted vector, so you can just append to it with table.insert('#', item_id) Correction: unit.corpse_parts:insert('#', item.id)

Caveat: weapons and armor which are interred are still listed in the available-for-uniforms vectors
df.global.plotinfo.equipment.items_unassigned.*. I have not yet tested if they will reappear if manually removed.

[amade-w]

Probably prudent to remove them from items_unassigned regardless. I suspect once items become part of a building they probably will not reappear in it.

Btw, I already sent you a collaborator invite in case you missed it.

[SilasD]

Okay, the pull request seems to have been merged successfully (merge strategy, not rebase strategy).
GitHub is saying everything is fine, so I'm going to archive my own fork now.

Archiving did not work; I deleted my fork. Things still seem fine in this fork.

[amade-w]

Thanks! I'm currently working in an adapted form of pedestal.lua's is_displayable_item() into the script to be called by both just before HaulToCoffin() and PutInCoffin(). Just had a case where meat items already sold to a trader was hauled away for burial. I'm not sure whether that should be allowed, but I'm leaning towards no.