[ 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⇧ Latest⇩

Apothecary Chess-Classic. Large board variant obtained through tinkering with known games.[All Comments] [Add Comment or Rating]

💡📝Aurelian Florea wrote on Thu, Jul 2, 2020 08:51 AM UTC:

@ Fergus,

I have found the mistake.
This piece of code was missing and adding it has solved the problem.

if == moved K:
unsetflag f2;
set Kpos $dest;
endif;

💡📝Aurelian Florea wrote on Fri, Jul 3, 2020 11:38 AM UTC:

@Fergus,

I have unfortunately uncovered another bug on the preset for this game.

The joker can't move when imitating a pawn, although the moves are properly displayed. Any idea why?

🕸Fergus Duniho wrote on Fri, Jul 3, 2020 05:02 PM UTC:

Since it works for displaying legal moves, it's probably because the Pawn functions are only for potential moves, and the Joker is trying to use one of the Pawn functions when making an actual move. Specifically, I think it fails on the line "and empty #1" in the Pawn function, because that space is occupied for an actual move. Some options include changing your rules, rewriting the Pawn functions to handle both potential and actual moves, or using a Joker subroutine for actual moves, which would let you undo the Joker's move before testing it with a function, then redoing it if it is legal.

💡📝Aurelian Florea wrote on Mon, Jul 6, 2020 12:29 PM UTC:

@Fergus

The way I had thought the game, the joker should, when imitating a pawn, get only the regular power and not promotion rights or double move privileges. And that works best with moving some of the lines in the pawn function to the pawn subroutine. It should be rather easy.

🕸Fergus Duniho wrote on Mon, Jul 6, 2020 01:28 PM UTC:

I wouldn't recommend that. That doesn't sound like the correct solution to your problem.

💡📝Aurelian Florea wrote on Mon, Jul 6, 2020 01:41 PM UTC:

Ok, thanks for the heads up. I'll try to think at something else.

💡📝Aurelian Florea wrote on Tue, Jul 21, 2020 01:13 PM UTC:

@Fergus

A few weeks ago I have figured out that the joker imitates the pawn in all things which causes the joker moves to not be allowed.

To tackle this issue I have decided to write a Barren_Pawn function that the joker will use when imitating a pawn instead of imitating the regular pawn function. Otherwise things are unchanged. The Barren_Pawn functions are:

def White_Barren_Pawn checkaleap #0 #1 1 0 and empty #1 islower space #1 and or checkaleap #0 #1 1 -1 checkaleap #0 #1 1 1;

def White_Barren_Pawn-Range merge leaps #0 1 0 leaps #0 1 1;

def Black_Barren_Pawn checkaleap #0 #1 -1 0 and empty #1 isupper space #1 and or checkaleap #0 #1 -1 -1 checkaleap #0 #1 -1 1;

def Black_Barren_Pawn-Range merge leaps #0 1 0 leaps #0 1 1;

The piece of code involving the joker imitation is:

if != const alias $moved White_Joker:
if != const alias $moved Pawn:
set last_type_moved const alias $moved;
else:
set last_type_moved White_Barren_Pawn;
endif;
endif;

and for black:

if != const alias $moved Black_Joker:
if != const alias $moved Pawn:
set last_type_moved const alias $moved;
else:
set last_type_moved Black_Barren_Pawn;
endif;
endif;

I thought it should easily work. Unfortunately it does not. Any idea why that is?

H. G. Muller wrote on Tue, Jul 21, 2020 02:05 PM UTC:

Is that minus sign in Pawn-Range intended, or is it a typo for an underscore?

🕸Fergus Duniho wrote on Tue, Jul 21, 2020 03:39 PM UTC in reply to H. G. Muller from 02:05 PM:

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 Tue, Jul 21, 2020 03:43 PM UTC in reply to Aurelian Florea from 01:13 PM:

It 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 Tue, Jul 21, 2020 07:32 PM UTC:

I 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 Tue, Jul 21, 2020 07:46 PM UTC in reply to Aurelian Florea from 07:32 PM:

The 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 Wed, Jul 22, 2020 03:41 AM 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?

🕸Fergus Duniho wrote on Wed, Jul 22, 2020 12:58 PM UTC in reply to Aurelian Florea from 03:41 AM:

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 Wed, Jul 22, 2020 02:55 PM UTC:

I 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 Wed, Jul 22, 2020 03:14 PM UTC in reply to Aurelian Florea from 02:55 PM:

I 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 Wed, Jul 22, 2020 03:41 PM UTC:

It works well. I hope there are no more bugs. Thanks Fergus!

💡📝Aurelian Florea wrote on Wed, Sep 23, 2020 03:54 PM 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 Wed, Sep 23, 2020 09:59 PM UTC in reply to Aurelian Florea from 03:54 PM:

I suppose you need a symmetry=none line in the diagram definition. It is probably reflecting the other Joker now.

💡📝Aurelian Florea wrote on Thu, Sep 24, 2020 04:16 AM UTC:

@HG, Indeed that has solved it. Thanks!

💡📝Aurelian Florea wrote on Thu, Sep 24, 2020 05:07 AM UTC:

@HG, ... But it has introduced another problem. Now the shuffling of pieces is not simtrical anymore :(!

💡📝Aurelian Florea wrote on Sat, Sep 26, 2020 03:29 AM UTC in reply to H. G. Muller from Wed Sep 23 09:59 PM:

@HG : And I could not find a solution on my own :(!

H. G. Muller wrote on Sat, Sep 26, 2020 10:03 PM UTC:

I 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 Sun, Sep 27, 2020 08:20 AM UTC:

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