Comments/Ratings for a Single Item

Even though it ignores the 4 part of the move, it still works as you describe it

Note : It also funny to say; "my adaubacfab"

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.

oabyafK would not allow moves parallel to the edge fecause the f forces the test to be opposit to the move.

Thing is, when I try it in the Sandbox, it does allow moves parallel to the edge (which you've already noted yourself).

[oW-bW-aQ] is translated into oabyaW, which also does allow moves parallel to the edge, as well as not allowing diagonal moves.

vvssoabyaK has the same result as the first one.

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.

I can accept that as a line of reasoning, though it'd be much more "natural" if there was a way to enter it other than opening the raw code and typing it in by hand (which is sadly open to typos and other errors).

The oflabaoslabaofly sequence I suggested was supposed to test forward left, forward right, and backward of the desired move. It obviously needs to be adjusted; oabaflabalabayflK seems closer to the mark: one step opposite the desired direction to find the edge, return, turn left 45°, return, turn left 90° (returning from front left, this turns it to front right), return, turn left 45° (returning from front right, this turns it to the desired direction), toggle range from step to slide, and go. This uses the edgefinder at the back of the move, but also checks the sides to make sure that there's no edge there as well. (It checks front and diagonally because directly to the side you'll find edges if you're trying to move diagonally from the corner.) Trying it on the Sandbox, it doesn't work, so I suspect that I missed something, but hopefully my description can help you find where I went wrong there.

I used these when I hadn't learned how to use morph
Edgehog
oabyaK(af)mpafoabK
Edgemover
(af)mpafoabKoabyasW
Limited Edgehog
oabyafympafmpabFmpabasmpabafmpabasoabyafympafmpabWmpabasmpabafmpabaz(af)mpafoabK

That Limited Edgehog does exactly what we're talking about!

The sandbox doesn't seem to work with moves that involve three separate intputs, such as cabaubQ

That is true. The sandbox still uses betza.js, and only betzaNew.js can handle moves that need more than 3 clicks.

I am not sure why I haven't upgraded that yet.

Thing is, when I try it in the Sandbox, it does allow moves parallel to the edge (which you've already noted yourself).

Not for me. Except in the corner, but that is because it is then perpendicular to the other edge. But oabyafK wouldn't move from a2 to a7, like an Edge Hog should have.

[oW-bW-aQ] is translated into oabyaW, which also does allow moves parallel to the edge, as well as not allowing diagonal moves.

It does allow move along the edge because it was supposed to move along the edge: there is no f in the final leg (and an a in the bracket notation). But yes, it is wrongly translated. Bracket notation is not really supported yet by the ID. The only thing that is guaranteed to work is slider after some not-to-far leaps, to work for Griffon, Manticore and Ospray, and with some rider steps in the second leg. With more than 3 legs it is basically a coincidence if it works, especially when the legs use different atoms: XBetza is based on the use of a single atom, and the code only worries about making the atoms in the first two legs compatible.

vvssoabyaK has the same result as the first one.

Again, not for me. This one can move from a2 to a7 (as intended). It does give the correct Edge Hog moves (for an Edge Hog on an edge square). If you try that move in the Play-Test Applet and generate GAME code, you can see that the legdefs array contains only 28 moves for the Queen, so there are no duplicats. (Testing in 4 different directions, each followed by 7 different 3rd-leg continuations.) Except in a corner, where two of the test steps would go off board, and would then continue in 3 different ways each.

Of course it is still stupid: of the 7 continuations the two diagonally backwards are guaranteed to also go off board, and would always be attempted in vain. So it would be better to write vvssoabyassfhK. This limits the continuations in the 3rd leg (after orthogonally stepping back on board) to sideway (along the edge) and forward-half, 5 instead of 7. Indeed the GAME code only puts 20 moves in legdefs, for that case.

I can accept that as a line of reasoning, though it'd be much more "natural" if there was a way to enter it other than opening the raw code and typing it in by hand (which is sadly open to typos and other errors).

Well, the Play-Test Applet 2.0 allows you to do that, right?

The oflabaoslabaofly sequence I suggested was supposed to test forward left, forward right, and backward of the desired move ...

Note that a move only succeeds if all its legs meet the specified target. So what you write here only succeeds if you get off board in all directions. Which would be  the case on a 1x1 board, but there the entire test would be redundant.

what about having ii mean up to the same distance in continuations, and iii meaning at least the same distance

what about having ii mean up to the same distance in continuations, and iii meaning at least the same distance

I don't think I'd do it quite that way, but having some way to indicate this would be nice.

Do there exist pieces that need this?

It seems to me it can already be expressed by inserting an extra slider leg in the same direction for making up the difference. Like [R?fR-isR] for a hook mover limited to the forward quarter sector.

I don't think it is a good idea to invest in (and spend resources) merely simplifying cases that almost never occur.

The author, H. G. Muller, has updated this page.

Note that a move only succeeds if all its legs meet the specified target. So what you write here only succeeds if you get off board in all directions. Which would be  the case on a 1x1 board, but there the entire test would be redundant.

As I mentioned in the original paragraph, oflabaoslabaofly was erroneous; the next sentence gave an improved oabaflabalabayflK, which (theoretically) attempts to move off-board to the back, on-board front-left, and on-board front-right before sliding forward.

[R?fR-isR] for a hook mover limited to the forward quarter sector.

So, mission accomplished for the second leg being shorter than the first; [R?isR-fR] can make the second leg longer than the first. That's what I was asking about. Adding [R-isR] can make them "equal to or less/greater than." (Or, [R?fR-isR?fW] for "less than or equal to," and [W?fR?isR-fR] for "greater than or equal to.")

That's certainly good enough for me.

On an entirely different note, what do you think about inn (or perhaps ine) for "initial lame move, not subject to en passant"?

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).

I was thinking that this would be a good Case Study for the page. Also, I had the thought that (yafoabyas)4B might allow for a full rectangle on a square board (or omitting the 4 to allow unfettered reflecting on a rectangular board), but that doesn't appear to be the case.

It seems to me it can already be expressed by inserting an extra slider leg in the same direction for making up the difference.

I don't see how you can express a shorter leg like that. I was thinking of something like dabaubR where each successive leg should not be longer than the previous. The only way that seems possible now is to do every possible combination of different numbers of W steps. But you understand it all better than I do

Another idea that's probably also too unusual to matter is to allow repeated p modifiers in a single leg so i could be applied to a move that hops over multiple pieces.

I don't see how you can express a shorter leg like that. I was thinking of something like dabaubR where each successive leg should not be longer than the previous. The only way that seems possible now is to do every possible combination of different numbers of W steps. But you understand it all better than I do

I don't think dabaubR is quite what you're after; the u should come before the d, if you want your Rook-like piece to move a friendly one. What you have there would simply make the friendly one disappear, and then move any enemy piece it captures at the end to an earlier point in its move. The effect you're after there would be more like uafafdaibR -- the first move forward sets the landing spot for the other piece, the second sets the landing spot for the moving piece, the third picks up the other piece and transports it to the landing spot, and the backward move puts the moving piece at its landing spot.

(Sadly adding entirely new modifiers will be difficult, as only the letter w is still unused.)

Actually, t is also unused. (But that only helps a little.)

Aside: I like the increasing use of punctuation here. So far I can find ()[]-?*', with a proposal for :; I'm not sure what's still available, though. At least +{}"`, I'm pretty sure, and I'm guessing at least most of \|@#$%&!, should anything more be needed that punctuation would cover. (I can't think of anything right now, though when certain new things are implemented I probably will).

