Comments/Ratings for a Single Item

Actually while testing with the interactive diagram I have noticed some undesired results. So I'm modifying a bit the game. Please allow me some more time.

To the editors. Now this article is ready for review.

May an editor look over this article?

Hello HG,

The Grand Apothecary alert game automatically generated preset work well as far as I can see.

Now I need to make my other two Grand apothecary chess games work. When I paste the diagram designer code into the playtest applet, the applet gets it, but I cannot for some reason press the game code button.

I cannot test that when I don't know what exactly you are trying to paste.

files=12

  ranks=14

  symmetry=none

  holdingsType=1

  promoZone=4

  promoChoice=!P!X*N*B*L*E*Z*R3*Y3*F3*J3*D2*Q2*I2*T2*U2

  graphicsDir=../graphics.dir/alfaerie/

  whitePrefix=w

  blackPrefix=b

  graphicsType=gif

  squareSize=54

  hole::::a1-l1,,a14-l14

  pawn:P:mfW*fceF:pawn:b4-k4,f5,g5,,b11-k11,f10,g10

  berolina:X:mfF*fceW:berolinapawn:a4,l4,c5,j5,,a11,l11,c10,j10

  king:K:KisO3isO4isjO2isjO3:king:g2,,g13

  rook::::a3,l3,b2,k2,,a12,l12,b13,k13:1

  queen::::f2,,f13:1

  bishop:B:B:bishop:c3,j3,,c12,j12:2

  knight:N:NmZ:knight:b3,k3,,b12,k12:1
  mamluk:L:WL:/graphics.dir/alfaeriemisc/compounds/%camelwazir:d2,i2,,d13,i13:1

  siege elephant:E:FAH:/graphics.dir/alfaeriemisc/good/%elephantferzrook:e3,h3,,e12,h12

  cannon:Z:mRcpR:cannon:a2,l2,,a13,l13

  knightrider:Y:NN:nightrider:c2,j2,,c13,j13:1

  caliph:H:BL:/graphics.dir/alfaerie/%camelbishop:f1,g1,,f14,g14
  vulture:F:afafafsKafsafafKafafraflKafaflafrKafraflafKaflafrafKmA:bird:d3,i3,,d12,i12

  joker:J:fI:fool:e1,h1,,e14,h14

  Dragon:D:FyafsF:dragon:f3,,f12

  Thunderbird:T:WB3afafyasfF:/graphics.dir/alfaerie-fpd/%thunderbird:h2,,h13

  Unicorn:U:BNN:unicorn:e2,,e13

  Firebird:I:FR2afyasfW:/graphics.dir/alfaerie-fpd/%firebird:g3,,g12

  symmetry=mirror

  shuffle=:B:N:E:F,QUT,DI,:L:Y

  maxPromote=2

  royal=3

OK, my bad. I had made a change recently in the script that flushes the GAME code, to allow for variants that start counting ranks at 0. The diagrams you can define with the Play-Test Applet always start counting ranks at 1, but when I added the possibility to paste existing diagrams into the Applet, this was no longer true. With as a result that the locations of the castling partners were not calculated properly. But when I corrected that by adding the variable rank1 to the internal rank number, in one place I had accidentally typed rank11. Which crashed the script.

I have deleted the spurious 1, and now it works again.

Thanks, HG!

I have created presets for all the 3 games. Now I'm going to test them. Hopefully there are no errors.

There is some problem with the rank labels. I had tried to change it from 0-13 to 1-14 but there are still problems. When 0-13 was the case I had brouhaha squares on rank "1" and pieces on rank "0" were no able to move. This is not suppose to happen. When I had changed it to 1-14 it was even worse. I could not understand what is going on. All hell broke loose.

If you post a link to a preset that doesn't work as it should, I can have a look at it. I am a bit surprised the rank labeling matters much. Of course in the Interactive Diagram the firstRank parameter should be consistent with the lists of square coordinates you give for all the pieces. But if the initial setup looks OK in the Diagram, producing GAME code from it would depend on firstRank only in very few (and non-essential) places. The initial position is defined by FEN, and thus doesn't use any square coordinates. The only info that is encoded as square coordinates in the generated Pre-Game code that I can think of is the location of the castling partners. But even if that would be completely wrong, it just means that you can never castle.

HG.

https://www.chessvariants.com/play/pbm/play.php?game=Grand+Apothecary+Chess+1&settings=Applet

https://www.chessvariants.com/play/pbm/play.php?game=Grand+Apothecary+Chess+2&settings=Applet

https://www.chessvariants.com/play/pbm/play.php?game=Grand+Apothecary+Chess+3&settings=Applet

Those above are the presets. I noever specified a fist rank parameter. What seems to be the problem.

So what is wrong with those? They seem to work normally when I use them in 'Play' mode.

I can't reproduce said bug. Maybe it was something temporary!

But I had a new bug here: https://www.chessvariants.com/play/pbm/play.php?game%3DGrand+Apothecary+Chess+3%26settings%3DApplet

