Comments/Ratings for a Single Item

Well, I think it is a justified complaint that it is not easy to see that there is a Rook move hidden in there. The bracket notation [smpW-sR] would make that more explicit. The notation of a full Griffin based on this idea would be [mpW-sR], and would automatically visit the F squares, as these are now reached by the first sideway Rook step. But it literally requires some 'out of the box' thinking to detour the trajectory over an auxiliary square (sW), and subsequently make that square fully transparent by giving it mode mp. And this obscures the fact that in reality the first square visited by the piece (in the sense that it can move to it or be blocked there) is an F square. That distracts greatly from the intuitiveness.

That is true, it wasn't easy to understand the bent moves at first for me for that reason, and also because it's not immediately obvious that 'a' actually applies only to the move at the end of the sequence of modifiers rather than being a connector between two different moves, and that every leg before the last is mandatory.

What about using the brackets alone to indicate that all the moves contained within are part of a sequence? [FfR] [smpWsR] You could differentiate between mandatory and optional continuations using a separator or with different symbols, such as [F+fR] and {FfR} meaning F followed by a mandatory R.

And then perhaps the whole sequence could be modified too, so what if you could do p[FfR] to get a gryphon that must jump (a grao)? And v[FfR] might work for the ship, if it's not ambiguous somehow.

Not sure what you mean by long. The "R" part? I don't see what the problem is, it is not easy by messages. "Outward" for me means the move is always in the direction of going away from the starting square both in x and y. If after the first leg, the second leg starts by going to a square that is closer to starting square either in x or y than the intermediate square (between the two legs), then it is not outward on that definition.

If the N moves goes from e1 to f3 (i.e. both increasing in the x and y dimension) then both f3 -> f8 and f3 -> h3 are R moves that neither decrease x nor y. So both fit your definition. But they are not equivalent. Probably f3 -> f8 has the best claim on being called 'outward'. One could argue that the other one is unnatural, because it crosses its counterpart that moves from e1 -> g2 -> g8, and therefore is unlikely to ever occur in any game. So that there also is no need to have any notation for it.

Anyway, I brought this up in order to show that just having one new symbol, meaning 'outward', is not enough, but that we would likely need a complete system for indicating all 8 relative directions. Which seemed worse than just using the existing system used for indicating the 8 directions relative to the player. As these new symbols would only be encountered in multi-leg moves, which are quite rare themselves, so that people would not be familiar with those, but likely think "what kind of a freaky symbol is that???".

The price for this is that these symbols would no longer be available for indicating absolute directions, though.

The Ship just happens to be one of these very rare nasty cases, because the equivalent moves of the Ferz alternately bent to the left and the right. It hardly ever happens that referring to an absolute direction is of any help. I can think of many solutions, but most of those require introducing new symbols or new meanings of existing symbols that would virtually never be used, and thus unknown to the casual user of Betza notation. I think the best way is to accept that compactnes and intuitiveness here are conflicting demands, and thus go for the somewhat cumbersome description [frblF~flR][flbrF~frR], to explicitly indicate on which starting steps there is a right bend, and on which a left bend.

A more practical problem is that the difference between tilde and hyphen is hardly visible in this font...

What about using the brackets alone to indicate that all the moves contained within are part of a sequence? [FfR] [smpWsR]

Well, for practical reasons I would prefer to have some separator between the legs. (Then I can just use the JavaScript split method to split the move in the parts between the hyphens, while otherwise this should be judged by the case of every individual letter.) I think that once you allow the brackets, allowing other non-alphabetic characters as well is no longer a problem.

The idea of considering a certain grouped sequence of directional modifiers plus atoms as a 'crooked atom', and allowing the whole group to be prefixed, does have merit, however. Otherwise you would have to specify a separate move for each leg the mount could be in to make a hopper. E.g. for the Grao you would need [pF-fsR][F~fspR] (i.e. mount either at the F square or in the Rook path). Then p[F~fsR] is a lot simpler. The Interactive Diagram internally already uses this method for moves like zB and qN: it creates a complete description of the maximum-length path as a sequence of 1-step legs, with in each leg a special mode flag to indicate the move can also terminate there. And it does allow the entire path to be used as a hopper, in order to allow zpB or zgB. I could easily extend that to allow user-defined paths.