Addendum: After a couple of hours, I thought of something. There probably should be some way to indicate that the same set of modifiers applies to multiple atoms; that would be handy for when that's being done with especially long modifier strings and/or several atoms. The simplest might be to enclose the atoms in parentheses, though putting a pipe (| sometimes used to mean "or") or double-quote (", sometimes used as "ditto marks," meaning "same as before") could work too. So (giving a more or less random example) while a (0,1)-Zigzag Nightrider is Nabl(abz)N, doing the same with a Buffalo, which would now be NCZabl(abz)Nabl(abz)Cabl(abz)Z, it would be NCZabl(abz)(NCZ), NCZabl(abz)N|C|Z (which would be my choice), or NCZabl(abz)N"C"Z.

(I'm not expecting that next week, or anything. It's just something to ponder.)

I wanted to reserve @ as atom for indicating dropping. Single or double quote behind a modifier was proposed for friend-only or foe-only (e.g. on p). For grouping of atoms I would use braces {} rather than overloading the parentheses. But  I like the double-quote idea better (except that I would use &, as I thend to interpret quotes as suffixes of the previous symbol), as meaning 'same group of modifiers as previously'. I don't think that would be very useful in the bracket notation, though, as there will never be very many modifiers on an atom there. And perhaps it is more useful to focus on a full implementation of the bracket notation than trying to keep the a notation bearable through all kind of quirky tricks.

And one can also look at it this way: an unwieldly Betza notation is a very useful 'red flag' to indicate you are attempting to do something that you really should not do. The complexity of Betza notation reflects the complexity of conceiving the moves when playing, and perhaps that is a good thing.

I was thinking of something like dabaubR where each successive leg should not be longer than the previous.

If I understand this correctly that means a Rook that relocates the friendly piece at the end of its extrapolated move to any of the squares it passed over. Requiring a certain order of the intermediate 'transition squares' is difficult for back-and-forth movement, but comes automatic when you always move in the same direction. E.g. the Valkyrie in Odin's Rune Chess is basically a simplified version of what you use here, which can ony relocate a piece on its destination. Rather than first picking off the piece, and then moving back to the point where you want to unload it, (which would require length restrictions to not overshoot the origin), I described it as first moving to the unload square, and then continuing to the target ([Q-udQ] or  afudQ). That automatically guarantees the unload is between origin and destination.

So in the case you describe you could at least first move to the unload square. Unfortunately there is no such freedom for the destination; this always has to come last. So you would get an m slide to the unload square, fud slide to the piece that should be relocated, and then an m slide back to the destination. The 3rd leg should be shorter than the 2nd, which you can enforce by making the last leg an i leg, and split the 2nd leg into two: [Q-uQ-dQ-ibQ] or afuafdaibQ. Another way to look at that is traveling origin - unload - destination in the same direction (to enforce the order), followed by a friendly rifle capture in that same direction.

(I think that this is what Bob had in mind too, but he wrote the u in the wrong place.)

I found an interesting method of applying a on the wikipedia page of Ko Shogi, where for example a4 means "up to 4 times", thus KaKaaK would be rewritten as a3K. You could also add an ! to indicate that it must use that exact amount of step, no more, no less. a!5W indicates exactly 5 Wazir moves
Note : In the context of Ko Shogi these multi-steps are allowed to capture a piece on every step, maybe we should do ac3 or another punctuation to indicate multi-capture or something else. This also means that a1 has no definition and a is a2. Edit: The new a, if it were to be defined as a2, would be defined as a combination of the old a and non-a move, which may be weird and or difficult to implement. The old a would be a!2

With this aa is opened up and i think a good idea for what it should be is "as many times as you want", based off the doubling of leaper atoms, which gives us the notation of the Dabbabante and the Ubi-Ubi, being aaD and aaN respectively

You can already shorten KaKaaK though by 1 character by writing (a)2K. Dabbabante is (mpaf)D.

Well, what you propose is not backward compatible with what we have, so that rules it out no matter what. I think repetition through parentheses is more flexible than on individual modifiers, and can achieve the same thing. KaKaaK can already be written as (a)2K, and if all steps should capture as c(ac)2K, or (ca)2K if the last step does not have to capture. Exactly 5 Wazir moves can simply be written out in full aaaaaW. The Ubi Ubi can already be written as (a)N.

