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>
- survey.cpp: rename loop variable for more clarity; replace use of parmeter with use of vector.size(), replace nested vector.at calls with direct index access/subscript as it is faster and easier to read
replace the local/automatic mid_level_tiles variable in matcher::match_world_tile with one that is created once during the setup phase (heap).
The dynamic part of the contained (16*16*3 = 768) vectors is being allocated on the heap in both cases - which made the repeated instatiations of the automatic variable so slow/expensive.
Also replace calls to vector<bool>.resize in nested loops with direct assignments to those vectors, which curiously even after a lot of profiling is the fastest way to reset the inorganic vectors - at least on Windows.
- embark-assistant.cpp: Replace 2 local/automatic mid_level_tiles variables with a single dynamic variable created during setup as well; add calls to matcher::setup() and matcher::shutdown()
- matcher.cpp/.h: add state with mid_level_tiles member; add setup and shutdown functions
- survey.cpp: add function reset_mlt_inorganics as replacement for the looped calls to vector::resize as all inorganic vectors are now expected to have the proper size when entering survey::survey_mid_level_tile
- survey.cpp: add function to copy all incursion values from one mid_level_tile_incursion_base instance to another; replace repeated assignments with calls to new function in survey_mid_level_tile
- survey.cpp: replacing repeated nested vector access with a region_map_entry reference in survey_mid_level_tile; made a reference mid_level_tile const to prevent acidental change of values
between stockflow and stockpiles
I removed stockpiles's dynamic placement code as well. it attempted to
move the hotkey help text down if it covered any stockpile links, but
this will no longer work since other hotkey text already takes up all
the lines below stockpiles' hotkey text.
This kind of functionality is much more important now than it used to
be since there are so many supported building types.
Also modified the 'Planning Mode' status on the building placement
screen to reflect whether we're in quickfort mode, enable all mode, or
whether just the building type is enabled.
this setting is not persisted (just like quickfort_mode is not
persisted), but it can be set from onMapLoad.init
- matcher.cpp: manually moving the cursor to the neighbouring world tile so it can be moved back and embark_update is being called when all (incursion) data has been collected
Co-Authored-By: PatrikLundell <22739822+PatrikLundell@users.noreply.github.com>
- defs.h: using mid_level_tile_incursion_base in region_tile_datum to store incursion data of world tile edges
- survey.cpp: commented out "not used" blocks of assignment in survey_mid_level_tile that no longer make sense now
- def.h: make attributes/fields of mid_level_tile_incursion_base available in mid_level_tile by inheriting from mid_level_tile_incursion_base which also allows treating mid_level_tile as a mid_level_tile_incursion_base
- survey.cpp: removing layer_bottom and layer_top, which are never read, but slow down survey_mid_level_tile significantly because entries are added quite often into the tree map structure
- survey.h: removing now obsolete include for map
allow buildingplan settings to be set from the DFHack# prompt. For
example, if a player knows they'll always want to build with blocks,
they could add the following two lines to onMapLoad.init:
buildingplan set boulders false
buildingplan set logs false
allows buildingplan to prevent unsuspension of planned buildings without
also eating the 's' key when the user is trying to use it to give the
building a custom name.
for items that cannot have a quality or be decorated:
in place mode, don't show quality adjustment hotkeys (or isDecorated
flag hotkey) and don't interpret the associated keycodes if they are
pressed.
in query mode, don't show quality or decorated fields.
solves the confusing behavior when both automaterial and buildingplan
are enabled for constructions. the two plugins now communicate with each
other over the Lua layer to negotiate consistent behavior.
if neither plugin is enabled, the standard DF UI acts as normal
if automaterial is enabled but buildingplan is not, then automaterial
behavior is unchanged.
if buildingplan is enabled and automaterial is not then behavior is
the same as other buildings with buildingplan (no material selection
screen, screen stays on building placement screen after placement).
this commit fixes a bug, though, where buildingplan would only lay
down a single tile of contruction instead of a solid block when a
block is requested.
if both plugins are enabled but buildingplan is not enabled for the
building type then automaterial is unchanged from previous behavior,
execpt for an additional header showing the separation between
automaterial hotkeys and buildingplan hotkeys.
finally, if both plugins are enabled and buildingplan is enabled for the
building type then buildingplan behavior prevails, but the box select and
hollow designations features of automaterial are still usable and
useful. the 'Auto Mat-select', 'Reselect Type', and "Open Placement"
automaterial hotkeys are hidden in the UI and ignored in the feed. This
is because buildingplan takes over material selection, so 'Auto
Mat-select' doesn't make sense. Buildingplan also already stays on the
placement screen after placement, so 'Reselect Type' is not necessary.
And all buildingplan-placed buildings have relaxed placement
restrictions (e.g. they can be built in mid-air) so 'Open Placement' is
also not necessary. The missing options are replaced with blank lines so
the vertical alignment of all other options stays constant.
we also remove a few extra lua_pop() calls that are made superfluous by
the StackUnwinder.
this ensures that a player's preferences are saved across map reloads.
this is particularly important for the building material filters, since
item fulfillment tasks are regenerated on map load, and any changes in
settings when buildingplan is reset will change the item vectors that will
be searched for planned buildings. if the settings were allowed to reset,
then a player who thought all walls would be made out of blocks would be
surprised to find boulders and logs being used after the map is reloaded.
- remove buildings_use_blocks setting from quickfort config file
- add a new Buildingplan Global Settings dialog to house global settings
- move Quickfort Mode (for legacy Python Quickfort) into that dialog
- add four settings to control how generic building materials are matched:
- blocks
- boulders
- logs
- bars
- ajust the buildingplan algorithm to register duplicate tasks for
building material item filters, one for each type. since we track how
many items we've matched for a filter, the first matched item will
"win" and the extras will get detected as invalid and popped off the
queue.
- ensure boulders, logs, and bars are scanned last, and in that order
- more global settings planned for the future! see
http://www.bay12forums.com/smf/index.php?topic=176889.msg8202679#msg8202679
but restrict to only the currently supported set so we can still assume only one filter is required for each building.
changes:
- update buildingplan plugin version to 2.0
- new serialization format for planned buildings
- old persistent data is automatically migrated to new format on load
- algorithm now respects job_item filters; items must match job_item filter and buildingplan ItemFilter
- more invalid items are now filtered out, like items encased in ice. are there any others we should be checking (see BadFlags struct)
- items are sorted before job is unsuspended so final item ordering is correct regardless of what order the items were matched and attached
- item counts in filters are kept up to date so if buildingplan is disabled before all filters are matched and the building is completed by DF itself, the item counts will come out correct (though the item ordering and building "roughness" may be incorrect)
- fixes two memory leaks in building finalization code
- allows artifacts to be matched (ItemFilter defaults now top out at Masterful -- Artifact is selectable but must be manually specified)
- add gui to switch between items for buildings that require multiple item types
Replace C++ building construction code with lua constructBuilding so we can get the proper job_item filters set. these filters will be used when we replace the core buildingplan algorithm in the next PR.
Lots of refactoring and reorganizing, with only cosmetic player-visible changes.
- show quickfort mode hotlkey label regardless of whether the current building type has buildingplan enabled. before, it was only shown after the user enabled buildingplan for the current building. this eliminates the extra step when enabling quickfort mode, which force-enables all building types.
- changed signature of lua-exported isPlannableBuilding to take subtype
and custom type in addition to building type. this is only used by
quickfort, and it already sends all three params in preparation for
this change
- added lua-exported scheduleCycle(), which is like doCycle(), but only
takes effect on the next non-paused frame. this lets quickfort
run only one buildingplan cycle regardless of how many #build
blueprints were run
- declared a few dfhack library methods and params const so buildingplan
could call them from const methods
- converted buildingplan internal debug logging fn to have a printf api
- reshaped buildingplan-planner API and refactored implementation in
preparation for upcoming core algorithm changes for supporing all
building types (no externally-visible functionality changes)
- changed df::building_type params to type, subtype, custom tuple keys
- introduced capability to return multiple filters per building type
(though the current buildings all only have one filter per)
- split monolith hook functions in buildingplan.cpp into one per scope.
this significantly cleans up the code and preps the hooks to handle
iterating through multiple item filters.
- got rid of send_key function and replaced with better reporting of
whether keys have been handled
zone: enumnick command create nick for creature from given prefix and number
uinfo displays "Matched creatures" i.e number of creatures matched by filter
maxage, and minage filters accept float now
slaughter flag displayed on uinfo cretures list
- Confirmed that libexpat is built statically and linked with xlsxreader
- May need da7cda3a85 for Windows
- Although libexpat's CMake options are all prefixed with LIBEXPAT_, it also adds some cache entries like SIZE_T (from expat/ConfigureChecks.cmake). Unsure if these affect other libs.
- xlsxio may need additional reconfiguration after moving to add_subdirectory() to find libexpat/libzip on non-Linux platforms.
- no API or logic changes, just moving code around
- split buildingplan-lib into planner and rooms files
- move business logic from .h files to .cpp files
to enable writing to a subdir that may not exist, blueprint now automatically
creates folder trees. E.g. ``blueprint 30 30 1 rooms/dining dig`` will create
the file ``blueprints/rooms/dining-dig.csv``). Previously it would fail if the
``blueprints/rooms/`` directory didn't already exist.
When enabled, custom reactions will begin to produce gloves in sets, based
on the number of hands the job performer's race has, and set the
Handedness flags accordingly.
The "createitem" plugin already contains a simpler workaround (which
doesn't check body plan but instead just produces pairs), but it shouldn't
trigger when this tweak is enabled (unless you use it on a creature which
has been modded to only have "neutral" hands).
lethosor
myk002
Ben Lubar
DFHack-Urist via GitHub Actions
PatrikLundell
bseiller
Susan
Su
Myk Taylor
abstern
Timur Kelman
Tachytaenius
Nilsolm
Quietust
George Murray
PassionateAngler
kristjanmoore
Ryan Bennitt
Kelly Kinkade