Closed dlareau closed 5 years ago
Been thinking... maybe I'll allow the option for a folder to be the link in a puzzle and it will just pull the whole folder as puzzle components? That way it will remove the need for separate "puzzle_file" objects and process.
Probably also a nice time to add native support for custom HTML pages as puzzles.
A few comments here:
At the very least, it would be nice if the puzzle files didn't have to be placed directly in the puzzles folder with a puzzle-id prefix. The current situation (as I understand it) is that a 3 page website must have each page prefixed with the puzzle id and placed in the puzzle directory. It would be nice if I could prefix a folder with the puzzle id and then put whatever I want inside.
The optimal would be using the share link to a dropbox folder and then having the index.html page be used as the puzzle. In that case, the puzzle object would have an additional field "is this an html puzzle". HTML puzzles wouldn't have a PDF and the submission page would just have a "Click here to view" link.
That is what I was imagining. The 3 digit prefix is a hack so that the server knows which file is associated with which puzzle so it can do permissions properly. The good news is that it's only the first thing after /protected/puzzles/ that needs the prefix, so the prefixed folder with an index page would totally work.
I do hope to make automatic dropbox folder pulling work, but I might have to start using the dropbox API if that is the case. I'll deal with all that when it comes up.
Just to confirm, this means that I could make HTML puzzles right now be just ensuring that the parent folder is prefixed, right?
That should theoretically work right now.
This is the current thing being worked on, two questions have come up: 1) Will there ever be a need for both a PDF and an HTML element? I can't see any legitimate use cases that aren't contrived, but I'd be open to being proven wrong. 2) What should happen to the "Click here to download a PDF" button? My first instinct is to just remove it for HTML puzzles and not have anything replace it, but if you can think of something that would be useful there, let me know. I gave brief thought about something like "Click here to download a .zip of the HTML, but I can't see any well-intentioned reason someone would want that.
@TomWildenhain
Yes, there are cases I can imagine where having both a PDF and a website could be useful. For some puzzles (guided tour from f17: https://puzzlehunt.club.cc.cmu.edu/puzzle/650/) the web pages were accessible by scanning a QR code during the runaround. The pages were prefixed with the puzzle ID so they could only be accessed if the puzzle was unlocked. However the first page of the puzzle was a PDF (though a website would have been acceptable in this case).
However, I do not think it would ever be necessary for the puzzle page to include both a PDF and a link to the website. I think the best approach would be the following:
Give each puzzle an optional dropbox link for "web resources". All of these are copied to a URL of the form ###/resource_name
where ### is the puzzle id. All resources would not be accessible unless the puzzle is unlocked (and directory listing of course wouldn't be allowed).
Give each puzzle a "is html puzzle" option. If checked, a PDF cannot be provided and the normal preview image will be replaced with a message like "This is a web-based puzzle ###/index.html
.
Add to the management page the ability to refetch puzzle resources (similar to downloading PDFs).
Does this seem reasonable?
That all sounds good and is mostly on track with what was planned. The only real change I need to make to what I'm working on now is making the resources URL a separate URL so the staff could have both a PDF and resources.
The only deviation from the above plan is that I don't think I'll split the management out unless that is really something you want. The management page will continue to say "Fetch puzzle from URL", just now that will mean fetching the PDF if it exists and fetching resources if they exist.
Thanks for the feedback!
Solved in 8f7abc1
In the attempt to get old puzzlehunts archived properly (#63), I noted that some puzzlehunts used additional files for certain puzzles besides just the PDF. Stuff like: https://puzzlehunt.club.cc.cmu.edu/puzzle/504/ https://puzzlehunt.club.cc.cmu.edu/puzzle/604/ https://puzzlehunt.club.cc.cmu.edu/puzzle/650/ etc...
Having to put these files in place manually violates two goals of the project: 1) No server interaction necessary (puzzles like these should be possible even if there isn't a techno-wizard on staff) 2) The only thing that should need to be backed up is the database. The ideal is that if the server catches fire, I spin up another box from cclub, pull the code from git, restore the database, click the "download puzzles" button and the hunt is up and running again. Having these manual files in there doesn't play nice with that workflow.
I'm gonna wait till after the current hunt to really start thinking about this, but it will probably just be some form of additional model with fields that can be populated from the puzzle page.