But I want to get rid of the a notation (which was the core of XBetza), which quickly gets very obscure. And the need to express everything with a single atom is often very cumbersome, requiring many mp intermediate steps for what really is a single (but incommensurate) leap. The bracket notation, which is somewhat similar to a very old proposal that I called Betza 2.0, would solve all that. But I never think there was any formal specification of it, which should be a first step. So:

Betza 2.1

All extensions of XBetza apply, except that the a modifier is not used for chaining, y does not exist, and g exists only as legacy from original Betza notation (i.e. in a single-leg move describing a grasshop).

Complex moves must be surrounded by brackets [ ]. Within the brackets there can be a number of simple Betza move descriptors, each describing a leg of the move. These can be separated by hyphens - or question marks ? . The meaning of a question mark is defined as

[A?B] = [A][A-B]

The hyphen indicates chaining: the legs must all be made one after the other, the next one starting where the previous one ended, each satisfying the conditions that their Betza notation specifies. The default mode for non-final legs is m. This doesn't exclude the leg descriptions from being compounds:

[A-BC-D] = [A-B-D][A-C-D]

Directional modifiers in continuation legs are interpreted relative to the preceding leg, where f is default, and means "as much in the same direction as possible". Since legs need not use compatible atoms, it is not completely trivial what that means. So to be more specific:

• Diagonal after diagonal and orthogonal after orthogonal: f = exactly the same direction (W system).
• Diagonal after orthogonal and orthogonal after diagonal: f = two moves, deflecting 45 degrees (F system).
• Orthogonal after oblique: f = in the direction of the longest orthogonal component (W system).
• Diagonal after oblique: f = in the same quadrant (W system).
• oblique after diagonal: f = two moves in the same quadrant (N system).
• oblique after orthogonal: f = two moves closest to that orthogonal axis (N system).
• Oblique after oblique: f = in the same octant (K system).

The use of an 8-fold radial (pseudo-)atom like K or Q after oblique might result in undefined behavior, unless all directions are allowed. After diagonal or orthogonal atoms these use the K system, with f is in exactly the same direction.

In this system a is a new directional modifier for use in continuation legs, meaning "all directions, except to squares that were already visited earlier in the path". And 'the path' is supposed to also contain the square of origin.

The bracket notation always specifies completely (i.e. 4-fold or 8-fold) symmetric sets of moves. If the use of compound legs allows non-congruent paths, each such path will be included in all its orientations (including reflections). That means directional modifiers on the first leg are not allowed. To define a subset of these moves, directional modifiers should be placed before the brackets.

Paths that completely stay on one diagonal or one orthogonal will be considered of that symmetry; other paths are considered oblique. Directional modifiers in front of the brackets will be interpreted in the symmetry class of the trajectory that is subject to it. For oblique moves the direction in which the path first steps of an orthogonal or diagonal determines in which of the two adjacent octants it belongs. E.g. for a Ship, the symmetric move set is that of a Griffon ([F?R]), and the first oblique squares on its allowed paths are that of the narrow Knight (vN). The Ship is thus v[F?R].

Consequence: describing trajectories of different symmetry in one bracket notation can be asking for trouble if you want to make a selection. If you write fr[R?sR] the brackets describe both orthogonal and oblique moves. For the Rook moves fr means forward or right, but for the hook move it means the forward one of the rightmost pair, which would be first right and then forward.

Prentheses can be used to indicate the text they enclose can occur zero or more times; a number behind the closing parentheses indicates the maximum number. E.g. [(pR-)cR] is a Rook move that must capture, but can hop over arbitrarily many occupied squares to do so.

Burning: trajectories of 'flames' can be appended as extra leg(s) within the brackets, separated from the real move by a semicolon ; rather than a hyphen. The piece would in any case end up in the destination specified by the last leg before the semicolon (to which the rules for a final leg apply). From there any valid move of the burning spec (interpreted as continuation legs of the move, as far as directional modifiers and i legs go) would then burn its destination. E.g. [Q;cK] would be an Advancer, burning the square just beyond the one where it stopped, [Q;acdK] would burn all pieces (friend and foe) adjacent to the destination, [Q;ibQ-cK] would be a Withdrawer, and [R;ap'D-bcW] would be an Ultima Pincher Pawn if p' indicated friendly hopping.

Planar moves: (proposal) these could be indicated by two moves within brackets separated by a period. The meaning of [A.B] would be that any move consisting of zero or more repetitions of a move described by A and a move described by B would be valid if any move with a smaller number of such repetitions of A and/or B would end on an empty square.

I think that's a good use of @, ', and ", and your note about quotes looking like suffixes is a part of why I prefer | for the "or" function -- & would be (or at least look like) more of an "and" function, like trying to make an alternative to bracket notation.

And consider my Grandmaster Mage, currently notated as ooKooCooZooudcKooudcCooudcZaooxKaooxCaooxZ. (I probably can delete the first triad, perhaps with an m in t he second, and the last one may need another oo, but that's irrelevant here.) It would be much shorter with (treating the other string as though it's correct) ooK|C|ZooudcK|C|ZaooxK|C|Z, which is less than half as long.

A thought on ' and " on p (and presumably g): Doing this would still leave those marks open for similar but different meanings ono other modifiers. I have no ideas on what such meanings could be; I just thought I'd point that out.

Aside: Long-term, I'd like to eventually see ! used as an atom suffix for "not when under attack," and !! for "only when under attack." But that's admittedly a fairly low priority, since at this time the Chicken Pawn is the only piece I'm aware of that would use it (maybe the Anti-King and/or Orphan).

Dabbabante is (mpaf)D.

Thanks for that! I was trying to figure it out a while back, and here's the very obvious solution.

I wonder what (mpaf)A would be. Elephante? Then (mpaf)S could be Alibabante....

I think that this is an excellent documentation for full bracket notation, but for two or three quibbles.

One is a typo: in the paragraph on Burning, you say "color" instead of (the first time of) "colon." Also, I'd wonder whether directly backwards is part of the default, or would have to be added.

Second, while that's a dead-on explanation of a as used in this context. I think it's worth mentioning that a(b) or ab can be used for any direction including exactly backwards. (My experience is that for former works, but not the latter.)

About planar moves: This needs a clearer explanation of what a planar move is. Besides being convoluted (for brevity, no doubt; "Hello, Mr. Kettle"), the description there doesn't match up with the explanation that I recall being given to me. Also, this might be a better use of & (as referred to in another Comment) as being both more visible and (arguably) more intuitive than ..

PS: The Ubi-Ubi as (a)N is pretty simple, though it does seem to overwhelm the system (at least, on my computer, which is particularly powerful).

(I think that this is what Bob had in mind too, but he wrote the u in the wrong place.)

Guilty on both counts! :)

