* 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.
This was the last failure. Unsure why this doesn't occur with other submodules.
https://github.com/DFHack/dfhack/runs/3307299302?check_suite_focus=true
```
+ git checkout dfhack
Previous HEAD position was 19b52ca 0.15.0 release
Switched to branch 'dfhack'
+ git pull --ff-only
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.
git pull <remote> <branch>
If you wish to set tracking information for this branch you can do so with:
git branch --set-upstream-to=origin/<branch> dfhack
```
to support @BeforeEach and @AfterEach semantics. however, much of our
code is scope-based (lambda-based?) so it seemed to make sense to
use a single wrapper function instead of separate before_each and
after_each functions.
Any library functions written in Lua, like `dfhack.with_finalize()`, would
cause the traceback to end even if there were more stack frames in the test file.
string:split() isn't part of the standard library, but is defined if
`gui/load-screen.lua` is run. This happens in the default dfhack.init-example
and on GitHub Actions, but not on Buildmaster.
This is an intermediate solution to get CI working again. A more complete
solution would be to move string:split() to dfhack.lua, like
string:startswith(), or to take a pass over scripts and make sure they aren't
modifying built-in types like string/table.
Myk Taylor
lethosor