* 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>
- Improve link in Binpatches.rst
- Fix `alias` anchor in Core.rst (ref #701)
- Increase depth of Plugins.rst table of contents. Some plugins were hard to
find because they fit in multiple categories.
- Fix formatting of (c) in license
- Avoid possible issues with script linting
- Move plugin docs out of Core.rst
- Fix some builtin docs, tweak other bits
The Introduction is the first page to read, and thus explains what
DFHack is, installation, basic use, and troubleshooting.
This frees up Core.rst for a detailed list of builtin commands (meant to
be complete, but I might have missed some), some other key commands, and
a discussion of init files. I also put the random notes that don't fit
anywhere at the bottom of this file.
Because it's not actually that important to the user how a command is
implemented, and the docs should reflect that. This also makes them
easier to write!
Binpatches aren't used much at the moment, so this has two purposes:
collate information so it's easier to write them again, and remove it
from other sections where it's useless.
Note that if the standalone binpatch.exe is removed, the 'patching on
disk' section can be cleanly removed from 'Using a patch' by deleting
lines 44-47 & 61-90.