Comments/Ratings for a Single Item

How to remove a piece from the diagram. For example if I want to put the King on another square than those on which they stand by default?

You can move the pieces over the board, just like you can when you use the diagram for playing. If you want to remove a piece that you selected by mistake, but do not want on the board after all, it is a bit more tricky: you would have to capture it with another piece, and the Diagram only accept attempts to capture if they are pseudo-legal moves (i.e. when the piece to capture gets highlighted when you select the piece you are going to capture it with.) Best way is just to move the piece next to the opposing king (moves to empty squares are always accepted, even when not pseudo-legal), and then capture it with the king, and finally move the king back to where it belongs.

Also, how to use "paste an existing diagram". For example, I want to create a play-test for Shako. What can I paste in that box, an image? the link for the shako page? something else? I don't know how to use this?

That box is for pasting diagram descriptions of the type you get when you press the 'Show HTML' button at the bottom of the article. It is intended for trying out diagrams that you modified by editing the text of their description, e.g. to implement some features that the Play-Test applet would not allow you to switch on. Such as Shogi-style promotion. You can then first make the Diagram without that feature, ask for the HTML, paste it in a text editor to modify it, and copy-paste the modified version back into the diagram. Or when you get a Diagram from another page (by asking for 'Page Source', and copy-paste from there. (I discovered that also there you have to paste it into a text editor first; directly copying from the Page Source seems to leave in all kind of invisible formatting information the Play-Test Applet chokes on.)

E.g. when you want two promoting piece types, you would have to add the line maxPromote=2 to the Diagram description, otherwise only Pawns will promote.

[Edit] I forgot to say: there is also a button for creating GAME code for automating a Game Courier preset. Originally the paste box was added to make it possible to convert an Interactive Diagram that you made before and posted somewhere else to GAME code. Without the need to entirely recreate the Diagram through the Applet. Which for large variants would be more cumbersomet than just copy-pasting an existing and well-tested Diagram into the box, and pressing the GAME-code button.

@HG: why the "estimated piece values" are varying when I reload the page. Even relatively one piece to another, I see some changes.

Is the way it is estimated explained somewhere?

Thank you

I did not describe that anywhere yet. But it involves some randomization: it starts by generating some 10 random positions with a filling fraction of 25%, where the pieces of a given color are 3 times more likely to be at their own back rank than on the far rank. Then it counts the number of moves the piece under test would have on every empty square in these positions, distinguishing captures from non-captures. It translates that to the number of reachable and attacked squares on an empty board using the filling fraction. (E.g. if it would on average have 1.5 captures while the board is 12.5% populated with enemy pieces, it counts 1.5/0.125=12 attacked squares. If I would count attacked squares on an empty board directly, sliders would get too many moves, and hoppers would not have any.) It does not only calculate the average number of moves of the piece this way, but also the standard deviation, and adds the latter to the average. (This to compensate for the effect that during play you put pieces on squares where they are active, and avoid bad squares.) From the thus calculated mobilities N I derive a piece value with the formula (33+0.7*N)*N (centi-Pawn), which takes account of average cooperativity between moves, where captures are weighted as 1.33 move, and non-captures as 0.67. (And locust captures have some extra weight.)

It is still far from perfect, but good enough for the level at which the AI of the diagram is intended to play.

Thank you very much. It looks like a well though model. It makes a lot of sense.

I understand that the random positions are taken on the related board, so the result is indeed dependent of its dimensions (which is expected I guess).

That randomisation at the beginning explains why I get different results by re-doing the operation. For example with a Rook's value normalised at 5, on a regular 64-sq chessboard, I get Queen as 8.95; 9.2; 9.6; 9.8 on 4 consecutive trials.

I agree that this enough to what it is done for. I wonder if increasing the number of 10 positions would decrease the results' span.

Thank you again for this detailed explanation

I wonder if increasing the number of 10 positions would decrease the results' span.

Sure, in the limit of an infinite number of positions this should converge to a fixed value. I suppose this limit could even be calculated from the probabilities that squares will be occupied (and by what) according to the rules used by the model to generate the positions. It was just less work to have the program estimate it.

The variation between attempts is not larger than the accuracy of the method anyway. (And a bit of randomization helps to avoid deterministic play.) Different distributions of black vs white pieces might result in a different limit: the more your pieces gravitate to your own side of the board, the larger will be the reward for 'forwardness'. Perhaps the move counts should have been weighted to take account of the probability the piece will be there (which would be smaller in the enemy camp). Using a different filling fraction would affect the relative values of leapers, sliders and hoppers. (Strong chess programs do use separate sets of piece values in end-game and opening phase. The Diagram's AI is not that advanced, which probably means it handles hoppers stupidly. But if I would ever imrove that I would probably have it determine the values with a 50% and 10% filling  fraction, respectively.)

There are also many 'global' aspects of the move patterns that are not taken into account. It seems that there should be some bonus for attacking orthogonally adjacent squares ('concentration'), which is the most likely explanation for the unexpectedly high value of the Archbishop. There probably should be a penalty for color binding, especially for severe forms of color binding. As it is, the algortithm would value an Alibaba about equal to a Knight, because it is not aware it can only access 1/4 of the board. Having only step moves (i.e. Shogi generals) should probably be penalized.

The table with all pieces on this page is pretty useful to estimate values. I wish it could include more piece: Manticore, Buffalo (NCZ), Okapi (NZ), Bison (CZ), Duchess (KADGH), Cheetah (CZGH), Tiger (CZGHAND), Centaur (KN), Heroin (RFN), Templar (BWN), Lion KAND, Ship t(FvR), Snake t(vWB), Troll (mfWcfFGH), promoted XQ pawn, Mao (XQ N), Osprey t(DB), Ostrich t(AR). Well, that's a lot, too many maybe. Maybe just some of them...

It is easy enough to get value estimates for pieces with moves that are not in the table, since you can alter the moves that are in the table by default. Just type the Betza notation for the move you want in the text entry below the table, and then click the cell with the move of some piece that is in the table to give it that move.

There is just one caveat: you have to assign all the moves before you ever ask for the values by clicking the header of the move column, (or use the Diagram to play against), because it only calculates the values once, and is not aware that a move has changed. (Because in the normal function of the Diagram this cannot happen; Arguably this is a bug and I should make the code that assigns the new move, which is specific to the Play-Test Applet page, also recalculate the piece values.)

Thank HG. I will try again because I was getting 0 only for any changed move.

The generated GAME code doesn't work properly with moves that involve unloadng pieces. The last unloading step is never applied and the piece ends up removed.

Also, it doesn't recognize the use of 'o' to detect board edges. Might these be supported eventually?

Is this for unloading the piece that is captured at the end of the move, or for a locust capture? I remember having tested the GAME code for Odin's Rune Chess, and the Valkyrie there did work properly. Unloading locust victimes might not have been implemented yet, though. I could of course have broken something while implementing other new features.

I was trying pieces that would need to end their move just before or after a friendly piece, such as (dauf)F, for example. It's able to pass through friendly pieces, but the last passed through piece is never unloaded. Something like yaodfaubQ also fails to unload. Maybe these are too obscure to bother with.

I implemented the dau work-around for friendly hopping in the Diagram only after I wrote the betza.txt include file. And I don't think I ever got to adapting that likewise. But eventually I should do that. Like you say, it is pretty exotic, so it was not a priority. E.g. Shogi promotions seem a much more common feature.

I now added a button at the bottom of the Applet page that causes the HTML for a table of piece descriptions to be displayed. So users could copy-paste it into the articles describing their chess variant. This is probable a better method than relying on an Interactive Diagram on the page to generate it on the fly, as it would also work when JavaScript is disabled.

It also solves the problem of imperfect description generation for pieces that are too complex: one can simply edit the text for the corresponding pieces after it was incorporated in the article.

Assistance request for promotion piece in the test applet for chess variants

Hello, I ask our help for understand the correct process for implement the promotion of a piece in this editor: https://www.chessvariants.com/page/MSplay-test-applet-for-chess-variants

I use for example a 12x12 board and i want to make a Queen promotion with pawns in the last rank (white & black) so I set this: Promotion zone (ranks):1 Promotion choice:Q Pieces to shuffle:P

Press Apply Press start position

Unfortunately I try this mode but seems works sometimes only for the a.i. pieces...

I also want to ask how I do for also more type of promotion on the same board? For example always in a 12x12 board I want the pawn-to-queen promotion and add a new one es. the knight-to-amazon promotion, both in the last rank, or the Queen promotion in the 10th rank and the Amazon in the last...

Thank you very much for your support, Best regards.

The shuffle parameter has nothing to do with promotion; it defines how the initial setup has to be shuffled each time you start a new game, like in Chess960. Mentioning only a single piece type there has no effect. For promotionChoice you can give a list of all pieces the user can choose from when a Pawn promotes. The choice will have to be made when you move the Pawn into the zone, by clicking the desitred piece in the piece table (where available choices will be highlighted in blue). For normal Chess you would have to set it to QRBN. (Or Q,R,B,N ; it understands comma separation, which can be needed when some of the pieces have multi-letter ID.) But if you specify nothing it will assume all piece types in the initial setup except Pawn and royal.

There is a difference between the Play-Test Applet and the Interactive Diagram on which the Play-Test Applet is based. The Diagram supports many more options than those you can specify through the Play-Test Applet. The latter is a compromise between easy operation for the most common cases and versatility. In particular the Play-Test Applet assumes chess-style promotions: a single Pawn type promotes on reaching a certain rank, and the user can then choose between a number of piece types. The Diagram supports a parameter maxPromote, which can be used to specify the number of piece types that can promote. But the Play-Test-Applet automatically sets that to 1, and offers no method for the user to alter it. Even if it could be altered, it would assume all the promoting types have the same choice for the piece to promote to.

It sounds like what you want is more like a shogi-style promotion, where there is no choice (other than to promote or not), but each promoting piece type has a fixed type to which it promotes. The Diagram also supports that, through a parameter promoOffset, which would cause all promoting types to be upgraded that number of rows in the table on promotion. So which type promotes to what is then critically determied by the order of the pieces in the table. The Play-Test-Applet does not have a method to let the user specify promoOffset, and offers no control over the order of the piece types in the table (which is just inherited from the table you select the pieces from). This is mainly because I have no good idea for how to let the user specify that in an easy way (especially the order).

If you want to make the full power of the Interactive Diagram available, rather than just what the Play-Test Applet allows you to specify, the only possible course of action is to create your own web page with an Interactive Diagram (which could be on your local computer), and than edit the Diagram specification by hand to use the features that the Play-Test Applet doesn't allow you to set or alter. You can start by using the Play-Test Applet to get as close to the desired rules it allows, and then use the button at the bottom of the page to create the HTML for the Diagram. Which you could then paste into the HTML page you are making. (If you put that page not on the CVP website, but elsewhere, such as on your local computer, you would have to prefix the links it contains with http://chessvariants.com to make it work.) You then have the possibility to edit the Diagram specification in any way you want.

You could of course paste the Diagram you are working on into a comment here, submitting it in HTML mode (as Daphne did below).

Thank you very much.

I'm not very good at HTML coding but I will look what I can make.

Well, all you have to do is copy-paste what the Play-Test Applet displays after pressing the Show HTML button into the comment-entry form after selecting HTML there. That cannot be too hard...

Ok, here is the code of one of my boards... seems the promotion works only for the cpu when I paste this on the "existing diagram" so if i understood correctly from this code it is not possible to implement shogi style promotions in any mode? if yes I'm glad to see an example of a knight promotion to amazon.

Thank you again for all the support.

Why the Tiger is noted bRfBfRbBvRB? Except if I'm wrong, fBbB is simply B, then B is written twice. bRfR is simply vR, then vR is noted twice. So your Tiger is simply BvR no? I don't know if redundant notation may have an effect.

OK, to start with you should make the Diagram a bit smaller by using 35x35 pieces, as for many people it would not fit on their display now. So change the following to parameters as follows:

graphicsDir=/graphics.dir/alfaeriePNG35/
squareSize=35

The Play-Test Applet does not pay any attention to diagram appearance; if you want to color the board you will also have to provide the lightShade and darkShade parameters yourself (specifying HTML-style colors, such as #FF000 for red), and to get coordinates displayed you have to set firstRank=1.

You currently have promoChoice=z, and since z is not a valid piece ID (which are all capitals) promotion does not work. If you want the Knight to promote you should add maxPromote=2 ; that would make the first 2 pieces in your table promote. It would then use the same promoChoice, though.

To get shogi-style promotions you could add promoOffset=7 . It then ignores the promoChoice (which you could delete), but always promotes Pawn to Amazon. Because the Amazon occurs 7 places later in the piece table. The Knight would then promote to Elephant, though. So you would have to re-order the piece specification lines to put the piece you want the Knight to promote to immediately after Amazon.

@Jean-Louis: redundant moves in the move description are not fatal, but are detrimental to the AI, which would then search these moves twice and would think much longer than needed. Sometimes it is hard to avoid duplicats (e.g. in a piece like RD it would be hard to make the Rook part avoid generating a move to the D-squares too, if the adjacent square in that direction was empty).

@HG

Trying to enforce the rules to the Cetina Random Chess preset through the Play-Test Applet I get this warning:

Syntax Error on line 279

Missing both default and case "#rng" in switch

I don't know what that means nor how to fix it. Could you please take a look at it? 

Thank you again, I will consider these guide for my future project.

Now I complete the fix of the classic promotion (pawns) in the HTML-generated diagram, for both sides.

Carlos Cetina wrote on 2022-10-27 UTC

@HG

Trying to enforce the rules to the Cetina Random Chess preset through the Play-Test Applet I get this warning:

Syntax Error on line 279

Missing both default and case "#rng" in switch

I don't know what that means nor how to fix it. Could you please take a look at it? 

Well, the switch statement against which it complains should only be executed when #rng (the range of a move) is negative. The if statement around that should guarantee that. The legdefs array from which this range is taken does not contain any negative range.

So I suspect this is a case of misalignment, where the start value used in the array for the moves of a piece is 'out of register', so that numbers that represent board-step coordinates are interpreted as a range. I suspect it has to do with these lines for the Bishop Conversion:

def B cond #0 (cond flag var ori BBB cond == 1 var wstart BBB cond var wstart WWW BWBWBW) 0;
def b cond #0 (cond flag var ori BBB cond == 1 var bstart BBB cond var bstart WWW BWBWBW) 0;

These functions B and b are supposed to return the number of the starting element of the list of moves for the B and b piece in the legdefs array. I suppose they somehow return an incorrect number. Does the error disappear when you remove those lines, or just let the functions B and b return 0 always?

[Edit] It seems you have removed the lines, and the error has now disappeared. What are BBB, WWW and BWBWBW supposed to be anyway? They did not seem to be defined anywhere; their only occurrence was in those two functions.

The error disappear when removing those lines but now the conversion rule is broken. You can check it by clicking here and doing some moves by using the "PLAY someone at the same location" resource.