Open tdhsmith opened 3 years ago
Ok, to be honest... I did not understand what you described above.
What is an "ordinary sign-in sheet"? Why should columns not be parsed?
Can you provide an example and/or more details?
I mean taking a human-readable sign-in sheet as used by online GMs and exporting it directly to CSV.
So for example, here's a template I've used before for players to enter their own data:
If I had a hidden row where I listed pfscf's labels for the fields, and a hidden column where I indicated which rows contain the player data, as highlighted here...
...then pfscf should have everything it needs to consume this spreadsheet direct from CSV export, and not require me to create a new file and paste the data there.
This particular issue is in reference to the first column. In this example I went a step further and used numbers to indicate which player # the row represented, but it could also be a simple on-off.
Just desires for further automation, and gives a much simpler intermediate step before something as involved as #56.
Notes:
societyid.player
input won't work like that -- a lot of things can be worked around with sheet formulas though anywayAh, ok, I understand the scenario now, thanks.
Out of curiosity: Would having the players as columns instead of rows be an option for you? I would expect this to not be that much of a change, both from GM side and for the players, at most people will only need to modify this sheet shortly at the beginning and at the end of a session.
Out of curiosity: Would having the players as columns instead of rows be an option for you? I would expect this to not be that much of a change, both from GM side and for the players, at most people will only need to modify this sheet shortly at the beginning and at the end of a session.
No, it's not a problem for me personally. I have seen signup sheets formatted that way before. But from my experience, the vast majority use players as rows. And if you are using Google Forms, players are always rows (unless you use some formula/transformation to change it). I'm sure people using pfscf would appreciate the benefits enough to be willing to switch though!
And to be clear all of my recent issues are definitely just ideas. The tool already simplifies 80% of the process, just trying to figure out how and where to simplify the next 2-3%. 😉
Here's an example of a popular sign-in sheet that uses columns, btw: https://docs.google.com/spreadsheets/d/1haSAT6C6d8cG1g1gFr_punV5w_m_mNVR9tT_A8-FUDE/
Thanks for the link.
Hm, I am currently wondering whether transposing a CSV and adding an ability to ignore certain rows or columns would be sufficient for proper support. Perhaps it would make more sense to either have a separate tool or at least some separate functionality within pfscf for such a scenario.
Something that either takes the URL to such a google docs sheet, or the resulting CSV as input, and then transforms this into a CSV that is fit for pfscf to work with. Probably would need an additional config file that provides information about the structure of the google docs sheet.
PS: In the link provided above the players are also organized in columns like in pfscf, not in rows ;-) But yes, I accept that other sheets out there do it vice-versa.
I kind of assume this might be already a part of your picture for the revised configuration system, but to get to the point where the tool can accept "ordinary" sign-in sheets unmodified, it'd be helpful to have a flag to determine whether a column is parsed or ignored.
It's probably easier to use it as a whitelist than a blacklist, since there are only a handful of player entries and a potentially unbounded number of columns used for instruction/decoration/organization of the sheet...