Check out Balbo's Chess, our featured variant for October, 2024.


[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments/Ratings for a Single Item

Earlier Reverse Order LaterLatest
Grand Apothecary Chess-Classic. Very large Board variant obtained trough tinkering with known games.[All Comments] [Add Comment or Rating]
💡📝Aurelian Florea wrote on Sat, Apr 24, 2021 04:44 AM UTC:

This article is ready for review.


💡📝Aurelian Florea wrote on Sun, Apr 25, 2021 09:26 AM UTC:

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.


💡📝Aurelian Florea wrote on Thu, May 6, 2021 09:26 AM UTC in reply to Aurelian Florea from Sun Apr 25 09:26 AM:

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


💡📝Aurelian Florea wrote on Tue, May 18, 2021 06:48 AM UTC:

May an editor look over this article?


💡📝Aurelian Florea wrote on Thu, Aug 26, 2021 06:20 AM UTC:

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.


H. G. Muller wrote on Thu, Aug 26, 2021 08:12 AM UTC:

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


💡📝Aurelian Florea wrote on Thu, Aug 26, 2021 09:34 AM UTC in reply to H. G. Muller from 08:12 AM:

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

H. G. Muller wrote on Thu, Aug 26, 2021 09:56 AM UTC:

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.


💡📝Aurelian Florea wrote on Thu, Aug 26, 2021 11:08 AM UTC in reply to H. G. Muller from 09:56 AM:

Thanks, HG!


💡📝Aurelian Florea wrote on Thu, Aug 26, 2021 11:54 AM UTC in reply to H. G. Muller from 09:56 AM:

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


💡📝Aurelian Florea wrote on Fri, Aug 27, 2021 04:56 AM UTC in reply to Aurelian Florea from Thu Aug 26 11:54 AM:

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.


H. G. Muller wrote on Fri, Aug 27, 2021 10:13 AM UTC in reply to Aurelian Florea from 04:56 AM:

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.


H. G. Muller wrote on Sat, Aug 28, 2021 04:43 PM UTC in reply to Aurelian Florea from 04:17 PM:

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


💡📝Aurelian Florea wrote on Sat, Aug 28, 2021 05:15 PM UTC in reply to H. G. Muller from 04:43 PM:

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


💡📝Aurelian Florea wrote on Sat, Aug 28, 2021 05:24 PM UTC in reply to H. G. Muller from 04:43 PM:

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.


H. G. Muller wrote on Sat, Aug 28, 2021 05:36 PM UTC in reply to Aurelian Florea from 05:24 PM:

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.


H. G. Muller wrote on Sun, Aug 29, 2021 09:52 AM UTC:

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 Duniho wrote on Sun, Aug 29, 2021 03:22 PM UTC in reply to H. G. Muller from Sat Aug 28 05:36 PM:

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


H. G. Muller wrote on Sun, Aug 29, 2021 03:46 PM UTC:

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.


💡📝Aurelian Florea wrote on Sun, Aug 29, 2021 06:09 PM UTC in reply to H. G. Muller from 03:46 PM:

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


🕸Fergus Duniho wrote on Sun, Aug 29, 2021 06:31 PM UTC in reply to H. G. Muller from 03:46 PM:

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.


H. G. Muller wrote on Sun, Aug 29, 2021 08:48 PM UTC in reply to Fergus Duniho from 06:31 PM:

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.


Greg Strong wrote on Sun, Aug 29, 2021 09:10 PM UTC in reply to H. G. Muller from 08:48 PM:

You can browse the available include files here.

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


🕸Fergus Duniho wrote on Sun, Aug 29, 2021 10:18 PM UTC in reply to H. G. Muller from 08:48 PM:

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.


25 comments displayed

Earlier Reverse Order LaterLatest

Permalink to the exact comments currently displayed.