Something just occurred to me about punctuation in the notation. How would : (for burn moves) interact with the use of colons in Interactive Diagram coding?

Ughh, that would be a problem indeed. Better use a semicolon for the burning then.

Also, I'd wonder whether directly backwards is part of the default, or would have to be added.

Good question. It makes less sense to exclude it here. OTOH, normally this square has to be empty, or it would have blocked the move. So it only becomes an issue for a burning Grasshopper move. As it seems quite unlikely anyone would use that, there seems little harm in excluding it. Just for uniformity with other continuation legs. It is easy enough to add it through ab, while it would be very hard to exclude it.

the description there doesn't match up with the explanation that I recall being given to me.

Well, I tried to generalize it. But I think I blew it, because I was thinking in terms of steps rather than moves when I wrote it.For the conventional 'orthogonal planar move', which we would write here as [vR.sR], the point is that the steps set up a grid (in this case containing every board square), and that you only have to consider what is on that grid. But (on an empty board) every square of the grid could be reached by zero-or-one move of the first kind plus zero-or-one move of the second kind. The area spanned by the move (which must be empty) consists of all squares that could be reached by fewer or shorter moves of both kinds.

I used the dot because I saw it as a multiplication. A comma could also be suitable, if you see it as coordinates.

The Ubi-Ubi is of course a sick piece. The problem is that the current implementation of the I.D. tabulates each angular realization of a given move, and for multi-leg moves that can freely change direction that quickly explodes. Even the Tenjiku area move, (a)2K, produces some 500 trajectories.

Good question. It makes less sense to exclude it here. OTOH, normally this square has to be empty, or it would have blocked the move.

Not if the move is a leap. Imagine, for example, a Flame-ingo with [CX;KD].Or, probably more to point, a piece with K[T;K] -- or should that be K[T;abK]?

Well, I tried to generalize it. But I think I blew it, because I was thinking in terms of steps rather than moves when I wrote it.For the conventional 'orthogonal planar move', which we would write here as [vR.sR], the point is that the steps set up a grid (in this case containing every board square), and that you only have to consider what is on that grid. But (on an empty board) every square of the grid could be reached by zero-or-one move of the first kind plus zero-or-one move of the second kind. The area spanned by the move (which must be empty) consists of all squares that could be reached by fewer or shorter moves of both kinds.

Yeah, I was thinking Rook/Bishop when I was reading it, not Wazir/Ferz. This explanation is much better, and reflects what I recall.

I used the dot because I saw it as a multiplication. A comma could also be suitable, if you see it as coordinates.

