* reorganize init scripts into dfhack-config
allows player init scripts to build on defaults instead of replace them
this also moves the init scripts out of the main df directory
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* escape asterisks in docs
* remove unneeded dfhack.init file creation for test
* write the test init script to the new init dir
* create the init dir before trying to write a file
* rename default init files for clarity
* Update changelog
* Update docs/changelog.txt
Co-authored-by: Alan <lethosor@users.noreply.github.com>
* Try to get buildmaster to work with old branches
* Update changelog
* get keybindings from all init scripts
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Fix spacing in changelog
* split default loading into its own file
* update docs with new changes
* update help text wording in default init files
* Apply suggestions from code review
Co-authored-by: Alan <lethosor@users.noreply.github.com>
* Alphabetize changelog
* Update onMapLoad.default.init
* Update onMapLoad.init
* Update Core.rst
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: Alan <lethosor@users.noreply.github.com>
* download and cache the test save along with df
Depends on us actually putting the test save on files.dfhack.org
* run fortress tests in run-tests.py
* use google drive link for now
* make the save directory before extracting to it
Previously, only frames in the file that called `expect.*()` were printed.
This change allows calling `expect.*()` from functions called by the files
under test. See dfhack/scripts#385 for an example with `expect.fail()`.
The check previously matched any filename ending in `lua`, not `.lua`. This
caused failures in my fork because I had a branch ending in `-lua`, which
created a file of that name in `.git/refs` that was not a valid Lua script.
For extra good measure, anything under `.git` is ignored now as well.
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.
Myk Taylor
lethosor