remove the unneeded cache layer. the cache is for writing. we're just
reading. all the cache is doing is adding latency as it makes its copies
of map data structures.
generating a 190x190x100 dig blueprint:
before change: 1.7s
after change: 1.0s
the performance gains aren't as important here as the reduced complexity
of the algorithm, though. for reasonably-sized blueprints, the time
savings are unnoticeable.
To reproduce:
1. Enter the `d`esignation menu
2. Press `-+` to change priorities
3. Create a designation
4. Press `Alt-p` to hide priorities
5. Exit and re-enter the designation menu (`Esc`, `d`)
Previously, priorities would be visible again after step 5. With this change, they are not visible until you press `Alt-p` again.
Fixes#1068. Note that this is a relatively unobtrusive fix: selecting a priority with `+-` will still result in priorities being shown again. This is native DF behavior that I am reluctant to override because users of designation priorities likely want to see them.
- Use at() to crash immediately on out-of-range errors instead of introducing
memory corruption (see #1824)
- Replace custom implementation of df::unit::find()
- Use range-based for with get_vector() where appropriate
Planning a 4x2 construction with DF's `umkh` keys (i.e. not automaterial's box-select) would previously produce a 5x3 construction instead, for example.
Fixes#1803
Running a command that created a new screen would previously result in a screen
order that looked like this, due to how `Screen::Hide` works:
- DF screen
- `command-prompt` screen (dismissed)
- New screen
The `command-prompt` screen remained on the stack until the new screen was
dismissed, so it would intercept viewscreen vmethod calls intended for the
DF screen.
This change adds a new behavior to `Screen::Hide` that results in this screen
order after running a command:
- DF screen
- New screen
- `command-prompt` screen (dismissed) - DF removes this screen immediately
- matcher.cpp, survey.cpp: setting the state pointer to null/nullptr in ::shutdown() to prevent errors caused by accidental double-frees - an additional check if the pointer is null already is not necessary as the standard guarantees that nothing happens if delete is called on a nullpointer
Co-Authored-By: Alan <3719547+lethosor@users.noreply.github.com>
lethosor
myk002
Ben Lubar
DFHack-Urist via GitHub Actions
PatrikLundell
bseiller