-
Notifications
You must be signed in to change notification settings - Fork 472
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[dreamfort] revise according to playtesting and feedback #1921
Conversation
docs/changelog.txt
Outdated
@@ -43,6 +43,7 @@ changelog.txt uses a syntax similar to RST, with a few special sequences: | |||
- `tiletypes-here`, `tiletypes-here-point`: add --cursor and --quiet options to support non-interactive use cases | |||
|
|||
## Documentation | |||
- `quickfort`: Dreamfort blueprint set improvements: extensive revision based on playtesting and feedback. includes updated supporting ``onMapLoad.init`` file and automation orders JSON files. see full changelog at https://github.com/DFHack/dfhack/pull/1921 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this the right section? Or do you want it under "Misc Improvements", maybe? Or split? (Asking because it looks like a lot more than just documentation changes)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm, um, not sure that ended up in the documentation section. I intended it for Misc Improvements
. Slip of the arrow keys? Unintended consequence of a rebase? Brain fart? Dunno. Probably that last one. Will fix.
What are your thoughts on where the supporting files are stored? Would the automation orders, sample onMapLoad.init
, and sample professions files be better off distributed with DFHack? I designed them to be useful beyond just Dreamfort, and I'm starting to think they would benefit from version control, but that doesn't mean that they have to be part of the DFHack package.
If we do add them to the DFHack repo, I'm not suggesting that they be loaded automatically. The onMapLoad.init
file is too opinionated for that, especially with the autobutcher settings. They could be added to an extras
directory or something, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It makes sense to me for them to be tracked. Unsure if there's a good existing location for them, though. hack/examples
maybe? We have a bit of a special case with example raws currently, with plugins/raw/*.txt
getting installed to hack/raw/
, but this wouldn't really fall into the same category (just noting something similar we have set up already).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea of hack/examples
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That works for me, as long as we make it clear that they are actually ready-to-use, not just toy examples or syntax examples
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I'll merge this PR as-is and address the additional files in a new PR
prioritize
scriptprioritize ConstructBuilding
where especially useful