Perhaps there are some more parameters that should be made dependent on the selected setup. This would be very simple, I just have to put an "if(sel)" in front of the statement that is executed when the parameter definition is encountered, as the boolean variable 'sel' determines if the currently encountered line is within the requested set (or in set 0). The shuffle, royal and captureMatrix parameters might be good candidates for this, as these refer to pieces by their ID. And the IDs might be different in different sets. The royal parameter can also refer to piece types by number, but also there not all variants in a collection might use the same number of pieces. Other parameters that refer to pieces by number are baring, and the various anti-trading options like iron, antiTrade, protected, counterStrike...
Actually one could wonder whether it would be harmful to make all parameters subject to testing whether they belong in the currently selected set. The user can already place the definition lines that he wants to apply always in the default set (0).
Completely ignoring all lines (by just including a line "if(!sel) continue;" before the code that parses a line) would allow the auto-generated buttons to also be used for controlling the square shades and graphics type and directory, for switching between themes. There is a caveat there, though: some of the parameters for defining the look of the Diagram are only used when the page is first loaded, and would not be reprocessed when they are altered after that through a button. In particular these are the parameters that determine the board dimensions: files, ranks, squareSize, rimColor, and background. At the loading of the page these are used to create a table for representing the board, and after that the script only manipulates how the individual cells look.
Perhaps there are some more parameters that should be made dependent on the selected setup. This would be very simple, I just have to put an "if(sel)" in front of the statement that is executed when the parameter definition is encountered, as the boolean variable 'sel' determines if the currently encountered line is within the requested set (or in set 0). The shuffle, royal and captureMatrix parameters might be good candidates for this, as these refer to pieces by their ID. And the IDs might be different in different sets. The royal parameter can also refer to piece types by number, but also there not all variants in a collection might use the same number of pieces. Other parameters that refer to pieces by number are baring, and the various anti-trading options like iron, antiTrade, protected, counterStrike...
Actually one could wonder whether it would be harmful to make all parameters subject to testing whether they belong in the currently selected set. The user can already place the definition lines that he wants to apply always in the default set (0).
Completely ignoring all lines (by just including a line "if(!sel) continue;" before the code that parses a line) would allow the auto-generated buttons to also be used for controlling the square shades and graphics type and directory, for switching between themes. There is a caveat there, though: some of the parameters for defining the look of the Diagram are only used when the page is first loaded, and would not be reprocessed when they are altered after that through a button. In particular these are the parameters that determine the board dimensions: files, ranks, squareSize, rimColor, and background. At the loading of the page these are used to create a table for representing the board, and after that the script only manipulates how the individual cells look.