Storing exercise move count to jump to in SGF

qcgm1978 commented 7 months ago

(The following content beautified by Claude.ai)

The goto_move_count parameter for loading exercises should be derived from the PM property of the SGF file instead of the filename. This would make it more flexible and reduce the risk of errors.

Current approach

Currently, the goto_move_count parameter for loading exercises is derived from the filename. This means that the filename must be in a specific format, and any errors in the filename can cause the goto_move_count parameter to be incorrect.

Proposed approach

The proposed approach is to store the move count as a property in the SGF file. The property name should be PM, and the value should be the move count.

To implement this approach, the following changes would be required:

Add the PM property to the SGF file for each exercise.
Update the goto_move_count function to use the PM property instead of the filename.

Benefits of the proposed approach

The proposed approach has several benefits over the current approach:

It is more flexible, as the filename does not need to be in a specific format.
It reduces the risk of errors, as errors in the filename will no longer affect the goto_move_count parameter.


// game.js
const pm = first_node_ref("PM")
merge(game, {
    ...
    pl,
    pm,
}
// ------
let pm = ''
if (game.pm) {
    pm = `PM[${game.pm}]`
}
const header =
        `;${sz}${pm}${ha}${km}${ru}${f('PW', game.player_white)}${f('PB', game.player_black)}${com0}`
        + init_stones(true) + init_stones(false)
// exercise.js
function exercise_filename({ game, format = exercise_format, only_date = false }) {
    ...
    const mc = get_next_move_str(game)
    game.pm = mc-1
// main.js
function load_as_exercise(file, win) {
    ...
    // const move_count = exercise_move_count(file);
    const move_count = game.pm;
    goto_move_count(move_count);

kaorahi commented 7 months ago

This approach has an appealing aspect as you said, but I hesitate to use it since it does not match the official semantics of the PM property. Such a non-standard use of PM[] might confuse other SGF apps. It seems only PM[0], PM[1], and PM[2] are allowed officially.

https://www.red-bean.com/sgf/properties.html#PM

I'm not sure what the "practical" merit of this approach is. The exercise directory should be regarded as a private database of the app. Manual modifications should not be made anyway. For example, changing a file name invalidates the metadata in .config/LizGoban/lizgoban_exercise_info.json. The board size is also encoded in the file name format, which makes it convenient to list the exercises of the given size without having to read the contents of, say, 1000 files.

qcgm1978 commented 7 months ago

I misunderstood the meaning of the PM attribute, and did not consider the current exercise data storage method. I wanted to store the visits information when generating the exercise, add it to the file name, which caused errors and raised this question. The original intention was to expand the metadata of the exercise to include more context information. However, in the implementation process, if the existing data format and architecture are not fully considered, data incompatibility or other problems may be introduced.

kaorahi / lizgoban