* 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.
- implement navigation function for loading a fortress from the title
screen (requires a fortress save to be ready in region1/).
- ensure we don't try repeatedly to enter a mode that we can't reach
(such as getting back to the title screen from fortress mode). failing
to enter the mode once will skip all remaining tests in that mode.
Myk Taylor
lethosor