I imagine, BTW, that someone's already mentioned the far-from-rare tendency for miners just about to complete a new through-route to finish digging out the penultimate block, target the next block along (accessible from both sides) but wander around to the other side to do it? As if the route-finder is working not on "square to be dug out", but "square to dig out from" (which is often not the one they've just cleared, which would be an ideal spot to stand and dig from, but the long-time open space all the way around the other side).
Yep, this has been brought up before, and you're right - they pathfind to squares that are adjacent to the square they need to mine. But you can't pathfind to multiple squares simultaneously, so they do them in a fixed sequence: left, right, up, down, then the diagonals. The first one that comes up as accessible, regardless of the distance, is used. The dwarf never even realizes that there's a shorter path right in front of him.
People have suggested solutions of varying degrees of complexity, but it's not been a priority for Toady.
Perfectly understandable (it not being a priority).
For the record, my solution to (to remove the need to pathfind to the multiple adjacents), is to treat the to-be-mined square as a valid destination, run a single pathfind and extract the penultimate spot as the work-from.
Don't know what language Toady works with, whether it's OOP or not, supports overloading of functions/procedures or how it might be tweaked, but maybe as little as adding an analogue to...
function pathFromNextto(from,to): pathorfail
markAsOpen(to)
fullPath = pathFromTo(from,to)
if fullPath = fail
return fail
else
markAsWall(to) /* if this wasn't done locally and needs resetting */
return partialPath(fullPath,-1)
end pathFromNextto
...if you can't just add some kind of "finalDestinationIsValidAsWall" flag recognition in the current "pathFromTo()" function call along with whatever handles the "dwarfAllowedOutside" sort of thing which allows the final step to be taken without such a restraint.
Whatever the case, mining (and smoothing and... does anything else that get so affected?) can be redirected to use pathFromNextto instead of pathFromTo (or the version that's at home to the last step being a wall under those circumstances).
Again, I don't know the code. It
seems easy enough to make a minor modification to (or modified copy of) the pathing procedure. Keeping it transparent to all other users of the procedure which don't require that little extra functionality and merrily use it as they always have. (Also, some solutions work well with unknown future changes to the pathing in-line with the suggestions here and elsewhere at improving the A* over Z-level displacement, if it isn't too spaghettiised in the first place.) But then I know that there's plenty of space between theory and practice in such cases...
Never mind workload. I bet amateurs like me suggest pseudocode fragments all the time.
(While we're here, how does wall-building work? That probably targets the exact spot (which is currently open) for a route from the material pick-up point and checks that there is an orthogonal (not diagonal) space next door (where the builder can move into after hauling the material there) as a pre-validator before even considering assigning that job and making a standard route. But
if this goes ahead and the worker arrives, could it then be made to bias towards making the builder move off to the point of entry (or an adjacent square of it, if the last move was diagonal)
where this is possible, as this would seem to be more a sensible generalisation that would negate the need to build additional 'spoiler' walls to pre-deny orthogonal access on what might be the wrong side of this last block of wall, i.e. enclosing an area with no other egress. Nah, too many ideas in one post. Ignore me.
)