Well, unlike features such as contagion and ironness tranparency cannot be implemented as a filter on the generated moves, but would have to be implemented within the slider loop of move generator. In this respect it is similar to the already implemented ban on hopping. (As the final move does neither show what you hopped over, nor what empty squares you passed through.)
But wherever it is implemented, it has to test whether the slider loop should terminate or can continue after skipping the square, based on the piece type of the encountered piece. And in that case it might as well check the piece type of the moving piece as well, by looking in captureMatrix[attacker][victim] rather than in some newly created table transparency[victim]. So if I were to implement a parameter transparency=N, I would implement that by just filling the entire column of the capture matrix for piece number N with the code for transparency.
I have grown an aversion agains specifying pieces by number, though; it is a frequent source of bugs when you decide to add or remove a piece later. So it would be better to allow a (possibly comma-separated) list of piece IDs here. That is a bit harder to implement, because you can interpret it only after al pieces have been defined, but I already did something like that for the royal parameter.
The problem with an interface that shows the entire capture matrix at once is that for a large game it might not fit the screen. And usually capture matrices are quite sparsely populated. There are only a few special pieces, that either have their colun or their row set to something (possibly with some exceptions). But I am always open to good interface ideas.
Well, unlike features such as contagion and ironness tranparency cannot be implemented as a filter on the generated moves, but would have to be implemented within the slider loop of move generator. In this respect it is similar to the already implemented ban on hopping. (As the final move does neither show what you hopped over, nor what empty squares you passed through.)
But wherever it is implemented, it has to test whether the slider loop should terminate or can continue after skipping the square, based on the piece type of the encountered piece. And in that case it might as well check the piece type of the moving piece as well, by looking in captureMatrix[attacker][victim] rather than in some newly created table transparency[victim]. So if I were to implement a parameter transparency=N, I would implement that by just filling the entire column of the capture matrix for piece number N with the code for transparency.
I have grown an aversion agains specifying pieces by number, though; it is a frequent source of bugs when you decide to add or remove a piece later. So it would be better to allow a (possibly comma-separated) list of piece IDs here. That is a bit harder to implement, because you can interpret it only after al pieces have been defined, but I already did something like that for the royal parameter.
The problem with an interface that shows the entire capture matrix at once is that for a large game it might not fit the screen. And usually capture matrices are quite sparsely populated. There are only a few special pieces, that either have their colun or their row set to something (possibly with some exceptions). But I am always open to good interface ideas.