Comments/Ratings for a Single Item
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.
Is there a way to have a piece be both contageous and immune to contageon?
Indeed. The Ko Nets are problematic, as are other Gorgon type of pieces. Because the don't really cast the spell as a fixed zone, but as a sliding move that can be blocked. So the zone doesn't only change on their own move, which is what the Diagram's implementation of spellZone assumes. The Gorgon effect is similar to the rule that you cannot castle out of check, which is again related to e.p. capture; one could say that the latter is en depart capture. Castling creates e.p. rights not only on the squares the King passed through, but also on the square it came from. And any piece type can use those rights, not just Pawn. This is how the Diagram's AI implements the ban on castling out of check; it makes it look like exposing the King to (e.p.) capture.
Gorgons could be implemented in a similar way, by adopting the rule that a Gorgon move to the origin of the preceding move must be scored as an immediate win. The square of origin becomes a kind of e.p. square for exclusive use by Gorgons, while a thus captured piece counts as absolute royal. I guess this could be specified in the captureMatrix as a new symbol, so that you could specify in a type-selective way which pieces are paralyzed by a Gorgon. An alternative is adding 'Gorgon capture' as a new mode to XBetza.
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.
The spellZone is defined as a bitmap held in an integer, so the number of squares is limited. The N option was in fact already extra, since I didn't know any variant that would need anything else than K. or a subset thereoff. In absence of variants that actually use it, I would not extend it. (And that doesn't count variants that are intentionally designed to break the limit, as that could be done for any limit...)
Hm. So I guess I'm out of luck if I want a two-space perimeter for a spellZone -- much less the Skyward Net and Earthward Net in Ko Shogi.
Spells do not affect the piece that casts them, and I don't see why they should. The piece is always in the spell zone, so whatever the spell does simply becomes a piece property.
"Affects only itself" is basically the effect I was looking for. I just don't know how to shut down the other spaces. spellZone=0?
The spellZone is defined as a bitmap held in an integer, so the number of squares is limited. The N option was in fact already extra, since I didn't know any variant that would need anything else than K. or a subset thereoff. In absence of variants that actually use it, I would not extend it. (And that doesn't count variants that are intentionally designed to break the limit, as that could be done for any limit...)
Spells do not affect the piece that casts them, and I don't see why they should. The piece is always in the spell zone, so whatever the spell does simply becomes a piece property.
Two quick questions; I suspect the answer to both is (or boils down to) "not currently, but perhaps some time in the not-too-distant future."
1. Can blastZone or spellZone be something like (for example) KNS? or AXNX?
2. Can the hide spell be used to make the piece itself "hoppable"?
25 comments displayed
Permalink to the exact comments currently displayed.
I don't know how to say that the source piece cannot hop to move, to capture, or capture said type. Meaning both ? and $.