[suspendmanager]: enhancement

[fricy]

Track carving designations are cancelled by the game if a build order is completed on the same tile before the carving is finished. That means the player has to wait for the tracks to finish before being able to add features to it, or has to repeat the track carving order later. It would be a nice enhancement if suspendmanager could keep these build orders suspended until the tile is carved and usable.

Furniture/machines affected: trackstops, rollers, gears, horizontal axles, doors, hatches, bridges, pressureplates

[plule]

Can we assume that any construction job sharing a track carving job should be suspended, or do you think it would cause issue for some?

[fricy]

I'm not sure. I listed the furniture that are usually used on/with tracks and I tested most of them for this issue. Floodgates can be also added for good measure, but I'm not sure anyone would want to use those over bridges. I did some more testing in the meantime, and the only exception I found is hatch covers and one tile retracting bridges over track ramps. But those are not built strickly on the track, but on the gap above.

One scenario I can think of is when someone realises a mistake, and want to change the track layout by adding a wall somewhere. Still not the end of the world if that wall doesn't get build until the carving is finished, but I'd exempt walls from the suspension.

The only other issue I can think of is multi-tile constructions, like an axle perpendicularly crossing a track not getting built, and that's only an issue if the user doesn't understand the reason.

Edit: Thinking about some more: I guess the same logic could be useful for applyiny to smoothing too. I haven't tested the exact behavior, but I assume beds/tables/doors cancel smoothing jobs.

[fricy]

Wow, that was fast. 👍

do you think it would cause issue for some?

Perhaps something like this would be useful?

[plule]

Yep, I agree that this UI would be nice. It's a general problem in suspendmanager that it does not give any feedback on why it keeps the jobs suspended. Can you open this in a separate issue? I think it will need some discussion/agreements before implementing it.

[fricy]

Possibly a user error on my part, but I get this error on game start after replacing the three .lua files in /script with the ones in the PR above.

...eamapps\common\Dwarf Fortress/hack/scripts/unsuspend.lua:56: attempt to call a nil value (field 'foreach_construction_job')
stack traceback:
        ...eamapps\common\Dwarf Fortress/hack/scripts/unsuspend.lua:56: in function <...eamapps\common\Dwarf Fortress/hack/scripts/unsuspend.lua:53>
        (...tail calls...)
        ...mapps\common\Dwarf Fortress\hack\lua\plugins\overlay.lua:412: in upvalue 'detect_frame_change'
        ...mapps\common\Dwarf Fortress\hack\lua\plugins\overlay.lua:435: in upvalue 'do_update'
        ...mapps\common\Dwarf Fortress\hack\lua\plugins\overlay.lua:472: in upvalue '_update_viewscreen_widgets'
        ...mapps\common\Dwarf Fortress\hack\lua\plugins\overlay.lua:481: in function 'plugins.overlay.update_viewscreen_widgets'
Failed Lua call to 'plugins.overlay.update_viewscreen_widgets'

[plule]

Well that was super weird that I did not got this earlier, I think there are some lua loading tricks I don't understand. Anyway, I just pushed a fix

[fricy]

git: ded5ea6 looks ok so far.

[myk002]

Well that was super weird that I did not got this earlier, I think there are some lua loading tricks I don't understand.

overlay widgets are tricky since their lifecycle is so long. they're instantiated once and kept forever. to reload an overlay widget after making changes, follow the steps here: https://docs.dfhack.org/en/stable/docs/dev/overlay-dev-guide.html#development-workflows

[plule]

@myk002 ah yes, that's likely it, thank you