Comments/Ratings for a Single Item

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

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

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.

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

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.

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

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

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

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.

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?

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.

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.

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

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

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

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.

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.

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

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.

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