I'm actually seeing the planar move as a simultaneous two-way move; that's why I was suggesting the ampersand. (Another symbol that makes sense to my brain is the slash -- though it's also one that I think would probably confuse the computer!)

Not if the move is a leap. Imagine, for example, a Flame-ingo with [CX;KD].Or, probably more to point, a piece with K[T;K] -- or should that be K[T;abK]?

In the former the burn would go to all 12 squares, as none of the KD steps is perfectly aligned with CX. In the second case one of the moves would go exactly in the backward direction. Although it doesn't seem a disaster having to write ab, I guess it shows that there really is no reaason to forbid moves with another stride. So I will change the definition to that it should not go back to the previously visited square on the path.

That reminds me that in XBetza at some point I defined it as not being allowed to return to any previously visited square, to prevent that aaK could make a turn pass by triangulating. Of course this was pretty much unimplementable. Now as the Ubi-Ubi (which basically has an unlimited-range area move with Knight steps) shows, area moves really need a dedicated generator if you want to treat those efficiently. (As is very important for the AI.) There is just too much overlap between them. (a)2K has 456 possible realizations, but these reach only 49 squares. So each move is generated some 9 times on average. A good algorithm would be to tabulate first which squares you can reach in one step, and then from all of those take another step to tabulate those you can reach in two steps, eliminating duplicats at every stage.

-King can't castle when in check in Chess

-King may not move out of check, except to capture its singular attacker in Makpong would be !mKcK.

-Vaulting Camel-King from fairy chess problems would be K!!C

-Transmuting King from fairy chess problems (King but when it is threatened, moves only like the threatening unit(s) (!K+Orphan))

-Tengu pieces from MAD Chess

-etc.

I am not sure that rules like this would qualify as being part of the move. Betza notation is supposed to describe the pseudo-legal moves of a piece, and that some of those might be forbidden in a real position because of the constellation of pieces outside the path, is what makes the difference between legal and pseudo-legal moves. Moves of pieces in a variant that has a checking rule are not written differently than in a variant that hasn't.

A rule for not being allowed to move out of attack can be implemented in the AI relatively easily: you test for in the reply move whether you can capture to the evacuated square. This is how the ban on castling out of (or through) check is implemented to. The AI is not aware it is in check, but on castling it marks the King's origin and passed-through squares as 'royal' e.p. squares, and considers any capture-capable move to it in the next half-move as an (immediately winning) King capture.

Moves that are only allowed when you are attacked are much harder to implement. They are a form of enemy induction. (Which the I.D. also doesnt't implement for that reason.)

So I will change the definition to that it should not go back to the previously visited square on the path.

That, I think, would be the ideal. :)

A good algorithm would be to tabulate first which squares you can reach in one step, and then from all of those take another step to tabulate those you can reach in two steps, eliminating duplicats at every stage.

That can be great, though sometimes where a piece can move from a square depends on where it came from. With a Rose, for example, any square that can be reached in 2 or 3 steps has two ways of approaching (unless blocked), and each of those two ways has a different allowed exit -- four if the Rose is allowed to go full circle. Some complex bent sliders, the Combine being the most common, also have overlapping moves. The algorithm would be perfect for pieces like the Ubi-Ubi or Shogi area movers, and probably would also improve regular radial sliders and oblique riders (especially those with cannon, grasshop, or juggernaut moves), but there should be some way to allow for "this way in, that way out" (like ignoring the elimination of duplicates after a turn modifier is encountered).

Moves that are only allowed when you are attacked are much harder to implement. They are a form of enemy induction. (Which the I.D. also doesnt't implement for that reason.)

I actually was thinking that it could be something that the new off-site AI you mentioned being in the early stages of working on might be able to manage. And HaruNY did point out a few other cases where the rule is used.

It's something to consider, at least, as you're building said AI engine. :)

Somethings i want to note and some ideas

• gK should be able to be written as [jS?Q] but the latter moves completely different
• gQ4 i expected to be a grasshopper, not a lion, limited to 4 tiles in total, the case of up to 4 tiles after hurdle can be constructed using square brackets [gQ?Q3] (i think, doesn't work in the diagram on the page)

• h on it's own has no definition, something like relative half, from the halfling, could work
  • This does make left-only half impossible as lh and hl already have a meaning, you could use a punctuation like a comma , to seperate them so that the compound doesn't work, with this , you can make a move that's initial and non-leaping, but does not create e.p. rights i,n
• t could be used for checking if there's a piece there, adding c or d to specify enemy or ally piieces

I think a nice feature would be to allow multiple platforms for cannon like pieces. Personally as I don't like the idea of bishops in a Xiangqi or Janggi environments I'd like a pRppcR instead (where pp stands for 2 platforms). Some food for thought.

@Aurelian: What do you call "platform"? Do you mean the "screen", as defined in https://www.chessvariants.com/piececlopedia.dir/pao.html?

Bracket notation is a proposal for future improvement, and basically not implemented. A few cases representing commonly used pieces such as Griffon are recognized, and handled by a pre-processor that substitutes the corresponding a-notation. The S is apparently not amongst the recognized cases. (This might be easy to fix.)

Range limits on hoppers has always been a problem in XBetza, because you would really need two ranges: one for before, and one after the mount. The rules for range toggling (triggered by g or y) are such that the specified atom + range count for the first leg, that finite range turns into infinite, and infinite into 1. So gQ4 means up to 4 steps to the mount and infinitely many behind.

Bracket notation would solve this, by allowing you to specify a range in each leg. But it is not implemented yet.

Reusing an existing symbol has little advantage if you have to introduce a new symbol to resolve the ambiguity it causes. IIRC 'halfling' is a (flexible) range specification, so it would be more natural to indicate it as a (non-numeric) suffix than as a modifier prefix. I would suggest the % sign, as the actual range should be a fraction of the free path. We could even give different meaning to W% and R%.

As a symbol on its own checking for a piece is already done by p. If a combination of symbols is to be used for specifying whether it should be friend or foe, I'd rather use p' and p" than a t. The quotes could be used to diversify other modifiers as well. E.g. c' could be friendly capture, and c" friendly or enemy capture. Than d could be retired.

Indeed, screen = mount = platform. Two platforms you can already do by [pB-pB-cB] or pafpafcB.

gafQ3

I like that idea for the %. It's actually quite intuitive for the symbol's conventional meaning. The only question is, what effect would that have on a Rook on a rectangular board? If the board is 12x16, would the half-Rook move six spaces sideways and eight spaces vertically? (That actually would make the most sense to me.)

As for using ' and " to "retire" d, I think the letter would have to be retained for backward compatibility. Otherwise, I think we'd have freed the L and J atoms by now. (I personally would welcome seeing all three characters freed up for potential new uses -- like, an atom for Bison (CZ), mainly for use with Cheetahs, Sabertooths, and related pieces, which I wouldn't try to do with the smaller number of free atoms we have right now.)

On a (mostly) unrelated note, I'm finding trouble when I try to put more than one pair of parentheses into a move, whether nested or sequential. For an example of the latter, I've tried expanding the Springer's pya(b)K move so that it can bounce off more than one target, but pya(b)(pa)K (or even pya(b)(pa)2K) doesn't yield anything but an error message ("No atom at end").

PS: With some experimentation, I've found that shQ and shK yield "all directions except forward and backward," while vhQ and vhK yield "all directions except left and right." I just thought I'd point that out; I think it'd be worth documenting. :)

I'm trying to build a piece that moves like a normal Rook, and then, if there's an empty square in the next space forward and an enemy piece in the next space beyond that, pulls the enemy piece into the empty square. I'm still a bit inexperienced with u, but it seems to me that the bracket notation should be built thus:

• The basic move, R
• The rest is optional, so ?
• The next space is to be a destination, so ufW
• Then capture the enemy piece in the next space, so -cfW (said enemy will then go to the first space)
• The jump back to where the Rook move ended, so -bD

But when I try [R?ufW-cfW-bD] out in the Sandbox, the enemy piece and moving piece just end up in each others' places. I'm not sure what I'm doing wrong here.

Well, bracket notation is currently only implemented for two-leg moves: it tries to reduce those to a commensurate atom, and ignores all later atoms, except their leaper/slider nature for determining if a y should be inserted. So when it works it is basically coincidence.

If you assign a new move to another piece, you can see which XBetza the preprocessor produced from your bracket notation. Which in this case is: RyafufafcfabR . So you see it did understand that the move could end at R, and it did understand there were 4 legs (3 as), it did understand it had to switch from slider to leaper after the first leg. It got a bit confused about the directions, because you added an f where no f was really needed, because that is already default. And you did that after a mode modifier (while I always do directional modifiers first), so that it did not notice it. Hence it adds a redundant f before the u and c. But I don't think that would hurt. It did understand that two continuation legs were f, and the 3rd b.

What it did not understand is that the 4th leg was D. Because it never looked at it, other than classifying it as a leaper, so that it should not toggle back the W to R. So it was close, but no cigar...

This might never be possible, but I wonder if there could be a way to specify a piece that captures like a cannon, but both parts of the move—before and after the mount—must be the same distance, and there can be any number of other pieces jumped over on the either leg.

This would indeed be hard. One way I could see it done was introduce a special symbol as repeat limiter similar to what i does for slider continuation legs, and thus means "as many repetitions as there were in the previous parenthesized group". Suppose that symbol is $, you could write [(mpW-)pW-(mpW-)$cW]. It is a sort of orthogonal Equihopper.

OK, so the bD should've been bpaW (or bpafW), and I should've realized that. Grr.

But now I've tried [R?mW-ucW-bpafW] and [R?uW-cW-bpafW] and various other combinations thereof (both with and without the f), and I still don't get the desired effect.

This would indeed be hard. One way I could see it done was introduce a special symbol as repeat limiter similar to what i does for slider continuation legs, and thus means "as many repetitions as there were in the previous parenthesized group". Suppose that symbol is $, you could write [(mpW-)pW-(mpW-)$cW]. It is a sort of orthogonal Equihopper.

I like this idea, and the choice of symbol. I can see it being useful for a number of different possibilities (like maybe a bent or hopping rifle capture).

[R?uW-cW-bpafW]

You are mixing XBetza with bracket notation. You cannot do that; a in bracket notation would mean 'all directions', not continuation. You should have written [R?uW-cW-bpW-fW].

But your original [R?ufW-cfW-bD]  is wrong in the first place. It specifies an unload on the start square of two consecutive W steps, and then a D step back. Which would end up on the same square as the unload. What you really want after the Rook move is step to the unload square (fmW), from there swap with the enemy piece (fucW) and step two back (bD). That is [R?W-ucW-bD]. (But note that this makes the attarction of the enemy piece optional; it could stop after R even if there is an enemy piece two steps further.) The D step would have to be split up in XBetza, and not being a 2nd leg the bracket preprocessor won't do that automatically. But it probably would handle [R?W-ucW-bpW-W] correctly.

It may not be neccesary, but we could expand the set of allowed symbols, currently we have;

• Letters, upper- and lowercase, Numbers and Punctuation, may use shift

We could expand to use symbols like í, þ and £, which are all available on a regular keyboard, the special i's could get used for various "cases" of initial, removing the requirement of ii as a special i could take it's place. Edit: Though you'd need Alt Gr for the latter 2 symbols given.

At the current point, i don't really see it happening, since we still have quite some punctuation not yet used

Edit: Could we also have grouping of symbols to make things like c(QNN) for a capture-only Amazonrider

There is no such thing as a 'regular keyboard'. Each country has its own national version, and that you happen to have these symbols, doesn't mean that others have them. (Have you ever been in Taiwan?) I do have í on my PC, but not on my laptop.

Grouping of atoms was also proposed by Bob (in various forms, either by enclosing them (and then I would not use parantheses but braces { }), or by connecting them with some infix operator like |.

See, I knew I was getting the u wrong somehow! And I didn't think about the a in bracket notation being different; botching that, honestly, is me all over.

Trying out your bracket notation (I think I'll start calling it BBetza, for Bracket Betza) in the Sandbox, though, it still doesnt work, beyond the R. If it helps, it translates (exactly as I'd expect) to RyafafucabpafR.

It's not incredibly important, though; I was just planning ahead half of a Burn (afafucabpafK) for when the use of the colon is implemented. (The other half, I think, would be apfafucbafK -- to push a friendly piece adjacent to the landing square away to an empty square beyond.)

Thanks for the help on that. :)

There is no such thing as a 'regular keyboard'. Each country has its own national version, and that you happen to have these symbols, doesn't mean that others have them. (Have you ever been in Taiwan?) I do have í on my PC, but not on my laptop.

I think the only place I'd allow characters outside the ASCII standard, such as letters with diacritics, would be as atoms in connection with the custom moves that we've discussed before. Even then, I'd limit it to the capitals in the ANSI/Windows-1252 set (À to ß, skipping × but possibly also including Š, Œ, Ž, and Ÿ). I say this in spite of the fact that I can think of specific uses for several other characters on the lower half of the Windows-1252 table, as modifiers.

Examples of what I personally might assign to those letters include Ø as a null move, Þ for a Rose, Ñ for Quintessence, and Ê for Edgehog. (Maybe even Ä as Aanca, as a Griffin/Manticore compound that could be broken down into orthogonal or diagonal.) But, again, I'd build them as "custom moves" (though I'd also make the code easily available to others).

While recently working on a particularly weird chess variant with a very odd board, it occurrerd to me that I'd set up certain elements in such a way that, under certain circumstances, a rifle capture might not be able to return the way it came, even if it was a simple diagonal slide (caibB). This was a product of the quirky board I'm using, so I didn't think of it much, but then it occurred to me that some more mildly exotic cases could face the same problem -- a grasshopper rifle capture, to give a simple example.

So, it made me wonder if there could be a way to mark a point in a move, either replaccing or supplementing u, as a point that the piece later comes back to.

I don't think this would be worth using the w or t for; save those for cases with multiple uses. So, punctuation... I recently suggested ! as an atom modifier for a move being possibly one if under/not under attack, but to my eye it's the character that looks most like a bookmark, so it could be used either following u (which would be my preference) or preceding a to "bookmark" the locatioin for later. Then, for going back, follow a with ~.

You may have a different preference for marker(s), and of course there's no rush on this (the above-mentioned CV couldn't use an ID anyway -- though I'm thinking of something with a bent rifle capture on a more traditional board), but I just thought I'd see if I could get some creative gars turning.

So, it made me wonder if there could be a way to mark a point in a move, either replaccing or supplementing u, as a point that the piece later comes back to.

I wonder if that could be done by having something to indicate self-capture. That could also be used for pieces that self-destruct without unloading.

I wonder if that could be done by having something to indicate self-capture. That could also be used for pieces that self-destruct without unloading.

That would have to also mean without capturing, since self-destrictive capturing can be indicated with a kamikaze move (0 on the captureMatrix). And I think that such a thing should be a modifier directly on the atom, or to the last leg -- though the ~ that I suggested could do the trick.

I don't see the problem of not being able to reverse the leg. Betza notation is for boards with a translation-invariant 8-neighbor topology, and that it would not work for other boards is normal and unavoidable.

If a modifier for self-unloading was necessary, I think that u' would be the obvious choice.

I don't see the problem of not being able to reverse the leg. Betza notation is for boards with a translation-invariant 8-neighbor topology, and that it would not work for other boards is normal and unavoidable.

As I said, if the issue was the weird board, than it would be a non-issue. The problem is if the approach path is something like yasfR or y(a)5K (both of which I actually would use; in fact, yasfR is what made me realize that the problem wasn't limited to weird geometries.

If a modifier for self-unloading was necessary, I think that u' would be the obvious choice.

It doesn't seem obvious to me, but that's probably just me.

Then a marker for where the piece "captures" itself, both for this purpose (the "load" spot won't always be the end) and what Daniel brought up would be needed; I suggested the tilde (~) because it's not likely to be needed for anything else, but a` could make a nice counterpart to u'.

This i find a very good idea, 31 new symbols, but we could also use the lowercases for 31 new symbols for modifiers, like the different i's for different cases of initial, so that ii is not needed, for I maybe we could use different Imitators.

Examples of what I personally might assign to those letters include Ø as a null move, Þ for a Rose, Ñ for Quintessence, and Ê for Edgehog.

I like these ideas, outside of Rose, since they couldn't be (easily) written otherwise, we could do like ê as the Edge-Modifier (and possibly ë as the Limited Edge-Modifier). We'd also may need a symbol for relative halfling, i originally thought a lone h, but maybe one of these Windows-1252 symbols works better

yafsR should be no problem (yafscabyaifzR). y(a)5K is not valid XBetza (as it includes yK), but I suppose you mean some kind of area move. If there is more than a left-right choice it is indeed not possible to retrace the path using q and z. This could also be solved by a new directional modifier that would do what i does for the range of a continuation leg: mimic a previous deflection.

It doesn't seem obvious to me, but that's probably just me.

Well, you unload something that disappeared elsewhere. And if p' means friendly hopping, it seems natural to make u' mean friendly unload, i.e. that you don't unload the captured piece, but the moving one.

(the "load" spot won't always be the end)

I don't get that. A moving piece would always have to follow the entire trajectory; that is the basis of XBetza  notation. So how could it end up anywhere else than at the end?

This i find a very good idea, 31 new symbols,

Well, I don't know. The success of Betza notation lies in its simplicity. The meaning of most modifiers is obvious (f, b, l, r as directions m, c as move/capture), and for those who are slightly familiar with unorthodox pieces, most atoms as well (standard symbols for orthodox chess pieces, plus W, F, A and D). Perhaps they have to learn a handful of other symbols (v and s, but outside Shogi pieces tend to be fully symmetric, and directional modifiers are only very rarely needed in the first place, p and g.)

Having to know the meaning of '31 new symbols' pretty much destroys that. There is very little benefit in introducing symbols that hardly anyone would know the meaning of.

yafsR should be no problem (yafscabyaifzR).

I had no idea that the i could be that far separated from the long move it's supposed to imitate.

Look out; here comes the Boomerang!

y(a)5K is not valid XBetza (as it includes yK), but I suppose you mean some kind of area move. If there is more than a left-right choice it is indeed not possible to retrace the path using q and z. This could also be solved by a new directional modifier that would do what i does for the range of a continuation leg: mimic a previous deflection.

I realized that it was invalid when I reread it a bit ago. It should've been ya(a)4K -- a King move, followed by one to five Queen moves (that's a simplified version of what the piece I had in mind would do; each leg would be a p, and the end a c -- I just didn't want to mess with calculating that aspect of it).

Well, you unload something that disappeared elsewhere. And if p' means friendly hopping, it seems natural to make u' mean friendly unload, i.e. that you don't unload the captured piece, but the moving one.

That's quite logical and reasonable. Still not "obvious," since p' isn't actually implemented yet, but it definitely makes more sense now than my suggestion of an exclamation point.

I don't get that. A moving piece would always have to follow the entire trajectory; that is the basis of XBetza  notation. So how could it end up anywhere else than at the end?

Take the Drive-By sliders that I posted very recently as a starting example: they move normally, but do sideways a rifle capture  somewhere along the path. Now imagine that, instead of a one-space capture, it went up to five spaces, turned 45°, and went up to three more spaces, and then optionally makes another 45° turn for up to 2 spaces, calling for u' and a~. to trace the rifle capture. The piece moves, makes the "magic bullet" rifle capture, and then continues moving.

Like I said, a rare enough occurrance to make it low-priority, but probable enough to make it an eventual reality.

Also, on the topic of just the u', the Lariat in Zwangkrieg isn't working as intended (I can explain again next week in a Comment on the game's page if need be), and this could work well in helping fix the problem.

Well, as I said, I don't think I'd make use of them in the main XBetaa/BBetza universe. Allowing their use for custom moves, once that is available, is the furthest I'd go with it. The ideas I cited for specific symbols are just examples, which I'd (at least hypothetically) code myself and make available to others. Others could also assign different effects to a given symbol; unless something really catches on, there'd be no standardization. The symbols wouldn't be used as part of any standard description, but only in specific games.

Actuially, of the four I listed there, only the Edgehog is a big challenge in XBetza. The null move is mpabK, the Rose is qN, and the Quintessence is zN. For just about anyone (myself included) the XBetza is actually much easier to type than the special character, unless I'm doing something weird with it like turning it into a rifle capture. (A "Rifle Rose" may be as simple as qcaibN -- I honestly don't know, or have time to check it out right now -- but I'd prefer caibÞ.) And anyway, those are just off-the-cuff examples.

I'm curious, though: Why not use the thorn (Þ) for the Rose?

A "Rifle Rose" may be as simple as qcaibN -- I honestly don't know, or have time to check it out right now -- but I'd prefer caibÞ

Here's an idea [c[qN]-ib[qN]]

or even [c[qN]-ib[]] with the empty brackets applying the ib modifiers to the previous bracketed path.

h on it's own means the same as b for orthogonal atoms.

I tried your idea, and mine, and a few others, and nothing worked. I have a feeling that if any existing XBetza does work, it'd be more hassle than just entering caibÞ considering it'd be just once, with Þ still available for an unaltered and/or differently-altered Rose. Þ7 can be one that doesn't go around the full circle, Þ3 only goes to the far rim, hrÞ only goes clockwise, [Þ?R] is a Rose-Rook bent slider... the first two are pretty easy with existing code, the second might be, the last I'm not so sure.

But of course others could do it their own way, and even use Þ for something else entirely. (No remembering required!)

That only happens with R and W, not with any other atom. And I'm not sure even that much is deliberate.

The q and z modifiers cannot be used in their original Betza meaning of circular / crooked in a multi-leg move. Their meaning in the latter context has been redefined as a directional modifier meaning the same as l or r, but in the same or opposit direction of deflection as the previous one.

The circular and crooked moves were hard to fit into the scheme according to which other moves are handled by the Interactive Diagram. I added a special case of move generation just for those, where a tabulated sequence of legs of a multi-leg move doesn't have to be traversed in its entirety for the move to be valid, but is allowed to stop at any point along the trajectory. This can be combined with (grass)hopping; normally the trajectory would not continue after an occupied square, but would exercise its c or d right there. But in combination with p or g it must continue on the first such encounter, in the latter case exactly one leg. Continuing after capture, or on any other path than the indicated circular/crooked trajectory is not implemented for this type of move generation.

The introduction of parentheses in principle would allow specification of circular and crooked paths in the context of normal multi-leg move generation. But the way parentheses are implemented is very inefficient, which especially hurts the AI. In theory (af)W is the sane as R, but in practice it is expanded to WafWafafWafafafWafafafafW..., which is WnDnHnWXnDX..., a squence of ever larger lame leaps. And for each next leap it will test all squares leapt over, even though the previous lame leaps already tested those. So if the W and D leap in a certain direction are valid non-captures, but the H leap is blocked, it would still try to generate thw WX, DX... leaps, and test the W, D and H squares they pass through for each of those, before coming to the conclusion that these are not possible. The special case of storing only the longest trajectory, and allowing termination at any step along the way, solves this problem. But it is not compatible with straying from the path.

BTW, the I.D. currently does not implement moves with more than one pair of parentheses on an atom. The implementation through pre-processing would really make the length of the XBetza string that results explode if there would be multiple pairs.

I had no idea that the i could be that far separated from the long move it's supposed to imitate.

The official definition says "as many steps as in the previous slider leg". It would never make sense to mimic the length of a leaper leg, as this is known to be 1. So intervening leaper legs are simply ignored.

It would make sense to slightly alter that definition in the case of multiple iso legs, to "the previous slider leg that is not iso itself, and has not yet been mimicked by an intervening iso leg". This is not how the I.D. currently implements it though. Which probably does make the current implementation useless for multiple iso legs, as it does something I cannot imagine you would ever want.

I completely agree with you HG. I hope those ideas will not crawl into the Betza's notation that you are developping. For me too what matters is the simplicity.

I completely agree with you HG. I hope those ideas will not crawl into the Betza's notation that you are developping. For me too what matters is the simplicity.

This is pretty much the reason I've been saying that these 31 new characters should be available only for custom moves, programmed by the game designer (or borrowed from another one). It's not inconceivable that one or two might catch on, though I'd consider it very unlikely; while I'd use Þ for a Rose, others might want to associate one or the other with something else, as I've already noted.

I actually would also consider it a headache if any of these additional characters were implemented into XBetza/BBetza during my lifetime. I previously said that I'd use Ø as a null move, Þ for a Rose, Ñ for Quintessence, and Ê for Edgehog; I could also use Ô for the Zpider's (and certain other pieces') move of tracing the edge of the board, and Ü for my Root-N25 Leaper. But I'd only actually use them, or any other extended character, in an ID if writing out the conventional XBetza was even more inconvenient, if I was doing something with it that couldn't be done in conventional XBetza, I was writing against a filesize limit, or some similar reason. A Rose would generally still be qN, but a Rifle Rose would have to be ÞcaibÞ (though it could also be qNcaibÞ).

And now that I think of it, since they'd be based on the custom move machine, I'm not sure they should be implemented for bracket notation.

You know, I prefer to say my opinion because your intention was not clear.

That my intention was insufficiently clear is, well, sufficiently clear. For that reason, I'm glad you stated your opinion so I could clarify.

Just a quick y/n question:

would pO (with other appropriate modifiers, of course) allow castling with an intervening piece?