fixes special case where a channel tile is specified over a regular dig
tile. this allows dig-now to produce a flat floor in that case, which is
likely what is intended.
found this bug with blueprint-generated blueprints. if both a channel
and the resulting ramp are explicitly marked in the blueprint (like the
blueprint plugin does), the channel is processed first, pre-creating the
ramp in the tile designated for a ramp. Then, when the ramp designation
is processed, the ramp is already there, which is an invalid tile to
make a ramp on, so the designation is skipped (and therefore not
cleared). this change clears the designation for both the ramp tile and
the channel tile when either is processed. this opens another edge case
where the designation under a channel is a regular 'd' mine, which will
now get ignored and leave a ramp insead of a flat floor. but I'll
address that in the next commit.
This should help identify differences in environments, e.g. what the screen
resolution is in `PRINT_MODE:TEXT`. The `scripts/gui/blueprint:render_labels`
test currently fails in an 80x25 resolution, which implies that our CI is using
something else.
- shift seventh dwarf from craftsdwarf to farmer
- give starting miners some skill in engraving to make smoothing the
cistern go faster
- update embark suggestions and sample profile accordingly
- widen clearcutting area for surface fort so trees don't overhang the
roof
- move wax from the cookables stockpile to the industry goods pile
- move coins from goods to metal
- move sheets from goods to textiles
DF is hardcoded to open libncurses.so.5 first. Both libncurses.so.5 and
libncurses.so.6 on Ubuntu 20.04 appear to have a valid waddnwstr symbol on my
end, but the GitHub Actions environment might be different.
In the past week, run-tests.py has started failing due to an ncurses issue on
Ubuntu 20.04, logged to stdout:
```
Didn't find any flavor of libncursesw, attempting libncurses
Symbol not found: waddnwstr
```
myk002
DFHack-Urist via GitHub Actions
lethosor