Tweet
So jb has some rooms that are mostly "solid" granite walls with only 1 or 2 "outer" granite walls for the tunneller to break through. 99% of the time these work. Occasionally however the tunneller just ignores it & breaks somewhere else. Anyone know why? Is this the ensure_connectedness routine? Is there a way to avoid it? Maybe by reserving a bit of extra space?
-
-
I'm guessing you've already resolved or worked around this, but in case it's still of interest, here's what I know from Vanilla's 4.2.* code.
The ensure_connectedness() routine is likely the cause for the breaks in the "solid" granite walls since it ignores the SQUARE_WALL_SOLID/SQUARE_WALL_OUTER flags and only avoids breaking vaults or permanent walls. There'd typically only be one such break (the only way to get more than one would be with more than two disconnected areas after tunneling, and the room in question would have to be positioned such that it was on the shortest path for connecting those areas). Something similar happens with the circular rooms in Vanilla: the way they were drawn (before post 4.2.2) leaves too thick of a layer of "outer" walls for the tunneling code to connect the room so the connection ends up being made by ensure_connectedness().
As for why it happens, the tunneling code either hits a random early termination (chance of that is set by the 3rd field on the "tunnel:" lines in dungeon_profile.txt) or reached the maximum number of steps (that's set to be 2000 in gen-cave.c's build_tunnel()) when constructing the tunnels to and from the room's center.
In Vanilla, there was a post 4.2.2 change to try and better handle tunnels from those kinds of rooms: flag the room in room_template.txt or vault.txt as having "FEW_ENTRANCES" so that tunneling code would use an "outer" wall (chosen randomly) as either the starting or stopping point for tunnels from the room rather than the room's center. The pull request with those changes is here, https://github.com/angband/angband/pull/4793 .
For better handling those rooms without those changes, I don't think that reserving extra space would help (the problem is really the tunneling code finding one of the "outer" walls rather than a "solid" one; having more room to maneuver around the room shouldn't help much). Decreasing the early termination chance or the maximum number of steps the tunneling can take should reduce the chance that tunneling fails to connect those rooms - at the cost of more computation during cave generation and more tunnels in general because of the other cases where the tunneling code has trouble getting from the starting point to the destination.
Comment