Closed julianandrews closed 3 years ago
Things to do:
M
properties to MA
for empty board points, and to TR
for stonesL
to LB
TE
then BM
in a node to IT
BM
then TE
in a node to DO
VW
per conversion instructionsRather than try to track whether conversion has happened, or try to throw errors on conversion for FF[4] files, I've settled on adding a parse_with_options
function which allow specifying whether to attempt conversion. The default parse
function will take no arguments and will perform conversion silently. Users wanting an error on conversion can use parse_with_options
to specify the behavior.
I've now implemented the most basic fix needed to address https://github.com/julianandrews/sgf-render/issues/3.
If you've wandered in from the internet and care about having the other conversion features implemented let me know - while I plan to implement this eventually, right now I'm operating on the assumption that no one is likely affected!
I've added support for extracting the FF version earlier in the parsing process. parse
should now fail if it attempts to parse an sgf that's explicitly marked as FF[4] when it has incompatible properties.
When I get around to doing the other conversions, I should be careful about how I handle them.
I think maybe instead of allow_conversions
I should switch to a ConversionMode
enum that lets you pick between strict conversions (where we'll only convert if the FF is specifically stated, and otherwise validate all files as FF[4]), a no-conversions mode where no conversion is attempted, and a default mode that attempts conversions unless FF[4] is specified.
Apparently PandaNet/IGS includes properties that look like:
(full games available here).
This leads to failures like https://github.com/julianandrews/sgf-render/issues/3. Here's another example: https://github.com/Kashomon/glift/issues/101. This isn't valid FF[4] but is valid under FF[3]. Given how widely-used PandaNet is, I think it makes sense to support parsing these files.
I don't want to put in the support for fully validating FF[1], FF[2], or FF[3] files since that would be a ton of work that probably no one would ever use. However the spec does provide specific instructions for converting old files to FF[4].
It would be reasonable to convert when loading a file - though if conversion is required, and the file is explicitly labeled as FF[4], that should probably be an error.