Comments/Ratings for a Single Item
The first position in each row is for the non-capture. So if the Cannons are number 12 and 13 in the table, the Cannon x Cannon indications would need to be in the 13th and 14th element of the row. So 12 'nothing special' positions in front of them.
There is no row for empty squares, as empty squares cannot be moved. So you would have to specify this in the 12th and 13th row of the matrix. But it seems you are doing it in the 13th and 14th.
Maybe it is better if I explain what I want to do.
So there are these two pieces (in position 12 and 13):
lightcannon:X:mRcpR:cannon:a4,n4,,a11,n11
heavycannon:Y:pRpafcpR:warmachine:a2,n2,,a13,n13
The rule I want to implement is that heavy cannons cannot jump, be jumped, captured or be captured by other cannons. My captureMatrix looks like this:
captureMatrix=////////////11$$./11$$./
but probably I got it wrong.
Note the heavy cannon is a bit more than a korean cannon is as it can jump two platforms in order capture, but not move.
I think you have Missed my previous comment here, HG!
I was out of town for the computer-chess tournament in Zundert.
I don't know how to say that the source piece cannot hop to move, to capture, or capture said type. Meaning both ? and $.
I am not sure what you are asking. If you cannot hop to move or capture, you cannot hop at all, right?
$ indicates you can neither hop over, nor capture said type. If you can capture, but not hop, it would be indicated by ^. It is not possible in general to specify multiple effects for the same piece-combination in the captureMatrix, and in most cases this would not be meaningful anyway. (E.g. it makes no sense to specify what you promote to is the capture is forbidden.) The hop ban is special in this respect, as it does not refer to the occupant of the destination square, so that the move can involve 3 piece types. To cover the case of the Korean Cannon I introduced the $ symbol.
I think you have Missed my previous comment here, HG!
I don't know how to say that the source piece cannot hop to move, to capture, or capture said type. Meaning both ? and $.
Can someone suggest an example where the capture matrix is used?
Minjiku Shogi, Makromachy. For Golem Chess I described how it could be done in the Comments. (At that time I had already made an I.D. in the old way, uses a WeirdPromotion custom script.)
Can someone suggest an example where the capture matrix is used?
I tried something similar, and it does work as expected using betzaNew.js. But not with betza.js. Which does surprise me, as I had not expected it to be different in this respect, so I will look into that.
And make sure to set maxPromote=0 to disable the normal promotion by zone rather than by morph.
[Edit] It appears that multiple promotion sets were never implemented in betza.js.
I don't understand how to use morph for optional promotions. I have
promoChoice=W/PH/PF/PQ/PS/VH/VF/VQ/VS
and two pieces, P and V, with morph=*/5/6/7/8
and morph=*/1/2/3/4
but it won't work right. What I expect is that each piece would have one optional promotion on each of the 4 ranks before the last. Instead, they either get all the promotion options at the same time or none.
I have now done that too. But betzaNewer.js is experimental, and sooner or later will replace betzaNew.js and disappear itself (because it is fully compatible).
Let's not forget about betzaNewer.js (the one with the experimental Shogi promotion system).
It would be really nice if you could deselect a piece that you have just selected in the holdings.
OK, I now implemented this both in betza.js and betzaNew.js. (Every click in the holdings was treated as a first click, to prevent you could move pieces into the holdings, or between holdings squares. But a click on the already selected piece there indeed deserves to be an exception.)
@Fergus: I can no longer upload these .js scripts through the File Manager page of the Interactive Diagrams article. I get this error message:
Upload of
/home/chessvariants/public_html/membergraphics/MSinteractive-diagrams/betza.js
was allowed but failed! The cause of failure is unknown.
Upload through WinSCP still works.
It would be really nice if you could deselect a piece that you have just selected in the holdings. Currently this is not possible without selecting another piece in the holdings or dropping the selected piece on the board.
I must've misunderstood from an earlier conversation that multiple spells were possible if spell=defensatrate (or whatever) was put on a line after a piece listing. My mistake. (Maybe that was just something you were contemplating or considerring.)
Currently you cannot even have more than one spell in the entire game. So anti-spell spells would not be useful.
Is it possible for a single piece to have multiple spells? I've been trying to come up with an ultima variant, and I had a few ideas that might be good as spells.
- unfreeze - unfreezes frozen friends
- neutralize - disables spells of affected enemy pieces (two overlapping neutralizers would have no affect on anything but each other)
- empower - enables affected friendly pieces to capture protected enemies
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.
If that's the result, that's fine. (It'd be only on the "friendly" side, of course.)
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.
I agree 100%. I've run afoul of that several times while building the larger Kagamigi variants.
Comma-separated, yes, please. Not all games can be handled with single-letter codes (see Short Sliders).
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.
Does it mean that Re-Ghost Chess with ghosts transparent for sliders is implementable here?
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.
I'm not against the captureMatrix, but without a good captureMatrix builder (one that shows a complete table and not just one piece at a time, as the Beta PTA gives) it's a little hard to use. From a user standpoint, at least, it would be easier to have something like transparent=N as a parameter alongside iron, antiTrade, and others in that group. Even so, I'm not sure from a programmer's standpoint whether it'd be easier to implement it that way, or build a full-scale Capture Matrix Wizard (which I'd adore in any event).
What am I doing wrong here?
How would you do a piece that hides itself, though?
Pieces don't hide themselves; they just are transparent. Unfortunately transparency is currently not supported, other than making all sliders also hoppers, and then use the captureMatrix to forbid them to hop over anything except the transparent piece. It would of course be more convenient if there was a special symbol in the captureMatrix to tell that one type can slide through another. This might be implemented some day.
As to the spell zone: pieces are always immune to thir own spell, specifying a zone of only the square they stand on would have no effect. How would you imagine a piece that (passively) burns itself? Or freezes itself, or brakes itself, or protects itself? The latter three already exist as pieces without moves, steppers and iron pieces.
How would you do a piece that hides itself, though?
(I see the problem with the freeze -- though I still wish there could be a KAND option somehow. Or at least K2.)
You can do that through the captureMatrix. Just fill the entire column for the contageous piece with its own ID, except in its own row. The capture matrix has basically made the contageous and anti-trade parameters obsolete; it can do all that in a much more precise way.
[Edit] I suppose the question was for if you had various contageous types, so you would have multiple columns with automatic promotion to the captured type, and you would just leave the rows of the pieces that are immune to this blank; That could also be the pieces that are contageous. You can even make them immune to some, but not to others.
25 comments displayed
Permalink to the exact comments currently displayed.
Oh, a silly trivial mistake on my part. Thanks!