Comments/Ratings for a Single Item

[nG?fB] does work, at least on the Play-test Applet.

OK, I see. As first leg before a step/slide (WFBR) only obliques other than N and leaps involving extenders (XY) would not work, and attention is payed to n (but not j). After a step (WF) only sliders and A, G, D, H, N and C-riders would work. And all this only in transitions between the first and second leg. Other combinations would give undefined effects. Later legs would keep the stride of the second, and can only change direction and range (1 or infinite).

Just throwing this out there; it'd be simple to do, I'm sure, but I'm not sure about how practical it would be.

Just as K is used as shorthand for WF and Q for RB, what if there was a shorthand atom for AND, and perhaps even one for HCZG? AND could be S (for Squirrel) and HCZG could be T (for Titan, since C for Cheetah is already in use by the Camel).

My doubt about it is whether they'd be used often enough to warrant the change. I know it'd shorten some things (Squirrel, Cheetah, Japanese Lion, Sabertooth, etc.... and, yes, the Berserker -- and I've even stumbled across a Squirrelrider); I don't know that it'd be worth this trouble. (But I do think that it's worth mentioning, which is why I'm doing so).

I don't think this these combinations would occur often enough to justify this. For K and Q the argument is that these are orthodox pieces, which tend to occur in almost any chess variant. It seems better to reserve the unused capitals for something that really could not be done in any other way. Possibly with the exception of P for abbreviating Pawn moves, as the Pawn is also an orthodox and extremely common piece, with an otherwise extremely cumbersome notation. If Pn is taken to mean fmWfceFifmnWn it would save a lot of trouble.

Yeah, that's about what I figured. But, like I said, it's worth mentioning.

I was perusing this for ideas for representing 3D movement* when I saw the discussion of the P atom. I support this, but I'm still wondering about the Berolina. Would yP2 do the trick? Could sP2 denote something like the Shield Pawn, which captures sideways instead of diagonally? Or bP my Anti-Pawn, which starts at the top of the board and moves backwards? (The latter two are just idle thoughts.)

*The best I can come up with so far is to use t to "turn" the board on the Y-axis, so the ranks become levels, or tt to turn it on the X-axis, so the files become levels. The board can become leveled again (if needed) by repeating the most recent one used, or with ttt. It's not a very good idea IMO, but it's the best so far. (Close behind is using the carat [^] instead of t.)

I think a move notation system for 3D should best be set up from scratch. It is not only that you need additional atoms for the non-planar moves. You would also need different directional modifiers to select subsets from those. In N dimensions a given atom can have N! 2^N symmetry-equivalent moves, so 48 in 3 dimensions.

The problem with using modifier prefixes in a non-standard way on a Pawn atom is that probably no one would understand what these mean. And that would defeat the purpose. Non-standard Pawn types (other than having a longer range for the initial move on larger boards) are used only rarely, which would both relax the importance of avoiding cumbersome dedicated notations for them, and increase the danger that people would not be familiar with the alternative.

Ah, well. It was a thought. At the least, though, PP should yield an Arabic Spear. (And I do think that the Berolina Pawn is used pretty often.)

A couple of questions about move induction using x:

1. I occasionally come across a piece that grants a move other than the one it uses to grant it -- for example, gives a Knight's move to a friendly piece a Queen's move away.

2. Negative Relay.

Are these even possible in the current setup? If they're not, don't worry much about it; I doubt that they'd be anywhere near common enough to put a lot of energy into implementing (like, say, more than about six new lines of code). I have a vague idea how the first might be doable (currently), but not so much the second.

Negative relay (I always call that 'enemy induction') is currently not possible. What makes it hard is that the ID implements induction as a move of the inducer. So to generate your own moves in the presence of an enemy inducer you would also have to generate enemy moves. Which would severely slow down the AI.

In Scirocco one of the promoted pieces induces N moves like Q3. This poses the problem in XBetza you usually have, when legs of a move use incommensurate atoms. And the usual solution is to express those as multiples of their 'common denominator', usually K steps. Q3 already does consist of K steps, so one has to write the N leg as two transparently glued K steps: xyampafsQ3. After the xQ3 leg the ya toggles the range to K for the following legs. An mp leg in the arbitrary direction followed by a 45-degree turn for the final leg add a Knight move to that.

In bracket notation this would be [xQ3-aN], but I am not sure the ID can already handle oblique after orthogonal/diagonal.

That's pretty much what I was thinking. I can experiment a bit to see if the bracket notation works, but the xyampafsQ3 is close to what I was thinking (though I'm pretty sure I would've put the x in the wrong spot).

I'm pretty sure enemy induction would have to be done as a spell, and I have no doubt that that would be more trouble than it's worth.

And I get what you're saying about the brackets; the other day I tried to use [vcD-aK] for a "sting" capture (leap two spaces forward or backward, capture, then "bounce" to any adjacent square), and the resulting behavior was very strange. I had it convert to straight strings, edited it manually until it was right, and ended up with (including a separate non-capturing move) vDvmpafcaKvmpafcabW, which works perfectly.

I am so looking forward to the bracket notation consistently working as intended!

PS: Thank you again for all your help on the Icon Clearinghouse diagram! I may request a bit more if and when I go to make it into a separate page, but for now I'm very happy with it.

Addendum: About the apostrophes (single quotes): does this work, at least well enough to put them into the move descriptions without generating an error message?

With betzaNew.js the apostrophes should work. The 'XBetza sandbox' still uses betza.js; this produces an error message when it sees an apostrophe, but then just ignores it, and continues parsing the remaining string as if it was a new atom.

I had it convert to straight strings, edited it manually until it was right, and ended up with (including a separate non-capturing move) vDvmpafcaKvmpafcabW, which works perfectly.

The vD and vmpafcabW seem to be extra compared to the bracket notation (where a also means all but back to where you came from). I am not sure K/Q after D is not recoginized as a case where it should expand the first leg into K steps, in the pre-processor for bracket notation. This is a combination that only makes sense when the second leg can freely change direction; for fixed direction you could use F/W/B/R. I am sure the bracket notation would work for those (e.g. the Snake Tongue). It could also be that the a in the bracket notation is not removed. I will have a look at it.

[Edit] OK, [vcD-aK] now works. The problem was two-fold. For one, the prefixes of the first leg (vc here) were kept in front, because they were expected to indicate the initial direction. But c is a mode modifier, that should go with the last leg of the expanded D. Only the v should stay in front.

The second problem was that the atom it picked for the XBetza description was W for an orthogonal leap like D. And although it correctly interpreted the a in aK as 'all directions', 'all' means something different for W than for K. It should have recognized K as a continuation to overrule the W or F choice. This will still give problems with complex directional specifications, though. But fortunately not here, as vK means the same as vW. But had the first leg been fA or even fsD, the directions would have meant something different on K. I haven't solved that yet. Perhaps this has to be saved for when the bracket notation can really be parsed directly, rather than through pre-processing.

I'm not sure if the Janggi cannon is supported.

I'm not sure if the Janggi cannon is supported.

It depends. Normally when someone talks about a Korean Cannon rather than a Chinese one I would assume he means pR. The rules that it can move diagonally inside the Palace, and not jump over or capture other Cannons would then just be Janggi additional rules. (The first having to do more with a peculiar board topology than with the move.)

The Interactive Diagram allows one to define a captureMatrix to make certain aspects of a move type-dependent. In particular, forbidding both capturing and jumping over a type can be indicated by a $ for the interaction of the involved piece types, while ^ would only forbid the jumping, and ! only the capturing.

Oh, so it's possible. I meant beyond the pR. I don't care about the special moves inside the palace for now. That is cool. I am curious also about if there is a way to allow just capturing after jumping 2 pieces. No locust capture.

You mean rifle capture like a (double) hopper? This is currently not possible if there are multiple slider legs involved. But XBetza currently has undefined behavior in the case of multiple 'iso' legs, and this behavior could be defined such to make it possible. The prescription then would be that the length of all slider legs in a multi-leg move is remembered on a stack, and that each i leg should do as many steps as recorded on the top of that stack, removing it from there so that the previous leg becomes top.

That way [pR-fpR-fcR-bipR-fipR-fiR] or pafpacabipafipafiR would do what you ask. But currently the length of any i leg other than the latest is not remembered.

Not a rifle capture but a korean cannon that may capture but may not move over 2 platforms. A heavy cannon let's say!

Don't worry to much about this though.

If I understand this correctly you mean mpRpafpafcR. A $ in the captureMatrix would forbid either mount to be a Cannon, though.

Ok, and I understand why. Thanks!

@h.g.muller,

thanks h.g., your new piece is cool and sleek. [[[ paf pafR ===capture target (after 2 screening ramps. ) ]]] (usually, cannon capture the first target, but this one is different. great invention and ingenuity. thanks, h.g.)

I was editing this move (mvDvmpafcaKvmpafcabW) into the listing for yesterday's piece, and had a thought about it: where a (in bracket notation) becomes "all directions but back the way you came from," perhaps aa could be "all directions including back the way you came from." That could turn the original mvD[cvD-maK][cvD-mbW] to mvD[cvD-maaK].

Why use aa when you could use ab? In Betza notation directional modifiers indicating direction sets with an empty intersection means one or the other, and a and b do not have moves in common.

Problem is that this possibility does not exist in the XBetza 'a' notation, and that currently the bracket notation is first converted to an XBetza string before it is parsed. No matter what method you would use to indicate 'all directions including back', it could not be implemented by substitution of the modifier sequence by something else; it would require duplication of the string. If there would be an independent bracket-notation parser, this would come automatically. So we should simply wait for that, and this is yet another incentive to work on it.