Added parseReportString, which parses a string using '&' as a control character (&r as newline, && as &) and cuts to a certain length w/o splitting words.
Added autoDFAnnouncement, which takes a report_init and a string, and handles them like DF does.
Added variants to log unprinted announcements and to build the report_init from arguments.
Added pauseRecenter, which recenters on an xyz coord (item style, not unit) and optionally pauses, while respecting pause_zoom_no_interface_ms.
Added variant that takes a pos.
Added recenterViewscreen, which recenters on an xyz coord using a report zoom style (item, unit, generic. revealInDwarfmodeMap calls "unit" style "center". Generic style ignores coords and just enforces valid view bounds.)
Added variants that take pos or use current cursor coords.
* route 'Loading script...' messages through the debug logging framework
* they are now controllable via debugfilter. to turn off, add this to your dfhack.init file: debugfilter set Warning core script
* clarify debug logging docs
* prevent DEBUG messages from being compiled out of the binary
* recolor INFO messages so they blend into existing console output
* add configuration interface for log message header elements so they are individually configurable. all default to off
* Add functions reverse-engineered from ambushing unit code
* Fix whitespace
* Fix debug_showambush check
* Remove getOuterContainerRef from Lua API
Don't think this works properly without allocating a new specific_ref. More trouble that it's worth.
* Fixed tile visibility check
* I don't think gamemode or gametype are ever NULL
* Minor tweaks to documentation
* Reimplement getOuterContainerRef for Lua; fix some comments
* Update Units.cpp and changelog
* Update Units.cpp
* Update changelog.txt
- handler freq now works on an individual handler basis (set to 0 to fire as frequently as possible)
- tick events no longer need to be re-registered after every eventful tick
Derived from disassembly of DF code. Returns a pointer to plant struct that owns the tile at position. Useful for finding a tree from one of its branches. Lua API support.
refactor is a straight copy-paste. this code could really stand some
cleanup (unused vars, unnecessary use of the MapCache layer, forced
allocation of all blocks even if they are not being unhidden, etc.), but
that can come in a later PR.
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
this allows callers of Buildings::setSize() to "pre-initialize" the
extents to declare non-rectangular structures. this allows quickfort to
create non-rectangular stockpiles, farm plots, zones, etc. the extents
are still reset as before if the size of the building doesn't match the
caller's expectations.
this commit also fixes a memory leak when setSize() allocates memory for
extents, but the memory is not deallocated if the building is ultimately
invalid for some reason.
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
The typedefs in the header foward-declared new structs of the same names in the DFHack namespace, e.g. DFHack::xlsxio_read_struct. Apparently the constructors that used these typedefs are not inlined on Windows, so libdfhack was compiled with a constructor taking a "DFHack::xlsxio_read_sheet_struct", and xlsxreader was looking for a constructor taking just a "xlsxio_read_sheet_struct", which didn't exist.
I refactored Filesystem::listdir_recursive to support removing the path
prefix from the returned files list. There are no current calls that
make use of the prefix parameter, so I converted it into a boolean.
Current usages will use the new default parameter and will not see any
changed behavior.
RemoteServer and PluginManager side would need complete redesign to be
data race free and concurrent. But as that would be unlikely to be
required from DFHack I decided simpler solution that is fixing data
ownership to a thread and all ServerConnection share a single lock which
allows access to PluginManager and Core.
Alter World to use Persistence instead of storing data in historical figures.
Fake historical figures will be converted to the new format when a world is loaded.
Added plugin_save and plugin_load functions to the plugin API.
Made the weird int7/int28 code that was in the old persistence API slightly safer.
This moves code intended to infer biome type currently living in a
couple of plugins into the Maps module, so that this code can be shared
more easily by multiple plugins, as discussed in #1392.
The runtime debug print filtering support dynamic debug print selection.
Tis patch only implements basic core support for filtering. The commands
to change the runtime filtering settings will be added in a following
patch.
But even with only this one can change filtering settings by editing
memory using a debugger. It can even be automated by using gdb break
point commands.
- Use port from remote-server.json in dfhack-run
- Make DFHACK_RUN environment variable take priority over remote-server.json
- Log current port to stderr
The bools could use acquire&release memory order or even relaxed but I
didn't think code was worth auditing for such low level optimizations.
Sequantial consistent is fast enough but much harder to use incorrectly.
The timeLast is protected by CoreSuspender lock. plugin_update is only
called when CoreSuspender lock is held.
The last_menu is protected by trackmenu_flg loads and stores.
The old CoreSuspender requires processing from Core::Update to allow
commands execute. But that causes issues if Core::Shutdown wants
quarentee cleanup order with std:🧵:join. Fixing shutdown ordering
adds too many branches to already fairly complex code.
I decided to try to refactor CoreSuspender to use simpler locking
locking using a std::recusive_muted as primary synchronization
primitive.
To help control when Core::Update unlocks the primary mutex there is
std::contition_variable_any and std::atomic<size_t> queue lenght
counter.
The last state variable is std::atomic<std:🧵:id> that is used to
keep track of owner thread for Core::IsSuspended query.
This should be merged only just after a release to make sure that it
gets maximum testing in develop branch before next release.
Fixes#1066
There is a minor chance that console or init thread would access already
freed memory when core is shutting down and cleaning up state. To avoid
any danger of having random bugs caused by the potential data race I
decided to make sure the shutdown code waits for the thread to exit
first.
Windows change is completely untested. It is purely based on msdn
documentation.