Neither the siege elephant or the mamluk works. Also in the the three games as I had said below the non-joker pieces on the brouhaha squares cannot move. I have not checked the jokers.

I notice that the piece labels for Mamluk and Seige Elephant both start with a period. Have you tried whether the Caliph works? (It also has a label starting with period.)

@Fergus: can there be a problem with functions that have a name starting with a period? The GAME code generated by the Play-Test Applet generates functions with the name of the piece label, which return the start index of their move description in the legdefs array.

I can confirm that the Mamluk and Seige Elephant properly work when I replace the symbols used for them (.JW and .ET) by an ordinary Camel and Elephantrider, the labels of which do not start with a period (J and EE). In the startup FEN and in the functions defined for the pieces near the end of the Pre-Game section.

@Fergus: Did you see my question about this, amidst the flurry of postings that appeared yesterday?

@Fergus: can there be a problem with functions that have a name starting with a period?

It would appear so. I ran this code to test this:

def cat * 2 #0;
def .dog *2 #0;
set p fn cat 8;
set q fn .dog 8;
dump;

And the result I got was this:

array(1) {
  [0]=>
  array(1) {
    ["main"]=>
    array(2) {
      ["p"]=>
      int(16)
      ["q"]=>
      array(2) {
        [0]=>
        string(1) "8"
        [1]=>
        string(2) "*2"
      }
    }
  }
}

This may be because GAME Code uses the period to separate array elements from arrays. I would recommend using aliases (old way) or rewriting the $piece array (new way) to avoid the need for writing functions with names that start with a period.

I am not completely convinced yet: in your example it is clear that the function definition of .dog is used to generate the output. I think the unexpected result is due to a space missing between * and 2 in the .dog definition.

The problem could be in onlyupper / onlylower, which I use for iterating over the pieces of the player on move for generating moves. This might not recognize the piece labels starting with the period. I guess I would have to loop over all pieces, and just test piece by piece using the fnmatch "*[a-z]*".

Of course it would solve a lot of problems to get rid of this madness of piece sets with non-alphabetic names. If I understood the 'new method' correctly, it would require help of an editor to define a new piece set in a PHP file. Perhaps we could make an adapted version of the 'all pieces'  Alfaerie set that assigns sensible labels to all pieces. Then we would never have to use anything else again.

I agree with HG. .stuff and 1stuff are a nuisance. But it probably takes a lot of work.

I think the unexpected result is due to a space missing between * and 2 in the .dog definition.

Yes, when I corrected that, .dog gave me the correct result.

If I understood the 'new method' correctly, it would require help of an editor to define a new piece set in a PHP file.

No, the new method was provided to eliminate the need to make new set files. I have now written a subroutine that will do the job once you feed it the data. It is in the include file update-piece-set, and the subroutine is called update-piece-set. Just feed it the notation you will use. To make preparation of data easier, you may feed it all the data it needs in a single array. Each array element should be a single piece label or an array including the piece label first and the new notation second. Where a piece label is by itself, it will reuse the same label for the same piece. Where it comes paired with new notation, it will use the new notation for the piece and discard the old piece label.

This method allows the designer to write the FEN code using the original labels, but within the code, it will change the piece labels to the desired notation, and it will strip the $pieces array of all pieces not being used.

You may get data on what notation to use from the user. For each piece, just include an extra field on what notation to use for the piece. When it's left empty, use the original piece label.

Where can I find this include file?

BTW, I did stumble on the method for defining a piece set through assigning to $pieces. Perhaps this is the best method to convert Interactive Diagrams to GAME code, as these Diagrams do specify the filenames of the piece images, the directory where these images are to be found, and the piece IDs (which can be used as labels). So it would just be a matter of dumping this internally held info in the form of a GAME-code associative array, in the code generated for the Pre-Game section.

You can browse the available include files here.

Populating $pieces with the correct info seems like the way to go

Where can I find this include file?

It's in the includes directory. So, you just include it by name.

BTW, I did stumble on the method for defining a piece set through assigning to $pieces. Perhaps this is the best method to convert Interactive Diagrams to GAME code, as these Diagrams do specify the filenames of the piece images, the directory where these images are to be found, and the piece IDs (which can be used as labels). So it would just be a matter of dumping this internally held info in the form of a GAME-code associative array, in the code generated for the Pre-Game section.

Yes, that could work, though there is one caveat. When Game Courier is in Edit mode, it does not run any code unless someone clicks Run. This is a safety precaution to allow someone to edit buggy code that would otherwise disable the preset. Consequently, the board may not look right in Edit mode until someone clicks Run. If you use a set file in conjunction with the update-piece-set subroutine, though, it will avoid that problem. However, there could be a discrepancy between the labels used for the FEN code and the notation used in the preset.

To avoid that discrepancy, I was thinking of letting custom piece sets be stored as constants. However, constants are stored in logs, not in settings files. So, I'm not sure I have a good solution for this yet.