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.
- 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
since the example I had used no longer exists now that we have
parameterized aliases. I had to find another example in the industry
blueprints. I made it a proper "tip" and added more explanation as well.
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
player-visible changes
- removed text that showed up if you used the wrong hotkeys. no other
dfhack screen does this, and it seems unneeded. can add back if others
think otherwise, though
internal changes
- 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
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.
lethosor
Myk Taylor
kristjanmoore
Ryan Bennitt