Specifying square properties was the first thing I proposed, but you didn't want to do that.
Not really. What I said was:
I suppose that it could be called a property of a square how it would change one piece type into another, and such a property can be assigned by the 'morph' parameters for each piece type, which for each (type, square) combination defines the type that would result from a piece arriving there.
So what I really said is that the I.D. already did support square properties, through the morph parameters. It is just a matter of what game rules you want these properties to affect.
As far as I understand what you are proposing, it is neither simple nor self-contained. Instead of giving each piece a simple, self-contained definition, you would split the definition of each piece into multiple interrelated piece definitions that refer back to each other. If they all referred to the same FEN-like string, then they would all require something external to themselves to be complete. If they kept things internalized by duplicating this string, it would bloat the code.
It doesn't really bloat the code, as it would simply use the already implemented code for selectively transforming piece types into each other on reaching certain squares, in a peculiar way. But it would bloat the table that specifies this 'morphing', by adding a new board-size 'plane' to this conceptually 3-dimensional table indexed by piece type, file and rank. Having a few hundred extra integers in that table hardly seems an issue in these days, where computer memories are sold by the gigabyte.
How exactly things are implemented in the script should not concern anyone, as long as it does what is required and will not consume annoyingly much resources (such as CPU time or memory). The only thing that matters is how we want to present a game with such rules to the user, and to a lesser extent how someone posting a Diagram would have to configure it. How the latter works in HTML is actually hardly important, as people who master HTML should not have any difficulty either with the FEN or the case-label implementation, and those of a less technical disposition will use wizards like the Play-Test Applet for generating the HTML. So we'd better avoid that this discussion degenerates into some kind of rear-guard skirmish on an issue that no one will ever be exposed to.
So the real issues are what the user should get to see for a variant like this in the finished Diagram. Since one of the functions the Diagram support is the summoning of move diagrams through clicking on a list or a table of pieces, it seems necessary to provide multiple entries in these tables for a piece with a location-dependent move. The I.D. also allows summoning of a move diagram by right-clicking a piece, but in that case it seems the best thing to do is to show the moves diagram for the piece in the current location. For each move diagram the list of squares on which the displayed move pattern applies (in condensed form where this is possible) could be shown above the board, behind the name of the piece. Or perhaps better, it could already be shown behind the name of the piece in the list entry you would have to click.
What I have in mind is just a comma-separated list of square coordinates as the most general form, where shorthand notation would be used for at least entire files and ranks (e.g. as 'e-file' or '2nd rank') and the tems 'dark/light squares' for checkered patterns. So no case labels, and no FENs.
Not really. What I said was:
So what I really said is that the I.D. already did support square properties, through the morph parameters. It is just a matter of what game rules you want these properties to affect.
It doesn't really bloat the code, as it would simply use the already implemented code for selectively transforming piece types into each other on reaching certain squares, in a peculiar way. But it would bloat the table that specifies this 'morphing', by adding a new board-size 'plane' to this conceptually 3-dimensional table indexed by piece type, file and rank. Having a few hundred extra integers in that table hardly seems an issue in these days, where computer memories are sold by the gigabyte.
How exactly things are implemented in the script should not concern anyone, as long as it does what is required and will not consume annoyingly much resources (such as CPU time or memory). The only thing that matters is how we want to present a game with such rules to the user, and to a lesser extent how someone posting a Diagram would have to configure it. How the latter works in HTML is actually hardly important, as people who master HTML should not have any difficulty either with the FEN or the case-label implementation, and those of a less technical disposition will use wizards like the Play-Test Applet for generating the HTML. So we'd better avoid that this discussion degenerates into some kind of rear-guard skirmish on an issue that no one will ever be exposed to.
So the real issues are what the user should get to see for a variant like this in the finished Diagram. Since one of the functions the Diagram support is the summoning of move diagrams through clicking on a list or a table of pieces, it seems necessary to provide multiple entries in these tables for a piece with a location-dependent move. The I.D. also allows summoning of a move diagram by right-clicking a piece, but in that case it seems the best thing to do is to show the moves diagram for the piece in the current location. For each move diagram the list of squares on which the displayed move pattern applies (in condensed form where this is possible) could be shown above the board, behind the name of the piece. Or perhaps better, it could already be shown behind the name of the piece in the list entry you would have to click.
What I have in mind is just a comma-separated list of square coordinates as the most general form, where shorthand notation would be used for at least entire files and ranks (e.g. as 'e-file' or '2nd rank') and the tems 'dark/light squares' for checkered patterns. So no case labels, and no FENs.