And you are right: the entire Griffon move is essentially an oblique slider, like the Nightrider. So it does make sense to allow indicating the individual trajectories by the same direction system as the trajectories of the Nightrider (or Knight). So the Ship would be the 'Narrow Griffon', like vN is the Narrow Knight.

Well, for practical reasons I would prefer to have some separator between the legs. (Then I can just use the JavaScript split method to split the move in the parts between the hyphens, while otherwise this should be judged by the case of every individual letter.) I think that once you allow the brackets, allowing other non-alphabetic characters as well is no longer a problem.

In that case, perhaps it would be good to have two different separators to distinguish between optional and required continuations. For example, the griffon could be F&fR, and the mao W+fF (or whatever other symbols would be preferable)

I think Betza suggested also other uses for the brackets, like z[F,W] for a slider that alternats W and F steps in a crooked way, but this distinction could also have been made by using other separators than comma for that, e.g. [W/F].

He did indeed. The alternation modifier was in fact a, contrasting q which alternated circularly if followed by a set of brackets; t is also defined there, as is g (for ‘go’ — equivalent to the proposed [X-Y] to t[]'s [X~Y]) which covers the mao case (though conflicts with the Grasshopper usage).

writing the Griffon as F&fR or [F-fR] assumes the move can also be terminated without making all its legs, after just the F step.

There is technically another interpretation which would not conflict with the mao (and would obviate the need for Betzan g[] in the common case — though the original rhino (mao+wazir) would still need either the distinction or expliit compounding), which you've mentioned before: consider slider legs to move 0 or more rather than 1 or more, while leapers are still exactly 1. The arguably more complex piece that follows a gryphon's path but must move at least two spaces then gets a suitably more complex notation (e.g. Betza‐style t[FWR] or the like). This would also allow e.g. Tim Stiles' doubly‐bent Fox to be trivially t[WBW]. Of course with still more complex paths (t[WFR]?) the same considerations apply, though counting to 3 or more starts to be complicated for humans too so more specific notations of the likes of what are being discussed here are probably in order anyway.

What if doubling a direction made it absolute instead of relative?

As HG points out, duplication is already in use for other things; but in principle one could add a punctuation mark (maybe an apostrophe or an exclemation mark) to mark a direction as absolute rather than relative, which would be roughly equivalent

considering a certain grouped sequence of directional modifiers plus atoms as a 'crooked atom'

This is the interpretation I've been coming to for most chess‐variant pieces in general. Some kind of (for me, radial‐step — Nightriders have more in common with Dabbabariders than with Rooks imo) path and, independently, a set of constraints on that path, be it leaping, limited range, skipping squares, hopping, etc. And modality (movement, capture, or other special effects such as relaying or rifle‐capture) as a third factor on top of that. Works for most of the pieces people actually use afaict.

So the Ship would be the 'Narrow Griffon', like vN is the Narrow Knight.

I second this and the v[F-R]‐or‐equivalent notation, if a bracket‐style notation is being adopted, and if it's easy p[F‐R] and the like look nice too.

Worth noting as well that Betza also made a similar extrapolation in defining the a[WF]4 on the above page (just above the Two Sets, Four Boards heading)

It feels a bit silly to adapt a notation to the shortcomings of a particular font, but the - and ~ here are nearly indistinguishable for me on my desktop. (Not on my tablet, though!?) So I was looking for alternatives that also convey the intuitive notion of optional versus mandatory. How about ? and ! for this? So [F?fsR] would be the Griffon, and [F!fsR] the one that does not have the F move. The Tamerlane Picket would be [F!fB]. The area move from Tenjiku Shogi would be [K?K?K]. I am not sure ! would be intuitively better than - , though, as a mandatory sequel.

I kind of like the ?, though. In most cases it would make it unnecessary to allow zero steps in a slider leg; you could use ? in front of it instead. I admit that this would not work if there are still other legs following the slider leg you want to cut short, (such as with the Fox), because these would then be cut  off the move too. But the F and D moves of the Fox are a rather non-intuitive consequence of the general description, so I would not consider it bad if it needed to be mentioned separately. (As the textual description indeed does!) Like [W-fsB-fsW][W-W].

• Tamerlane Picket: [F-fB]
• Ski-Bishop: [A?fB] (but XBetza also offers jB for this)
• Slip-Rook: [W?fDD]
• Griffon: [F?fsR]
• Manticore: [W?fsB]
• Unicorn: [N?fB]
• Osprey: [D?fsB]
• Lame (Picket-like) Osprey: [nD?fsB]
• 'Delayed' Manticore: [W?fW?fsB]
• Mao: [W-fsF]
• MaoWazir: [W?fsW]
• Narrow Mao: v[W-fsF]
• Wide Mao: s[W-fsF]
• Moa: [F-fsW]
• Narrow Moa: v[F-fsW]
• Wide Moa: s[F-fsW]
• Moo: [K-fsK]
• Ship: v[F?fsR]
• Sissa: [Q-ivsQ]
• Checker capture: f[cF-fmF] or [fcF-fmF]
• Fox [W-fsB-fsW][W-W]

Of these notations, the Interactive Diagram currently only fails to understand the Ship, Wide/Narrow Moa (v or s would be applied to the first leg, not the move as a whole), and the Unicorn (N and B are not 'commensurate' atoms, and it would use NN in the second leg). I already solved the problem of incompatible strides in the first two legs (B, R, Q after D, A, G or H) by automatically slipping in transparent steps to get the initial leap. I suppose I would have to add some dedicated code for Q after N as well (and perhaps after C and Z?). Depending on whether the second leg is B or R the initial N leap should be either layed out as a Mao or a Moa, to align the second step with the f direction of the original second leg. For Q after N we would have a problem, as it is not clear anymore whether the most-outward direction is the adjacent diagonal or orthogonal slide. But I guess it would be no big loss to declare that illegal.

But the F and D moves of the Fox are a rather non-intuitive consequence of the general description, so I would not consider it bad if it needed to be mentioned separately. (As the textual description indeed does!)

Imo the explicit mention in the description (which is also erroneous as it omits the nD move — though the diagram includes it) is only because humans aren't used to counting to (or from) 0(!) — after all he does call it a length‐0 bishop move, so from the piece design POV it probably is the more intuitive.

(and perhaps after C and Z?)

At that point surely it's not much harder just to support an arbitrary leaper atom as the first stage?

For Q after N we would have a problem, as it is not clear anymore whether the most-outward direction is the adjacent diagonal or orthogonal slide.

Since both Rook and Bishop each have an outwardmost move after N, wouldn't it make sense at that point to just treat Q as a compound of R and B? So that [N?fQ] (I quite like the question mark too) would be a slip‐gorgon (slip‐gryphon + GA Unicorn=slip‌‐manticore). Presumably the diagram would have to do the dissociation ‘by hand’ and oddities like [K-fC-fQ] stop behaving intuitively unless one preserves state from the K step by also decomposing C (differently depending on how the K starts — though a human would probably be confused by this one too!)

(N and B are not 'commensurate' atoms, and it would use NN in the second leg)

I'm guessing the likes of [W-NN] are out of scope for now? :P let alone [W-CC] which camel moves can't emulate at all…

Imo the explicit mention in the description (which is also erroneous as it omits the nD move — though the diagram includes it) is only because humans aren't used to counting to (or from) 0(!)

True, but isn't 'intuitiveness' all about catering to human peculiarities? It is not so much that I am worried about the description of the Fox, but more that in all kind of other cases people will get extra moves because they did not count on a slider leg also eliminating itself by taking 0 steps.

At that point surely it's not much harder just to support an arbitrary leaper atom as the first stage?

Well, so far every leaper is a special case, where I have determined by hand at what point it has to turn the corner, and how much extra transparent squares to add before or after that point. For inital N, C or Z this works now.

I'm guessing the likes of [W-NN] are out of scope for now? :P let alone [W-CC] which camel moves can't emulate at all…

Yes, this is hard. Because so far I implemented everything as a pre-processor, translating the bracket notation to XBetza by replacing the hyphens / question marks for a, eliminating all atoms, and writing the first atom at the end. So it cannot do anything that XBetza cannot do. (The resulting XBetza can be seen in the Betza Sandbox by clicking the move in the table a second time, btw.)

True, but isn't 'intuitiveness' all about catering to human peculiarities?

I think here it depends strongly on which humans and in which context; after all most multi‐leg movers with slider components do have the option of zero‐length stages — GraTiA's gryphon/anchorite and Mideast/Rennchess' duke/cavalier are very much the exception afaik, so from a design (and usage) perspective the 0‐step leg option seems to be the more intuitive. The case with reading descriptions is slightly different, because you have to say both stages of the move and consciously we count starting from 1 (unless we're mathematicians or programmers), so it often requires being explicit in the verbal description.

[…] that in all kind of other cases people will get extra moves because they did not count on a slider leg also eliminating itself by taking 0 steps.

Oþoh I can see the other case where someone expects to simply be able to write e.g. [B-fW] for a transcendental prelate/contramanticore, and is confused by the fact that it disallows the W squares; ofc in this case it's simple to add them by hand (the ? notation doesn't handle this case) but with more complex moves it may not be. Whereas imo in the opposite case, where the contramanticore has to make at least a knight's move, it's likely to be more readliy apparent that an extra F step is needed at the beginning to force that (or indeed two or three extra such steps if necessary). And surely it's more intuitive to specify three initial W steps (after the F one ofc) for the Tamerlane giraffe (“one diagonal and then after that at least three straight”) than only two?

Reminds me a bit of regexps; the Kleene star * there does explicitly specify 0 or more and if you want a minimum n^r of repetitions you have to specify them explicitly (or use syntax extensions like +)

Oþoh I can see the other case where someone expects to simply be able to write e.g. [B-fW] for a transcendental prelate/contramanticore, and is confused by the fact that it disallows the W squares ...

But there B is an initial leg, and I don't like it at all that initial legs would behave differently from only legs. Perhaps we have different intuition, because I would consider it natural that the Tamerlane Giraffe would only need F+2W: one for every traversed square where it isn't allowed to stop. When 0 steps is allowed, you would need [F-fF-fB] for the Tamerlane Picket, and [F-fB] would be a normal Bishop. I think that is really strange.

BTW, [W?sfNN], and even [W?sfCC] work now. All through using a new, undocumented (and quite horrible) extension of XBetza.

that initial legs would behave differently from only legs.

The behaviour is the same if you stipulate that all slider legs are potentially 0‐length but null moves are disallowed unless explicitly specified

Perhaps we have different intuition

May well be :) And fwiw I'm fine with either system in practice

