Print

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

[Kogut]

Dwarves should avoid standing on areas designed for removal, what includes.
- floors[1]
- walls
- area designed to be channelled

It especially includes area with removing work in progress. I know that dwarfs are dumb but starting removing floor job while standing on floor[2] with another remove construction job in progress is bit too dumb.

[1] except floors directly above wall/rock/soil
[2] floor 20 z-level above moat

===
Posted on ESV

[Bohandas]

I definitely agree with this. It makes sense and doesn't strike me as something that would be too hard to code for (although, granted, my only personal programming experience is from a course I took in high school, so I can't be sure of that)

[IT 000]

Supported, my legendary weaponsmith and his parade of children streamed over a bridge outside my fort. The weaponsmith was okay, but the children fell fifty z-levels, through two caverns, onto a bed of upright steel spikes. Pressure plates kicked in and the room flooded with magma and promptly drained.

So I did it again on the cat lady.

[Reelyanoob]

Dwarves should avoid standing on areas designed for removal, what includes.
- floors
- walls
- channelled area

It especially includes area with removing work in progress. I know that dwarfs are dumb but starting removing floor job while standing on floor[1] with another remove construction job in progress is bit too dumb.

[1] floor 20 z-level above moat

Maybe a way to get this behaviour is for dwarves to taking pathing cost into account when deciding where to stand when building / demolishing, then you could designate unsafe areas as Restricted pathing cost and be pretty sure that dwarves won't stand there when building, helping to reduce trapped dwarves. Areas marked for removal would have a little extra 'cost' calculated by the AI, and areas actively being removed would have a much greater cost.

[IT 000]

- channelled area

XXX
#D#
###

X = wall
# = 1z level of open space
D = Dwarf who is channeling where he is standing

Could cause a problem if the dwarf doesn't channel where he is standing. Likewise

XXXX
#DD#
####

The dwarves are trying to channel the block under each other.

[Jeoshua]

The way to avoid this happening is even more simple than that, Reelyanoob.

Dwarves already avoid standing where a wall has been designated to be built when building a wall themselves.  It would not be hard to make them do the same for floor removal, by using the same bit of code that makes them avoid standing on designated construction zones.

And while we're at it, add a "kick the cat" routine into building things? I'm sick of my masons getting adopted by cats and becoming unable to construct walls cause "Mittens" is always sitting there expectantly.  Sure it's realistic, but so is shooing the damned cat out of the way.

[Kogut]

- channelled area

XXX
#D#
###

X = wall
# = 1z level of open space
D = Dwarf who is channeling where he is standing

Could cause a problem if the dwarf doesn't channel where he is standing. Likewise

XXXX
#DD#
####

The dwarves are trying to channel the block under each other.

I reworded it to: area designed to be channelled. Is it OK now?

[Maybe we can] add a "kick the cat" routine into building things? I'm sick of my masons getting adopted by cats and becoming unable to construct walls cause "Mittens" is always sitting there expectantly.  Sure it's realistic, but so is shooing the damned cat out of the way.

Very good idea.

[isitanos]

I approve. I hate babysitting channeling/floor removal jobs so much that I usually just designate and hope for the best. It usually ends up in the death of several legendary miners.
Dwarves should also avoid causing collapses: if they're gonna create a chunk suspended in thin air by removing the current tile and that chunk is itsef designated, they should remove it first.


Is there an eternal suggestion voting item for this? I would definitely vote for it.

[Kogut]

"Dwarves should avoid standing on areas designed for removal" added to ESV

[Jeoshua]

Dwarves should also avoid causing collapses: if they're gonna create a chunk suspended in thin air by removing the current tile and that chunk is itsef designated, they should remove it first.

Maybe they could pause and undesignate the area like they do with warm/damp stone.  With another option in the announcements.txt file, you could even make it not pause and simply undesignate it for you... until you tell him twice he won't dig it, for fear of his own life.

This is just one of the many ways that dwarves could be made less suicidal, but one of the easiest I'd think.

[Bohandas]

What we need is the ability to specify what order tiles slated for removal will be removed in. That in  itself would clear up a lot of trouble and it would give a jumping-off point for new AI code to prevent the specific phenonenon being discussed here.

[zilpin]

This adds a specific case condition to the pathing.  Slowing down the slowest bottleneck of DF.

Maybe the best way is to add the FORBIDDEN path maker (after RESTRICTED), which makes the tile completely forbidden to friendlies.
It has many other uses, but would fit all the needs above and not need any special code for checking values in distant places in memory.

Memory structures in DF to check a designation for removal (as suggested above) require at least 2, and up to 4 (when removing walls), additional far fetches in memory, which make your CPU cache useless.

Using Forbidden paths requires no additional memory fetches, because it already is being fetched.

[Jeoshua]

It adds nothign to the pathing.  Dwarves could still path to and over these areas, as they should be dangerous areas and mistakes should be able to happen.  The difference here is where they stand, not where they walk.  It's a simple, trivial check to perform once one gets to the job site.

"Is this place I'm standing on gonna be gone soon? If so, move a bit.  Repeat as necessary and/or cancel job if you can't find a place to stand."

It won't slow down pathfinding.

[Kogut]

What we need is the ability to specify what order tiles slated for removal will be removed in. That in  itself would clear up a lot of trouble and it would give a jumping-off point for new AI code to prevent the specific phenonenon being discussed here.

How it can help? It is normal to have multiple tiles removed simultaneously.

[isitanos]

What we need is the ability to specify what order tiles slated for removal will be removed in. That in  itself would clear up a lot of trouble and it would give a jumping-off point for new AI code to prevent the specific phenonenon being discussed here.

I don't see why we should go through the extra-tedious and boring job of manually designating the order of tile removal, when determining that kind of order is something computers are actually very good at. I'd rather have Toady automatize it than code yet another UI feature for this.


The basic idea would be to use a flood-fill algorithm every time a channel or floor removal is designated, to identify the whole contiguous region of tiles to remove. Then, treat the connected region as a graph where each tile has 0 to 8 neighbours, and apply an algorithm to turn that into a tree (the algo would either be another flood fill but from a tile on the edge of the region, or something more fancy from graph theory).


Once the tree is computed, a dwarf can only remove a tile if it doesn't have children in the tree, and it can only remove it by standing on it's parent tile. This should void cave-ins and allow several dwarves to work together without sending each other plummeting to their death. Performance-wise, the worst that could happen is a slight slowdown when designating if you designate half the map for channeling, but it shouldn't otherwise affect your fps.


This method could also be used for constructing walls in a smart order without dwarves locking themselves in, etc.