Comments/Ratings for a Single Item

There are several issues here. The 'range' indicator 4 means 0 to 4. So all the pincher captures become optional; it can use the 0 case. And I suppose you want it to be an automatic side effect. Even if you could force it to traverse the parenthesized part 4 times, (by just writing it in full 4 times), there is no guarantee it doesn't take the path 4 times over the same piece, or over two pieces each twice.

The problem is that what you are trying to describe is not really a move. It is a form of conditional burning. These can both be described in Betza notation. But the difference is that for a move you have to pick one of the possible realizations, while for burning every possible realization should be executed. And that nothing moves during such execution: you really describe the path of a 'flame', which evaporates after having done its damage.

What you would want is being able to define spellZone=dabuafcK.

Now that I think about it, this might not be so difficult to implement. I could treat the spellZone as an extra piece, letting the Betza parser create the move list as usual. Then every move of a burning piece should automatically be followed by all possible moves of an empty square from the destination of that piece. Tomorrow I will try if I can get something working along those lines; most code for it already exists, and should just be called for another purpose.

Now that I think about it, this might not be so difficult to implement. I could treat the spellZone as an extra piece, letting the Betza parser create the move list as usual. Then every move of a burning piece should automatically be followed by all possible moves of an empty square from the destination of that piece.

Ooooh! Am I right in concluding that this would also allow for spellZone=KNS, spellZone=sRbBfW (Earthward Net), or spellZone=AXCY (Peacenik)? (I imagine that this would be done with both blastZone and spellZone.)

Not really, because I was talking about blastZone, even though I wrote spellZone by mistake. One difference is that the latter would have to deal with many kinds of spell.

But it might not be hopeless. The way spellZone is currently implemented is by tracking the piece that casts it, so that its location is known, and then before move generation create a board-size array, and mark the squares in it around the casting piece. The latter could be replaced by a move generation for the dummy piece, where each valid destination would not push a move on the move stack, but would mark the destination square. Or better, the capture square (which normally would be the same). By using c or d in the zone descriptor you could then decide whether the spell affects friends or foes (which would the need distinguishable marking).

Thinking... after that's all implemented, it looks to me like it might be possible to implement my Chicken Pawn move (the piece slides backward orthogonally or diagonally, but only if it's under attack). I wouldn't expect that right away, since it's low-priority and would (at best) require a bit of cogitation, but it sounds like it at least would be possible.

I thought it might be helpful to update this list, with new information:

A - Alfil (2,2)
B - Bishop (FF)
C - Camel (1,3)
D - Dabbabah (0,2)
F - Ferz (1,1)
G - Tripper (3,3)
H - Threeleaper (0,3)
I - Imitator
J - alt Zebra
K - King (WF)
L - alt Camel
N - Knight (1,2)
O - Castling
Q - Queen (BR = FFWW)
R - Rook (WW)
S - Second space (AD)
T - Third space (GH)
U - Univeral leaper
W - Wazir (0,1)
X - +3 ortho
Y - +2 diag
Z - Zebra (2,3)

a - again
b - backward
c - capture
d - destroy (friendly capture)
e - en passant
f - forward
g - grasshop
h - half
i - initial (or “iso” in a sequence)
ii - initial (where any such piece starts)
j - jumping (leaper) / ski (slider) / second from the end (castling)
k - king (delivers check)
l - left
m - move only
n - non-jumping
nn - non-jumping, allows en passant
o - cylinder (l/r)
oo - toroid (l/r & f/b)
p - hop
q - circular (rotates direction)*
r - right
s - sideways
u - unload (position switch)
v - vertical
x - excite (move induction/borrowing)
y - fork (in a sequence; switch between stepper/leaper and slider/rider)
z - zigzag (reverses direction of turn)

' - (following an atom) Cannot promote or morph using this move

*Also, for now, q turns a single-letter slider (B/R/Q) into a slipper.

Available atoms: E M P V

(Right now, M is proposed for Mimic, and P is being considered for Pawn.)

Available modifiers: t w

If I do this again, I may also include two-letter codes (like ck and rh), including some special codes under consideration, along with combos that achieve certain tricks like rifle, slip, null move, etc.

Again, I'm conscious to be a pain in the neck, but I contest the use of "perimeter" for S and T. A perimeter is not that!

There could be an issue when allowing arbitrary XBetza move footprints as blastZone, though: sould it have an absolute orientation, or be relative to the move of the burning piece? The rudimentary description used now was absolute; the Fire Dragon in Minjiku Shogi had a Q move, with an F burn, and burned diagonally no matter how it moved. But then you could not specify an Advancer with this.

A spellZone can only have absolute orientation, as there is no move to relate it to.

I guess c and d in the final step should be interpreted as to which side would be affected by the spell, not as what the current occupancy of the board should be before the move to be under the spell. E.g. a brake spell must affect empty squares to fullfil its function. So the marking of spell squares should use contingency planning, and tell what would happen should a piece of a certain type appear there.