When 0 steps is allowed, you would need [F-fF-fB] for the Tamerlane Picket

Or simply [nA-fB], which to me looks more natural as an alfil extension (istr Gilman classes it that way too). [F-fB] is ofc a bit odd as a Bishop description, but there are always going to be strange ways of notating things

BTW, [W?sfNN], and even [W?sfCC] work now. All through using a new, undocumented (and quite horrible) extension of XBetza.

That's pretty cool :) (and agreed, the repeating ys are… not pretty). I can even get an offset giraffe‐rider (or even zemel‐rider — presumably longer ones work too, if they'd fit on the board), even though normal giraffe‐riders (FXFX?) are apparently unsupported!

But the y extension still fails for e.g. [W?sfZZ] (also shouldn't that be fsNN ⁊c?), let alone pathological things like [C?fsZZ], so if we're making an effort to support direction‐type changes it probably deserves to be more general.

Also speaking of the Z, [Z?sfB] currently gives me Zebra‐then‐Rook, and vice‐versa

I can even get an offset giraffe‐rider (or even zemel‐rider — presumably longer ones work too, if they'd fit on the board), even though normal giraffe‐riders (FXFX?) are apparently unsupported!

The way it works now is that an even number of y force the next leg to be orthogonal/diagonal with a stride of half that number + 1, while the next odd number of y then adds a sideway step of 1 to that. (So there is currently no way to specify a Zebrarider in the 2nd leg.) But the preprocessor would not recognize any rider beyond CC, and never generates more than the 5 y needed to request that. Duplication of extended atoms is indeed not supported. Initially I thought of atom duplication as a legacy feature, and preferred a range 0 for specifying unlimited-range riders. FX0 should work.

But the y extension still fails for e.g. [W?sfZZ] (also shouldn't that be fsNN ⁊c?), let alone pathological things like [C?fsZZ], so if we're making an effort to support direction‐type changes it probably deserves to be more general.

That I used sf in [W-sfNN] was nonsense (and in fact turned out to be buggy when I first tried it), as sfN means the same as fN: both forward-most moves. I had suppressed the multiple-y extension on oblique first leg, but there really is no need to do that, so I lifted that ban now, and [C-fNN] should work too.

Also speaking of the Z, [Z?sfB] currently gives me Zebra‐then‐Rook, and vice‐versa

This is a consequence of sf being an invalid direction specification for B after an oblique. The continuation here always uses the K system of directional specs, and I laid out the transparent path of Z before B so that it ends in the diagonal direction, which means that B is the f direction. The specification fs causes the underlying XBetza interpreter to apply atom rotation, making the continuation Rook-like. So this is an example where the directional spec overrules the atom type. (Which of course is the basis of XBetza, which doesn't even specify the continuation atoms.) [Z?fB] should have given you what you wanted.

Now that we can use incommensurate atoms, the definition of 'forward' continuation had to be extended. I did that such that after oblique this is the diagonal slide that stays in the same quadrant. While oblique after queen-like uses the degenerate 8-fold system, so that f refers to a pair of moves.

I'm confused about u. I'm trying the move dyaubQ but when I try it out the replaced piece never ends up where I expected it too, on it's original square.

I'm confused about u. I'm trying the move dyaubQ but when I try it out the replaced piece never ends up where I expected it too, on it's original square.

The problem you are running into here is that locust capture of a friendly piece is used by the Diagram for encoding castlings. (As a locust capture by the king of its own rook. That allows indicating both the castling partner and the King destination.) So when the GUI performs the move that you entered, it tries to castle with the captured piece, and would relocate it even when there would not have been a u.) The u modifier is officially defined only for unloading the piece that was captured at the end of the move. (This to side-step the issue what we should unload when multiple pieces are captured.)

I am not sure what you are trying to achieve here. If u would have been defined as unloading the last (or only) victim that was captured during the move, the described move would unload the victim at the square it was captured (and then steps back one square). Are you trying to use this as a method for hopping over (or in this case bouncing back from) friendly pieces only? I guess it would be nice if (say) dyaufQ could be used to describe a Grasshopper that can only hop over friendly pieces, and cyaufQ for only hopping over enemies. I suppose the definition of u could be adapted to always unload the last piece that was captured before it, and if none was captured, the first piece captured after it. (And then exclude that piece from relocation by any following u.) That way you could always slip in as many cau and dau combinations you want, as alternative to pa. I could of course limit the interpretation of friendly locust capture as castling by the GUI to pieces that acually have castling defined as one of their moves.

It seems something else is wrong too, as I have to enter the first leg twice as locust square, before the final destination gets highlighted. This could be a consequence of that unload squares must also be clicked (e.g. the Valkyrie from Odin's Rune Chess allows relocation of the captured piece anywhere along the path of the move, and you will have to indicate where. So with afudQ it first lets you select the (empty) unload square, and then the (friendly) victim at the final destination. So I guess it first prompts you for the locust victim, and then for the unload square. Which is a bit silly when these must be the same according to the move description. I can streamline this, but with end-point victims only this situation was not supposed to occur.

[Edit] I did reserve the castling interpretation of friendly locust capture now for pieces that can castle. This means you can at least now define such moves on other pieces. But of course such captures are not likely to occur in a variant as such, as the players would avoid those like the plague. That becomes different when the piece reappears somewhere else. Problem is that the internal move representation of the GUI only has a single locust square, and it is already used to indicate the locust capture. When it points to an empty square it is interpreted as an unload. Of course an unload on the same square as the capture really is a no-op; it just becomes a simple (hopper) move, and the e.p. square would not have to be set or indicated at all, just as for entering hops you don't have to indicate the mount. So the highlighting function should be changed to treat locust capture + unload on the same square the same as a hop, the only difference being that it tests whether the victim has the right color.

Are you trying to use this as a method for hopping over (or in this case bouncing back from) friendly pieces only?

Yes, I was trying to figure out if I could define a sliding piece that cannot stop until it cannot slide any farther.

OK, I now made it such that dau and cau are treated as hop onto friend/foe-only, and are treated just as pa. That means you can still have another locust capture or unload square on the same move, and the unload would then refer to the piece captured in the destination.

I am afraid that what you want still would not work, because the slider could also hit the board edge, and there doesn't exist any method yet to 'sense' that. I once considered to allow o in non-final legs to allow the leg to go off board (or onto a 'hole'), but it conflicts with the use it has now for indicating cylindrical pieces. Of course a new modifier could be introduced for this.

Problem is that at best its use would lead to contrived solutions. If new symbols have to be introduced, it might be better to introduce something that directly does what you want: force a slider to its maximum range. Like we already have W* for moving up to half the board. E.g. R$ (or perhaps W$ ?) could mean 'only the farthest accessible empty square. You could then write Q$cQ.

I have implemented a new meaning of the o modifier on non-final legs. On a final or only leg the legacy meaning of 'cylindrical piece' remains valid. On non-final legs it means the move is allowed to step off board. This is treated similarly to hopping, where you step on an occupied square, and will terminate the current leg to continue with the next.

Why would this ever be useful? Well, it turns out there are several applications. One is the Reflecting Bishop, which bounces from the board edge. To 'sense' the edge you can optionally extend the Bishop move with a Ferz step in the same direction. And if that lands off board, you can retrace that with another Ferz step, and then continue as a Bishop at right angles. So [B?foF-bF-sB]. The ? indicates this 'hook move' extension of the trajectory is optional, and that you can terminate after a normal B move as well.

Another example is the Edgehog: this moves as a Queen, but only from or to an edge square. To describe these moves you need to sense for the edge at the start or the end of the move, respectively. When a back-and-forth King step can hit an off-board square you are on the edge, and can continue with the real move in the next (and in this case final) leg: [oK-bK-Q]. Or for moving to an edge [mcQ-oK-bK]. (There has to be an explicit c on the Q move there, as otherwise the latter would not be able to capture, being a non-final leg.) This works, but is a bit inefficient for the AI, which is still too stupid to recognize that moves that go through a different path to the same square are really the same move. So it would search each Edgehog move 3 times, reaching the destination through the three different off-board square the oK step can reach. This would needlessly drive up its thinking time. This can be cured by probing more selectively (directionwise) for the edge: [vvssoK-bK-Q][mcQ-foK-bK]. This limits initial probing to orthogonal directions, (which, except for the corner case, hits only a single off-board square), and probing on the target square to the forward direction.

Off-board detours also make it possible to describe the Ultima Withdrawer and Advancer. These are given an extra back-and-forth step at the start or the end of their trajectory, respectively. With this step they must either capture an enemy, hop over a friend, move through an empty square, or stray off board. Without the latter, it would not be possible to describe moves that dissociate them from the edge. There is one problem: we cannot use the p for describing the hopping, because that would also allow hopping over an enemy piece, and thus make the capture of it optional. While the capture must be a mandatory side effect of the move. Fortunately we can use the 'friendly capture + unload' trick to describe friendly hopping. But this forces us to describe it as a separate move from the real capture, as the latter should not be unloaded. So we get [omcK-bK-fmQ][dK-buK-fmQ] for the Withdrawer, the first move describing moving away from the edge, and empty square or an enemy (and capturing the latter), the second moving away from a friendly piece.

Similarly, the Advancer will be [Q-fomcK-bK][Q-fdK-buK]. These descriptions are not very intuitive; it would probably be preferable to have some method to describe the captures here as Fire-Demon style 'burning', but in a specific direction, rather than through all K steps. This still has to be designed, though.

The o modifier for straying off-board is a very powerful tool, but unfortunately not very intuitive. From the examples I discussed in the previous comment it appears that it almost exclusively occurs in back-and-forth move, for testing if we are on an edge square. This is somewhat clumsy idiom, and last night it occurred to me it could be useful to create a new atom to perform this task in a more intuitive way: E could mean a null move that can only be made on an edge square. The Edgehog would then be [E-Q][mcQ-E], which I would consider a rather intuitive description. Because a null move has no intrinsic direction, we can stipulate that for the leg following it the forward direction is determined by the leg preceding it. (Or, in other words, 'forward' is continuing to move in the same direction as the latest leg that really moved.) So [B?E-sB] would be a reflecting Bishop. When the E is in the initial leg, the forward direction for the following leg could be defined as perpendicular away from the edge. So [E-fR] would mean a Rook move away from the edge. I guess we could allow directional modifiers on the E for indicating in which absolute direction it has to test for an edge: [B?sE-sB] would only be able to reflect from the left and right edges.

The other idiomatic construct in which o appeared was useful for 'burning' a single piece as the side effect of a move, i.e. a locust capture that must be made when it is possible, but would not preclude the move from being made when it is not possible (because there is no enemy on the indicated square, or the square would fall off board). This also involves a back-and-forth step, which needs the 'most-general non-overlapping' mode omc + friendly hop, which covers all possible states of the target square, and specifies its clearing only when it is an enemy. This problem was compounded by the fact that we have no modifier for friendly hopping, and that this needs the ckludge of friendly-capture + immediate unload. Where the need for the unload then makes in uncombinable with the c, so that you end up with a horrible [..omcK-bK...][...dK-buK...] construction. It would be nice to have some shorthand for this: burn the target if you can, but never mind if you cannot. One idea that came to mind is to use cc for this. So ccK would burn (without moving) an adjacent enemy in the direction of choice (which could be limited by directional modifiers) if one was there, but also continue if there wasn't. The Advancer would then simply be [Q-fccK]. The Withdrawer would be [ccK-bmQ], the b indicating that the Q move should go in the opposit direction from the burn square (and an m needed to suppress normal capture the final leg would have by default). Of course we could have a similar dd for friendly burning.

If no single direction is specified on the cc leg, any single one of the allowed directions can be chosen (as is usual in Betza notation). So the Forest Ox of Odin's Rune Chess could be written as [N?ccK]: move as Knight, and then optionally burn one enemy of choice adjacent to the destination square. If you would want to burn more victims, you would have to repeat the atom. E.g. [R-flccF-rccF] would burn two victims diagonally forward from the destination. It is a bit awkward here that the second burn needs r rather than fr, because it is referenced to the previous burn rather than the Rook move. (But ccK must (re)define a 'last direction', or otherwise the Withdrawer could not work.)

Does any of this make sense?

Does any of this make sense?

Yes, it does. Doesn't the withdrawer in Ultima move as a queen, so wouldn't need to detect the board edge? Detecting the edge is still very useful. The suggested uses of E and cc make sense to me.

I don't quite understand how dau and cau work now. I tried (dauf)Q, thinking that would describe a queen that could pass through friendly pieces, but if it captures after unloading the captured piece ends up at the starting square of the whole move. Is that intended?

I tried (dauf)Q, thinking that would describe a queen that could pass through friendly pieces, but if it captures after unloading the captured piece ends up at the starting square of the whole move. Is that intended?

No, this was a bug. I fixed that now.

Doesn't the withdrawer in Ultima move as a queen, so wouldn't need to detect the board edge?

The problem is that when you put a plain mQ move in the Withdrawer, it can also make this move away from an enemy piece without capturing it. To make the capture mandatory you have to detour the path over the potential victim, either passing through an empty square or hopping over a friendly piece, but capturing as the only way to pass over an enemy. But if you do that (e.g. [mcK-bK-fmQ][dK-buK-fmQ]) the Withdrawer can no longer move away from a board edge. So you would need an extra [E-mQ] move (or change mc to mco for the sensing step).

The same problem exists for the 'maximum range slider': you want to sense if the next square in its path is occupied by a friend, but you should also be able to approach an edge. So [Q-fdK-buK][Q-foK-bK]cQ would do it. (The simpler [dQ-buK][oQ-bK]cQ would allow null move when standing against a friend or edge.)

[Q-odfQ-ubK]cQ seems to work too

[Q-odfQ-ubK]cQ seems to work too

Indeed; the u after an o leg apparently is ignored. I guess this is because you always have to end on an empty square with this move, so there is nothing to unload. (With a bit of bad luck it would have created a hole at the square of origin :-) ) Q-f..Q is not recommended, though:it creates a lot of different paths to a distant destination, as every square that is traveled to would be (successfully) tried as an intermediate. So it slows down the AI. With Q-f..K you don't have that: the intermediate square must be the last before the obstacle, or the K step could not hit the latter.

what about a piece I recently read about that moves like reflecting bishop, but that must make at least one reflection?

You mean how could it be described? With the new E atom it should be simple enough to do exactly one reflection: [B-E-sB] (a slight change from the regular refl. B in HG's comment) For arbitrarily many, but at least one, I think we still need the off‑board interpretation of o as the [] notation lacks arbitrary repetitions afaict. That would give something like yafoabyas(yafoabyas)B (though the sandbox seems to ignore the brackets on the second one, only allowing either one or two reflections… probably I'm doing sth wrong)