[ 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 ⇧Earliest ⇧Earlier ⇧Reverse Order⇩ Later Apothecary Chess-Classic. Large board variant obtained through tinkering with known games.[All Comments] [Add Comment or Rating]H. G. Muller wrote on 2020-07-21 UTCIs that minus sign in Pawn-Range intended, or is it a typo for an underscore? Fergus Duniho wrote on 2020-07-21 UTC Is that minus sign in Pawn-Range intended, or is it a typo for an underscore? It's a hyphen, not a minus sign, and it is not a typo. Fergus Duniho wrote on 2020-07-21 UTCIt doesn't work, because you are testing the codename of the piece, but Pawn is not the codename for any piece. It is the display name for the pieces with the codenames of Black_Pawn and White_Pawn. Aurelian Florea wrote on 2020-07-21 UTCI have corrected the post move code to: if != const alias $moved White_Joker: if != const alias $moved White_Pawn: set last_type_moved const alias $moved; else: set last_type_moved Black_Barren_Pawn; endif; endif; and similar for black. This code works. But the Barren_Pawn worked fine when I had done only the move part of the pawn's powers but now I have added the capture part and nothing is legal anymore. Please help if you may! The code in question is: def Black_Barren_Pawn checkaleap #0 #1 0 -1 and cond empty #0 not capture empty #1 or checkleap #0 #1 -1 -1 or checkleap #0 #1 1 -1 and cond empty #0 capture isupper space #1; Fergus Duniho wrote on 2020-07-21 UTCThe first thing it does is require that the move is a capture. If it is not a capture, it will not proceed any further. Aurelian Florea wrote on 2020-07-22 UTCI'm confused about what you want to say. Isn't it that : and cond empty #0 capture isupper space #1; does exactly that, capture for actual moves, and isupper space #1 checks for a potential victim in potential moves? Where am I wrong? Fergus Duniho wrote on 2020-07-22 UTC I'm confused about what you want to say. Isn't it that : and cond empty #0 capture isupper space #1; does exactly that, capture for actual moves, and isupper space #1 checks for a potential victim in potential moves? Where am I wrong? That's not the issue. The issue is that and has only one value. With only one value, it is a breaking and, which means that it will immediately exit the function and return false if the value it receives is false. See the "Breaking Logic" section in the tutorial on the fairychess include file for details. Aurelian Florea wrote on 2020-07-22 UTCI have corrected the mistake and now it goes like this: def White_Barren_Pawn checkaleap #0 #1 0 1 and cond empty #0 not capture empty #1 or and checkaleap #0 #1 -1 1 or checkaleap #0 #1 1 1 cond empty #0 capture islower space #1; def White_Barren_Pawn-Range merge leaps #0 1 0 leaps #0 1 1; def Black_Barren_Pawn checkaleap #0 #1 0 -1 and cond empty #0 not capture empty #1 or and checkaleap #0 #1 -1 -1 or checkaleap #0 #1 1 -1 cond empty #0 capture isupper space #1; But during my tests I came across the fact that a joker imitating a barren_pawn does not have the ability to capture another joker (although it is fine when capturing a knight). Fergus Duniho wrote on 2020-07-22 UTCI think this would work better. I moved an or and reformatted it to show the logic better. def White_Barren_Pawn checkaleap #0 #1 0 1 and cond empty #0 not capture empty #1 or and or checkaleap #0 #1 -1 1 checkaleap #0 #1 1 1 cond empty #0 capture islower space #1; def Black_Barren_Pawn checkaleap #0 #1 0 -1 and cond empty #0 not capture empty #1 or and or checkaleap #0 #1 -1 -1 checkaleap #0 #1 1 -1 cond empty #0 capture isupper space #1; Aurelian Florea wrote on 2020-07-22 UTCIt works well. I hope there are no more bugs. Thanks Fergus! Aurelian Florea wrote on 2020-09-23 UTC@HG, Hello, The interactive diagram on this page puts in the initial position an extra black joker outside of those defined. Why is this happening? H. G. Muller wrote on 2020-09-23 UTCI suppose you need a symmetry=none line in the diagram definition. It is probably reflecting the other Joker now. Aurelian Florea wrote on 2020-09-24 UTC@HG, Indeed that has solved it. Thanks! Aurelian Florea wrote on 2020-09-24 UTC@HG, ... But it has introduced another problem. Now the shuffling of pieces is not simtrical anymore :(! Aurelian Florea wrote on 2020-09-26 UTC@HG : And I could not find a solution on my own :(! H. G. Muller wrote on 2020-09-26 UTCI guess the current diagram script cannot do this, because the specified symmetry is applied both to the shuffling and to the setup. You seem to want a point-symmetrical setup, (symmetry=rotate) but then a line-symmetric shuffle (symmetry=mirror). H. G. Muller wrote on 2020-09-27 UTCThis night the following occurred to me: I normally write a Diagram definition by first specifying all parameters, and then all pieces. Although some parameters (such as the board size) must be set before placing any pieces, in general there is no need for this ordering, and parameter definitions and piece definitions can be mixed in any order. Furthermore, it is not an offense to specify the same parameter multiple times with different value; each definition simply replaces any previous value, so that the value from the last definition prevails. You could therefore try the following: start with a line symmetry=none amongst the parameter settings. Then specify all pieces with their locations. Because at the time of their processing the symmetry is set to none, it will not automatically place any mirror images, and you specify the squares of both white and black pieces in any way you want. After defining all pieces, you add a line symmetry=mirror . This will alter the symmetry spec, but this new spec will not be used during setup, which is already done. It will be used during shuffling, though, which occurs after the entire Diagram definition is read. Aurelian Florea wrote on 2020-09-27 UTCThanks so much HG. very cool tool you have made! Aurelian Florea wrote on 2020-09-27 UTCI have played this game against the interactive diagram's AI. It takes less time that an game courier match and I wanted to see how the games feel after the final changes I have made. The game seems to be very tactical now with many strong pieces quickly engaging . I'm really unsure about how good the game is. It's learning curve is quite steep but maybe once properly learned it is fun. I was hoping that more experienced player will take a look and try to play against the interactive diagram until the endgame (me I always blunder something before the endgame). Aurelian Florea wrote on 2020-09-28 UTCI have switched the places of osprey and mamluk in the opening position in order to give more opening opportunities. Aurelian Florea wrote on 2020-10-02 UTC files=10 ranks=12 symmetry=none holdingsType=1 promoZone=4 promoChoice=!P*N*B*L*E*R3*J3*A2*Q2*C2 graphicsDir=../graphics.dir/alfaerie/ whitePrefix=w blackPrefix=b graphicsType=gif squareSize=54 hole::::a1-j1,,a12-j12 pawn:p:ifmnDfmWfceF:pawn:a4,b4,c4,d4,e4,f4,g4,h4,i4,j4,,a9,b9,c9,d9,e9,f9,g9,h9,i9,j9 rook::::a2,j2,,a11,j11:1 queen::::e3,,e10:1 bishop:B:B:bishop:d3,g3,,d10,g10 knight:N:NmZ:knight:c3,h3,,c10,h10:1 mamluk:L:WL:camel:d1,g1,,c12,f12:1 siege elephant:E:FAH:elephant:e1,h1,,d12,g12 joker:J:fI:fool:f1,,e12 Chancellor:C:RN:chancellor:i3,,i10 archbishop:A:BN:cardinal:b3,,b10 king:K:KimbsLimbsN:king:f3,,f10 symmetry=mirror shuffle=A:BC,:BN,ACQ I have tried this week to add a rider piece. Unfortunately this proved to make the game worse as more opening moves were forced. So I reverted to an earlier version while keeping the idea that black has more pieces on the non-king side. This will be the final apothecary chess-classic game. I'm satisfied with the game. Kevin Pacey wrote on 2020-10-08 UTC@H.G. (or Aurelian): I tried playing the AI for this variant as White a couple of times, and in one game some things happened that apparently shouldn't have. Unfortunately I don't have the exact position or a record of the game, but here are the relevant details that may be all that's needed: White: Pawn e7,f6; Rook f1; King i1 Black: Pawn d6,e8,f8; Bishop g9; King f9. I tried touching my pawn on e7 and the Black pawn on f8 was lit in red, while the empty square f7 lit in green. I then tried 1.Pe7xpf8 and Black's pawn on f8 took my pawn on e7 instead - at no point did I specify what to promote my e7-pawn to, yet (there's already been at least the Archbishops traded and a bishop of mine traded for a knight). After that, I simply elected to recapture Black's (improperly arrived) e7 pawn with my f6 pawn, to see what would happen. At that point I was allowed to make a second move in a row, which I used to capture Black's king with my Rook on f1 on a now open file, and I was told that the program had lost. Any ideas what might have happened for such a case? Aurelian Florea wrote on 2020-10-08 UTCHave you used the diagram in the article or the one in the comments section? H. G. Muller wrote on 2020-10-08 UTCWell, it is hard to say without knowing exactly how you clicked. I can elucidate some general aspects of the Diagram, though: The Diagram does not enforce turn order. Hence you can always make as many moves in a row as you want. If the AI is switched on, however, it will always reply to every move with a move of the other player. This causes some alternation of turns, but would not preclude you from moving for the side that the AI just moved for. A click on a piece that is not highlighted as a valid target for a piece that was clicked before, will select that former piece, instead of any previously selected one. So it is not possible to enter illegal captures. Clicking an empty square will always move the selected piece there, whether it is legal or not. When a Pawn enters the promotion zone, and the piece table below the board is open, a message will appear (on red background) above the board requesting you to select a piece from the table to promote to. The table should then have highlighted (in light blue) all the piece types that are available. If the table is closed, however, a pawn entering the zone will automatically promote to a default piece, (the piece mentioned first in the promoChoice parameter of the Diagram) whether this is available or not. This is perhaps something I should improve on, e.g. by automatically opening the table and then following the same procedure as above. If I must hypothesize on what happened, I would think you had the table open, but missed the request to select a piece (perhaps because it was out of view). When nothing happened after you clicked f8 you got confused about whether the click had succeeded, and clicked it again. (Or perhaps your mouse button 'bounced', and accidentally produced a double click.) But this click, instead of a click in the table for selecting a promotion piece, aborted the promotion move, and instead selected the black Pawn. This added to the confusion, and you tried to redo the entry completely, by clicking your own Pawn again. But this Pawn was a valid target for the (now selected) black Pawn (which, unlike the white Pawn, was not waiting for a promotion choice to be made). So what you intended as a first click for your move, was in fact interpreted as a second click for a black move, which was then executed (Pf8xe7). Kevin Pacey wrote on 2020-10-09 UTCI started using the AI in the Classic version's article as of last night, when I had the experience I wrote of in my last post. It's quite possible I did what H.G. supposed I might have. A frustrating part of using my Windows 10 laptop is that mouse-slips seem to happen fairly often for me - particularly increasing or decreasing the font size without intending to, when on websites, happens a lot (I use [cntr]+ or - to get it back to 100% (normal) font size). I also accidently moved a piece I didn't intend to, one time, when moving too quickly. 25 comments displayed⇧Earliest ⇧Earlier ⇧Reverse Order⇩ LaterPermalink to the exact comments currently displayed.