Note that the apostrophe does not just affect promotion, but causes complete ignoring of anything specified in the morph or captureMatrix. That can also be burning, anti-trading rules, inaccessibility of a square.

Another proposal is cc in a final leg for move-dependent burning rather than moving.

Again, I'm conscious to be a pain in the neck, but I contest the use of "perimeter" for S and T. A perimeter is not that!

While I agree with you from a purely linguistic and geometric standpoint, I've seen the term used for this elsewhere.

I could go with "radius," though, given that it refers to moves that many steps away.

I think I'd give blastZone absolute orientation by default, with some sort of flag to make it relative. Perhaps the apostrophe can have that meaning in this context?*

Also, doesn't brake affect pieces already present, by turning sliders into steppers and riders into leapers?

I do agree with your take on c and d in the final step, but I'm not sure what you mean by "a piece of a certain type" at the end. Do you mean broader categories like those I just mentioned, or something like a spellMatrix? (I'd welcome a spellMatrix, though I can think of many other things that would take precedence, among them cc and M.)

*My first thought was w for "welative," but that's just widiculous.

Note that the apostrophe does not just affect promotion, but causes complete ignoring of anything specified in the morph or captureMatrix. That can also be burning, anti-trading rules, inaccessibility of a square.

Noted. A simple edit.

Another proposal is cc in a final leg for move-dependent burning rather than moving.

I can make a note of that, once I get more into the two-letter groups.

Should I make a page of this, as a sort of XBetza Quick Reference?

The fact you would have seen elsewhere is not a strong argument. I have seen many wrong things somewhere in my life, and I probably wrote some of them too :=) Why don't you say "square" (after correcting "ring") as HG does on this same page? It wouldn't be perfect, but it is less incorrect. Well, after all, I was just saying. With perimeter, people may understand that S=ADN and T=HGZC because they are the perimeters in a common view.

I'll make it super-explicit, then: Second Space.

Someone would have to have the brains of a lobotomized amoeba to look at the description where it says (AD) and think it means (AND), and even worse to think (GH) means (GCZH).

Perhaps, I am a lobotomized amoeba.

I was just expressing myself sloppily, and meant "pieces of a certain color".

My understanding of the rules for Hia Shatar was that pieces next to the Hia could slide if their first step left the zone. So this was how I implemented brake. Semi-freezeing of sliders already in the zone would be another, independent spell.

There is a problem with brake though. If you would specify a Q zone, a slider in the zone would be allowed to slide radially away, as the zone would be calculated before the move. So 'discovered spells' would not be implemented.

I am still 'on the fence' as to burning through a globally defined blastZone, and that defined by a cc extension of the move. Perhaps only the latter should be relative (as any move continuation). You cannot specify hopping of the flame before burning there, though, as anything before the cc leg would be considered part of the piece move. For p that makes no sence, though; as the piece destination could not be an occupied square. So perhaps the rule that preceding hopping legs are 'flame only' should apply when separating the XBetza descriptor into move and burn.

This looks needlessly contrived, though. An alternative would be to explicitly indicate the separation with a colon, and do away with cc altogether. Like Q:F for the Fire Dragon and Q:fK for the Advancer. You could then write R:[pD-bucW], or even R:[p'D-bcW] for the Pincher Pawn.

should [arbitrary XBetza move footprints as blastZone] have an absolute orientation, or be relative to the move of the burning piece? […] you could not specify an Advancer with [absolute directions]

But surely the advancer doesn't have a burning move? But rather an extension of its movement to capture on the next square? After all, passive burning is out of the question for an advancer (unless it were to remember its orientation)

Or have I misunderstood how blastZone works? (And also, now that I'm rereading the IDiag page, does the burn spell act only on pieces landing next to the spellcaster, or also on pieces it lands next to? A strict reading of the text implies the former plus a need for a matching blastZone, but this seems… an unusual rule, if consistent with modern Tenjiku)

cc (or, indeed, :) looks like it'd make sense

The colon notation strikes me as being quite elegant, and an improvement over blastZone. Writing these things out as part of the piece move is always much easier. (Now if only there was a way to write the Withdrawer as simply as you just did the Advancer!)

To make sure I'm understanding this right, though: A Bowman would be N:fN, and a Detonator's detonation would be mpabK:cdK.

I think, though, that you'd need some sort of indicator of whether the capture was optional or mandatory. Perhaps ' or + after a mandatory capture, or putting an optional one in parentheses.

Addendum: If the colon notation is used to replace blastZone, it might (I say, might) still be possible to use that variable, creating a sort of "area effect" on mid-move captures.

PS: I don't think cc is actually implemented yet, is it?

The Interactive Diagram allows independent specification of active and passive burning. (And it even allows burning as in Atomic Chess, through an addtional parameter, which causes friends to be burned as well, including the moving piece itself, but can exempt some types.) In Tenjiku Shogi these would both be set to K.

Advancer capture is a form of one-directional active burning, but it uses a relative orientation for the burn zone.

BTW, a Withdrawer could be [mQ:biQ-cK]. There is a subtlety here in where to place the burn spec; within the bracket it obvouslyy only applies to the move specified within those, and the piece could have other moves specified outside those that do not burn, or burn differently. Outside brackets the would apply to every move of the piece. KNAD:cK would be a Lion burning adjacent enemies on all its moves.

From the article:

The meaning of o could be extended to only imply wrapping when used in a final leg, but allow pieces to venture off-board without wrapping in non-final legs. This would allow moves to 'probe' for the presence of a board edge by attempting to step off-board and back. E.g. oabyaK for a (partial) Edge-Hog move.

Just a more-or-less random thought here: What if this "probing" could be done with a simple ob? That combination wouldn't make sense normally, unless the o was also in the previous leg, so if the first o in the string is followed by b then the does what you describe above. (And (ob)2 could check to see if the piece is within two spaces of the edge.)

The Edgehog could then be something like obyaKayobQ. (I say "something like" because, among other reasons, it might still need to be able to check whether it's in the middle of the board.)

Well, for one o is already implemented as this proposal describes, and it would break backward compatibility to change it. It is also often used in combination with other modes, such as m, which would require the a to go over into a next leg. If p' would be introduced for friendly hopping, as a cleaner replacenemt for the dau kludge, omcp' would be an often required combination, which now had to be spilt because of the required u. (But then again, introduction of cc for active burning (or the colon notation) would make that obsolete.)

I don't really see what you try to save here. Get rid of the single a that is needed between o and b now?

The oab... probing doesn't seem sufficient for an Edge Hog, btw. At least, I suppose a2-a7 would be a valid move for that, but at both ends the adjacent square on the ray would be on board. I suppose the way to implement an Edge Hog is through morphing: split it into two types, and morph type 1 to type 2 on edge squares, and type 2 to type 1 elsewhere. And make these non-edge squares inaccessible to type 1. So morph=E/E!!!!!!E/"/"/"/"/"/E for type 1, and morph=/.EEEEEE./"/"/"/"/"/ for type 2.

Well, for one o is already implemented as this proposal describes, and it would break backward compatibility to change it.

Oh, I didn't realize that. (Though arguably I should have.)

I don't really see what you try to save here. Get rid of the single a that is needed between o and b now?

See below about that.

The oab... probing doesn't seem sufficient for an Edge Hog, btw. At least, I suppose a2-a7 would be a valid move for that, but at both ends the adjacent square on the ray would be on board. I suppose the way to implement an Edge Hog is through morphing: split it into two types, and morph type 1 to type 2 on edge squares, and type 2 to type 1 elsewhere. And make these non-edge squares inaccessible to type 1. So morph=E/E!!!!!!E/"/"/"/"/"/E for type 1, and morph=/.EEEEEE./"/"/"/"/"/ for type 2.

That would almost be worth experimenting to find out if it'd work!

Another thought, though, would be to also probe for the edge in other directions; for example, if there's an edge to diagonal forward left or right, then the move isn't allowed, since the only places where both orthogonally behind and one of the forward diagonals gives you an edge is in the corner. And that extra bit of business is what ob by itself would save.

The same function could also be used to make a Reflecting Bishop, and related pieces. Think of this ob as saying "the entire move is only valid if this stop along the way is at the edge of the board, and the next one (if any) is not."

PS: I think the entire sequence for the above check would be something like oflabaoslabaoflab. So I'm replacing 17 letters with 2. (Probably more than 17, to figure out that it works if one direction has an edge but not two. That part might not even be doable in XBetza, but would be with this.)

Think of this ob as saying "the entire move is only valid if this stop along the way is at the edge of the board, and the next one (if any) is not."

Yes, but this is what oab... says now, make a move that leaves the board, and in the next leg step back onto it. The Reflecting Bishop (for a single reflection) is yafoabyasB. To the edge, one more step back and forthe to test whether you ran into it, and then continue again as slider in the perpendicular direction. [B-oF-bF-sB] in bracket notation. I gues even [oB-bF-sB] would do (but would generate moves in duplicat when already on the edge).

Yes, but this is what oab... says now, make a move that leaves the board, and in the next leg step back onto it.

You've already pointed out otherwise: it still allows for a move along the edge, if neither end is a corner.

Well, I suppose this depends on whether you require colinearity of the continuation. oabyafK would not allow moves parallel to the edge fecause the f forces the test to be opposit to the move. But oabyaK would allow arbitrary direction change after the back-and-forth. Problem in the context of the ID is that it would generate each move 3 times, as there would be 3 ways for a King to step off-board and back (and in a corner even 5). You would really want the test to be a W move. (And even then corners are troublesome.) With a bracket notation that would be possible: [oW-bW-aQ]. I suppose you could achieve that also with vvssoabyaK.

But I still think uing morphing is the natural solution. You want a piece that has different moves depending on where it stands, and this was what the morphing was invented for.