AI may stall when ecountering small holes in walls

Originally posted as a question about the performance impact of low-rise windows, it seems like there may be a bug with how the AI handles wall-holes with a height of 2 blocks.

A hole with a height of 2 blocks will be considered a valid path to blocks marked for mining, but hearthlings can’t actually squeeze through. They will however ignore paths to that job, that they CAN use.

If marked blocks are behing such a small hole in the wall, the hearthlings may end up trying to mine the blocks adjacent to the small hole first, even though they cannot actually reach them. As a result, the whole mining job stalls, until manually resolved.

The same behaviour may have performance implications, when a lot of low buildings with windows just one block above the ground level are being built and/or dug from the ground.

Original post

Is it possible for low windows to impact AI performance?


I have built a Raiya settlement, that consists of houses dug from the landscape, guided by the 5 levels in z-direction used by the slice tool to allow compact multi-floor buildings.

image

Is it possible that building houses with windows so close to the floor impacts performance? I’ve already noticed, that digging the windows first trips up the AI, such that the mining job will not be finished. E.g. giving the command to dig the depicted house at once as

image

will result in the hearthlings digging out the windows, the door and sometimes, sometimes not, a straight line from the door or the blocks directly adjacent to the door, but ignore the rest of the mining job.

The only way to get the insides hollowed out is to un-mark blocks adjacent to the windows. This also applies if the whole job is canceled and scheduled anew – as long as blocks next to the “windows” are marked for digging, the hearthlings will ignore the mining job entirely. The issue isn’t fixed by placing the windows either; It looks like the hearthlings are trying to get to the blocks through the window, but cannot.


This raises the question of whether such windows keep affecting the performance later on, especially since I am seeing some performance problems in this game, that are worse than I’ve seen in other games. My suspicion is, that the AI uselessly checks if the windows are a viable pathway.


If anyone wonders: I did it as drawings, because I wrote this in a coffee break :-)

3 Likes

windows are concidered traversable-but-not-preferable, so yes, if your window is one block off the floor, like in your picture, hearthlings will concider that as a hole they should check if they fit through. they do though concider windows a bit like “anti roads” (ew, i dont want to climb through a window, i rather take another route, in code)
will this serverly hamper performance? i doubt it. unless you put like 200 of the damn things down.
if you though worry about it, you can always dig your floors one floor deeper and leave a little “step” behind the door, so the outside is one block off the floor, but the inside is two blocks off the floor, making the windows not a valid route to start with.

I noticed the mining stopping in similar case.
To workaround that, you can cancel the mining when you notice they stopped, and redo it, split into two different areas instead of a single one. Or you can first carve just the main body of the rooms, and later carve the door and windows hole.

It sounds like there may a bug in here Bug Reports

Apparently hearthlings try to reach the blocks for mining by going through the window, can’t fit through and don’t figure out that there is a door they can fit through.

Sounds like something that could be optimized away, by caching the “window not high enough” result, as hearthlings seem to need 3 free blocks in z-direction in order to fit.

That’s what I do :slight_smile:

That I avoid, because I use the mining tool to pre-plan the spacing of windows and doors, as it looks best if there is exactly one block between each window/door and each window/door is exactly one block away from the closest wall.

[#]  <- Wall                        [#]
[#]    (Door)        (Windows)      [#]
[#][#][D][D][D][#][w][w][#][w][w][#][#]

Minor correction: the vertical dimension is y; the horizontal dimensions are x and z.

Because stonehearth is a badboy and doesn’t follow common prese dent in taking z as the up and down axle :stuck_out_tongue: