Comments/Ratings for a Single Item

How to specify a locust like a chu shogi lion with/without the trading restrictions using the move definition aid?

The move-definition aid only works for leaper and (straight) rider moves. (Which is sufficient for 95% of the pieces one encounters in chess variants.) The most common other pieces (such as Cannon or Griffon) can be selected from the table with their move predefined. In other cases there is no other way than to type the XBetza move description yourself, and assign it to the piece.

Anti-trading is not considered a feature of the move, and thus cannot be expressed in move notation. It is considered an extra rule on par with the checking rule, making some of the pseudo-legal moves illegal depending on circumstances outside the path of the move. The notation is for describing the pseudo-legal moves of the piece.

The Applet does not provide an interface for specifying anti-trading rules. (Which only rarely occur.) To make a Diagram that can play with such rules, you first have to make one without, copy the HTML code for the Diagram to a separate page (e.g. a Comment), and then edit in the anti-trading as extra Diagram parameters (as described in the article on Interactive Diagrams).

@HG

When trying to reinforce the Sissa Chess preset rules using the Play-test applet, I get stuck with the conversion parameter: something is wrong with it. The conversion rule does not fully apply, since if I normally move a bishop, the other would necessarily convert on its first move, which does not happen. The same thing happens in reverse.

Could you please take a look at this issue to try to see what's going on?

You commented on this matter on 2021-12-01:

All that is now required is define the bishop with an extra initial iW move, and add a parameter conversion=N, where N is the number of the piece table of the piece to which the rule applies. (So here N=3). The first moves of pieces of this type are then forced to go to different square shades.

Where does it come from that 3 is the number that corresponds to the bishop?

Thanks in advance for your help.

This Bishop was the third piece in the piece table of that Interactive Diagram, after P and N.

But that the Interactive Diagram supports the conversion rule doesn't necessarily mean the GAME code generated from it would. The generated GAME code still comes with the disclaimer:

This project is not entirely finished yet; some of the more exotic features supported by the Play-Test Applet (or not even by that, but by the Interactive Diagram), such as Imitators, and cylindric pieces, are not yet supported as GAME code.

Unfortunately conversion is one of these 'exotic features' (i.e. which almost no variant uses). So the GAME code would just take the iW move defined on the Bishop at face value, and always allow the orthogonal step on a virgin Bishop, no matter how the other Bishop had started. (This of course is already a big improvement to a preset that would not enforce rules at all, as it would never reject anything that was allowed.)

From where we are now I think the best solution would be to add some extra GAME code to the Post-Move and Game-End sections to enforce the conversion rule; the Post-Move code should detect whether a virgin Bishop moves, remember if it was a W or B move, and reject it if a move of the same type had already been done (by a virgin Bishop). I will give it a thought.

[Edit] It was actually not so hard to add this as a standard feature in the betza.txt GAME-code include file, without slowing it down much. To activate the feature you would have to add at the end of the Pre-Game section of your preset the line

set conversion (B b);

I will see if I can patch the Play-Test Applet so that it would automatically generate this line as part of the Pre-Game code you have to paste when you feed it a Diagram that specified the conversion parameter.

I implemented it in a slightly different way in the GAME code as I did for the Interactive Diagram; the latter judges the initial moves of the pieces subject to the rule by the square shade they land on, which must be different. The preset required that one of the moves was "initial only", and the other not. This is more general, and could for instance also be used to convert an Alibabarider with an initial Ferz move.

The current include should reject attempts to start the second Bishop with the wrong kind of move. It will still highlight these moves, though. I will fix that later.

Today any function of play test applet doesn't work... :(

The conversion rule is already applied correctly in the aforementioned preset, so once again... thank you very much for your help!

Indeed, the conversion rule should work now, including the highlighting.

Okay, I noticed that the "apply" button for the board setup doesn't work

Okay, I noticed that the "apply" button for the board setup doesn't work

For me that works without problems. Try flushing your browser cache; perhaps there is a damaged version of the betza.js script in there.

Thank you :)

The bracket notation for bent sliders doesn't handle fourth and higher perimeters well.

(No big worries; I can just enter the third-perimeter equivalent, let it translate to conventional XBetza, and extrapolate from that.)

Indeed, the bracket notation is still under development, and only a few of the simplest cases work. Slider after leaper are special cases that each have to be programmed separately, because of the XBetza requirement that every leg should be expressed in terms of the same atom. The move-definition aid doesn't do 4th ring either, btw.

What is really needed is code that compiles the bracket notation directly, rather than as a preprocessor for XBetza. The internal move representation does include a leap specification for each step.

I am working on a next version of the Play-Test Applet, which should also allow the user to specify automatic promotions and zone confinement. I am looking for some feedback on the interface that allows one to do this. Is it sufficiently evident how to use this? If not, what could be improved?

I tried setting up morphs for pawns but it never used the pieces I chose. It would be good if there were a way to see the morph board for a piece after it has been set to confirm or change it.

By "automatic promotions," are you referring to immediate promotion on entering a promotion zone, on the piece in question making a capture, or on another piece being captured? The Prince promotion in Vanguard Chess is an example of the latter, but I've also occasionally seen rules like, "The Pawn promotes to any piece that's been captured; if there are none, then the Pawn stays where it is until one's available, at which time the Pawn promotes immediately and automatically."

The Wizard/Sorcerer/Thaumaturge relationship in Short Sliders is also something that I'd like to see available, though if it's too complex I totally understand.

It'd also be good if certain pieces that can take a turn without actually moving (such as the Zero or the Bomb) could, when clicked, bring up a button asking if that's what the player wants to do (possibly as a spell or something similar).

Ah OK, I think I know what you mean. You morph into different pieces than those you placed on the board, once you start playing. Problem is that I currently create the morphs by piece ID, as they would appear in the morph parameter of the Diagram that is produced upon pressing the HTML button. But the table of all available pieces contains many pieces that have the same ID. And the algorithm for interpreting the morph parameter takes the last piece in the list with the given ID (other than the promoting piece itself).

I guess this is a general problem with the Play-Test Applet, when you use it to play on the page itself: it considers the entire list as participating pieces, and this would also wreck interpretation of the promoChoice parameter: it would allow you (or the AI) to promote to non-participating piece types that happen to have the same ID in the table as the participating promotion piece.

I suppose that I should remove all pieces that are not on the board from the table, at some point. That raises the problem for how to indicate participating pieces that are not present in the initial setup. Perhaps I should add a button for that, "Starts off board", so that one could select a piece type in the table, and then press that button instead of selecting a board square. These piece types would then also be left in the table when you press the "Start position" button.

That raises the problem for how to indicate participating pieces that are not present in the initial setup. Perhaps I should add a button for that, "Starts off board", so that one could select a piece type in the table, and then press that button instead of selecting a board square. These piece types would then also be left in the table when you press the "Start position" button.

Would it be possible to have it so that you can switch back and forth between playtesting and editing?

"Starts Off Board" would be a great addition! It'd make something like Short Sliders a lot easier to create. It'd also be a good step toward adding a "drop" feature later.

Would it be possible to have it so that you can switch back and forth between playtesting and editing?

That is exactly what stopped me before from culling the piece table; you would no longer be able to add new pieces once these have been deleted. But a solution for that occurred to me: the extra pieces are only troublesome if they have the same ID as participating ones. So on pressing Start Position I can simply set all IDs of the non-participating pieces to a dash. One can always assign a new, valid ID afterwards, if one selects the piece as an afterthought.

After pressing Start Position the Diagram is no longer in setup mode, though. This only affects automatic placement of color-reversed pieces, so perhaps this isn't a real problem. I suppose I could add a button to go back to setup mode.

"Starts Off Board" would be a great addition! It'd make something like Short Sliders a lot easier to create. It'd also be a good step toward adding a "drop" feature later.

Well, it doesn't really make a lot of difference if you know how: in the old Applet all pieces would be participating when you used it for playing in the Applet itself. And for the purpose of generating HTML for a Diagram elsewhere, or GAME code, you could drag the other participating pieces from the table to empty squares on the board after you had pressed 'Start Position', before generating the HTML or GAME code.

The problem with a drop feature is mostly in the AI, that it enormously drives up the branching ratio, and that you only start to distinguish useless drops from sensible ones after two more ply of searching. (As all drops are non-captures, and in general decrease your positional score, because pieces in hand are more mobile than on the board.) With such a large branching ratio the AI would not be able to search far enough ahead to see the advantage of any drop. What would be needed is some smart method for selectively generating drops that might be useful (e.g. those that deliver check, or where a weak piece attacks a very much stronger one). This is not easy in a context where dropped pieces can have arbitrary moves. E.g. for check drops you basically need a 'reverse' move generator, which gives you all moves to a given square, rather than from one. But some moves that can be described with XBetza are very hard to generate in reverse. E.g. for a Griffon.

Changing the id of all absent pieces to '-' appears to have worked for on-page playing. (Flush the browser cache, as I also had to fix something in the Diagram script, to prevent the Start Position button would crash on a highlighted empty square, which can be a remnant of defining the morph board.) And it makes future editing only slightly more cumbersome, as you would have to redefine a new id. Perhaps I should reserve clearing the id to ids that have the same id as a participating piece; those would have to be redefined anyway if one wants those to appear together in the same variant.

Another matter is how to enable the user to enter a capture matrix. The problem here is that this, unlike the morph board, might not fit in the board, but would need a board that has all piece types as 'coordinates'. For games with multiple rows of pieces this is usually larger than the board. (Even for the 8x8 Team-Mate Chess it is!)

I suppose I could let the user enter the matrix per row, and then assign that row to a piece (the moving piece). Then there could be an Nx2 auxiliary board displayed, which on the upper rank shows all participating piece types, and pieces could be dragged to the lower rank to indicate what the moving piece should change to when it captures the piece displayed above it.

The problems you describe with the "drop" feature are pretty close to what I suspected. That's why I said it would be "later." (And since I have yet to even think of a game that uses it, I'm in no hurry for it myself.)

If you ever do start working on it, I think some of the load can be taken by keeping a running score for each square for how useful a certain move (of one space) from that square would be for a drop. Something similar could also be done for how vulnerable the space is, and from what direction; this could evaluate how useful the space is as a block (since a drop can also be used to block a slider's or rider's move from check or capture). Those functions, which would activate only if drops are active, and could be calculated for each combination of piece and open space. That method is kind of crude and rough compared to "evaluating the future," but it's a possibility.

I suppose I could let the user enter the matrix per row, and then assign that row to a piece (the moving piece). Then there could be an Nx2 auxiliary board displayed, which on the upper rank shows all participating piece types, and pieces could be dragged to the lower rank to indicate what the moving piece should change to when it captures the piece displayed above it.

This does strike me as a very useful method. The matrix would be a separate table, I take it?

I now put an interface for defining a row of the capture matrix (together with the morph board and other properties of a piece) in the new Play-Test Applet. It doesn't really create a capture matrix yet; so far it is just a test for judging if the interface is convenient, or not. It only would allow defining what happens for capture of enemy pieces; friendly capture seems to rare a feature to worry about at this stage.

I was thinking, though. Chess Variants typically have a few pieces with special properties. Defining the capture matrix per row is good for pieces that promote on capture, and allows you to diversify based on what they capture. But there are also pieces that are exhibiting their special nature when they get captured. (E.g. contageous or iron pieces.) For such pieces entry per row is quite cumbersome; you would have to indicate the special behavior in the row for every piece that captures it. Defining the capture matrix per column would be much easier for that case.

So perhaps I should put a switch there for selecting whether the promotions you entered are for a row or a column.

Currently the capture row is a bit far from the piece table, so that you might have to scroll to place pieces there. I must put it in a place where it can get very wide if there are many piece types, though. Perhaps there is too much text above it to explain how it works, but I am not sure people could figure out how to use it without that text. Of course I could put a clickable link 'hide explanation' with the text, to reduce the distance to the table?

I experimented a bit using the opening position for Short Sliders, and the capture matrix looks great. I'm only unsure about how to enter information for more than one capturing piece, but that can come as you develop it.

I also don't think I quite understand how to keep a piece available without including it in the opening setup, but that's more likely because of me (unless you haven't implemented that yet).

To get it to fit, maybe you could put the morph board information on the left; if nothing else, that'll move the capture matrix up a bit. You could also put it in its own frame or something, like the piece list is, so that any left-to-right scrolling from having a massive number of pieces only has to affect the matrix itself.

(Of course I wish there were more symbols available on the diagram... but then, I would, wouldn't I?)