Closed tdhsmith closed 3 years ago
Brainstorm: Rather than coming up with a new syntax or flag for expressing this, the simplest thing in my mind would be a YAML list that can contain strings or parameter name references.
default_filename_format:
- "Chronicle" # just using quotes to visually distinguish a raw string -- I know YAML doesn't care here
- meta:id
- param:char
- param:date
Of course it would probably be best to escape those values properly for filenames / remove any problematic characters.
I just realized this setting could also allow you to simply omit the <outfile>
argument when running with regular fill, which would be nice too!
Fully agree that naming of output files needs improvement, rather disagree on proposal to do this with additional yaml input. If a GM then wants to adjust the output naming pattern to her/his personal needs, it would mean that the yaml files needs to be changed, which I would put in the no-go area.
What I was thinking on solving this (painting a broader picture here):
batch fill
. Instead allow to provide most of them like, e.g. --template=pfs2.s1-23 --input=blank_chronicle.pdf
--outfile-pattern=<date>-<societyid>.pdf
, with supporting parameter names of types text
and societyid
.batch fill
is the name of the CSV file.rather disagree on proposal to do this with additional yaml input. If a GM then wants to adjust the output naming pattern to her/his personal needs, it would mean that the yaml files needs to be changed, which I would put in the no-go area.
Yep that's logical. I wasn't sure if the templates were supposed to be accessible to/modifiable by users or not. Just thinking like a lazy developer and trying to use existing systems first. ;)
I love the look of the overall direction -- eventually being able to run off CSVs alone would be great for automation, since we could be collecting player data via form/Google Drive that already includes the necessary configuration values and then just pour it into the command with no extra options.
Users can modify the templates, but it is not expected that they do so. Especially currently their changes would be overwritten with the next update of the program and its provided templates. Also at the moment I do not yet care much about backwards compatibility, as this is still a new product that is not yet feature complete and bound to change everywhere.
Perhaps in the future a state can be reached where people start contributing new templates, at least for new scenarios where the base configuration for the season already exists and only a few parameters have to be tweaked.
Done. Now all command line flags can be provided via the CSV file, except of course the name of the CSV file itself.
The default
Chronicle_Player_X.pdf
gives about the bare minimum of organizational usefulness for the way I tend to use chronicles.For me, the values I like to have in the filename are the date, the adventure, and either the character's name or the player's name. Yes, some of these will be covered by directory structure, but it's useful to have them duplicated both as a sanity check, and for when I am sending them to players (i.e. over email). When I am looking back later, I will not know the player number at all.