Comments/Ratings for a Single Item

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

Well, I fixed the previous problem we had as Fergus suggested, by retrieving the shuffle made when the game was created from the constant 'startshuffle', like:

  if isconst startshuffle:        // shuffle has already been determined
    setsystem space @startshuffle;// retrieve it
  else:                           // new game; must shuffle
    ... // perform shuffling on $space
    setconst startshuffle $space;        // save the shuffle for persistent use
  endif;

That is, Fergus told me to write an @ before it, otherwise a wrong, uninitialized variable was retrieved, which led to a board of all white pawns. This seemed to work at the time. If you get a new shuffle now, it can only be because the test "isconst startshuffle" returns false, and it starts making a new shuffle rather than retreiving the old one (which apparently for some reason ceased to exist). If you shuffle again you are unlikely to get the same position. Perhaps Fergus knows how a constant can disappear.

@Fergus, Could you take a look at the latest on this post?

HG & Fergus

Hello, Something seems wrong with all my grand apothecary chess presets when the imitator has to move. It always imitates a pawn regardless of what the previous player does. Any of you 2 has a reason? Links Below:

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

My guess would be that the automatic code generator was never designed to handle imitators.

It worked before! Hopefully HG knows better!

HG, are you here?

It seems no one knows what happened. It worked before.

It seems the J/j piece is not defined as an imitator. In the Pre-Game code the legdefs array should be initialized for the Imitator as

1 -2  0  1   16777219 // joker(1826)
0
1 -2  0 -1   16777219 // joker(1832)
0

But instead of a -2 you now have a 1 there.

How was this Pre-Game code created? Did you paste an existing Interactive Diagram into the Play-Test Applet, or did you select the pieces one by one from the table?

To be honest I don't recall it is a long time ago. But it worked before. Anyway I'll make the change.

I have made the change and now it works! May I enquire what the -2 stands for?

Each line in the legdefs array represents the leg of a move, and contains either 5 or 4 numbers. The first leg always contains 5 numbers, the first number indicating how many legs the move has. A zero there indicates no more moves follow for that piece.

The other 4 numbers are range (1 = leaper), x-step y-step and 'mode'. The latter describes what must occupy the target square for the leg to be possible.

Ranges smaller than 1 are of course meaningless, and those are used to indicate special cases that cannot be described as a (repeated) step. Such as imitation. These 'invalid' rages are recognized, and will cause execution of dedicated GAME code to handle the particular case. E.g. -1 would be used for the variable range of Pawns moving up to the board half. A -3 would cause calling of a user-supplied GAME code subroutine for generating the move.

I guess there is currently a mismatch between how the Interactive Diagram handles imitation (indicating it by some bit in the 'mode') and how the betza.txt GAME-code include file handles it (through range = -2). It would have been the task of the Play-Test Applet to make that translation when you make it generate GAME code. I cannot recall changing any of these. But I must have, if you say it worked before. In any case I should fix the Play-Test Applet to emit the -2 as range when the mode specifies imitation.

Thanks, HG. I got it. Good luck!

HG, Actually in the following it is not about an error. But I need to figure out how to edit the already done preset so that when the joker that imitates a pawns it inherits only it's basic properties, no double move, en-passant, promotion. The way I had done that earlier was to treat the pawn separately and when it is the case that it is the last piece for it I imitate a barren pawn piece. This worked fine. But I do not know how to do it here. The diagram will still not be able to do that and that is fine for a newcomer, the game is complicated enough as is, but for the game code I think I can do it, just guide me a bit to how.

The GAME code in the betza.txt include file updates a variable 'toimitate' in its HandleMove routine, so that it will contain the ID of the piece to imitate on the next move. You could use the trick with the dummy piece also here. Say that its ID would be X or x, you could add this code in the Post-Move 1 section after the call to Handle move:

set toimitate cond == #toimitate p x #toimitate;

And in the Post-Move 2 section the same, but with capital P and X. The == #toimitate p tests whether the next piece to imitate would be a pawn, and if so, changes it to x, but otherwise leaves it as it was.

Thanks HG!

I now fixed the Play-Test Applet's GAME-code generation such that it does use the correct way for specifying a move as imitation in the 'legdefs' table it generates.

One caveat: the trick the betza.txt include file uses for determining whether moves are legal during highlighting is not reliable when imitators are present. Because it determines the pinned pieces and attacked squares before the move. And the move will usually change what the imitator is immitating. So it is recommended to use highlighting of all pseudo-legal moves, by specifying

set pseudo 1;

at the end of the Pre-Game section.

Thanks, for that HG!

It seems in the game code I can castle out of check and that should not happen.

I think it just highlights the move as legal but doesn't let you actually do it.

I verified this. You are correct!

That is a consequence of pseudo-legal highlighting. The issue of moving into / out of / through check is what makes the difference between fully legal and pseudo-legal moves.

Ok!

@HG, Hello I want to use the dummy piece trick here the way you suggested a while ago. I don't know how to define the dummy pawn (a pawn with no capture, en passant or promotion).

EDIT: I mean without having to redo the diagram from scratch.

Can you help me?