Comments/Ratings for a Single Item

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

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.