I also discovered that demotion of promoted pieces doesn't occur for captured pieces going into the hand when using Shogi-style promotions. Perhaps this can be parameterized to account for variants with different drop rules than Shogi.
Ah yes. When I implemented updating the holdings in the AI, it was purely for the purpose of selecting a promotion piece from your own captured pieces (holdingsType=1), as the AI cannot handle drops (yet). But now that the NewClick system uses the AI also for performing the moves at game level, this spoiled the holdingsType=-1 case.
For efficiency's sake I had changed the treatment of the holdings, by never flipping the color of pieces on capture, so that at game level it had to be flipped on dropping (or for displaying the number of pieces available for dropping). This was implemented, but I forgot to do the demotion. It seems best to also do that during dropping, so that it does not burden the AI in games without piece drops. To correctly display the counts for pieces with drops I added some code after performing the move at game level through the AI's move routine. This runs through the hand, and removes all promoted pieces from it, adding those to the counts of their demoted form.
For Shogi-style promotion all piece types larger than promoOffset are demoted by subtracting the promoOffset. For chess-style promotions all piece types available as promotion choice are demoted to type 1 (supposed to be the pawn). This is only done when the holdings type equals -1. This means it can be suppressed by setting holdingsType=-2, which would still flip the color on capture.
I also fixed the problem with e.p. capture in out-of-turn moves. When a piece of the same color is selected as the one that last moved, the memory of that last move (which contains the e.p. squares the move created) is suppressed during move generation for the purpose of highlighting and move selection. But immediately restored afterwards. So that you can still change your mind after a misclick, and move a piece that was on move after all, without having spoiled its e.p. rights.
Ah yes. When I implemented updating the holdings in the AI, it was purely for the purpose of selecting a promotion piece from your own captured pieces (holdingsType=1), as the AI cannot handle drops (yet). But now that the NewClick system uses the AI also for performing the moves at game level, this spoiled the holdingsType=-1 case.
For efficiency's sake I had changed the treatment of the holdings, by never flipping the color of pieces on capture, so that at game level it had to be flipped on dropping (or for displaying the number of pieces available for dropping). This was implemented, but I forgot to do the demotion. It seems best to also do that during dropping, so that it does not burden the AI in games without piece drops. To correctly display the counts for pieces with drops I added some code after performing the move at game level through the AI's move routine. This runs through the hand, and removes all promoted pieces from it, adding those to the counts of their demoted form.
For Shogi-style promotion all piece types larger than promoOffset are demoted by subtracting the promoOffset. For chess-style promotions all piece types available as promotion choice are demoted to type 1 (supposed to be the pawn). This is only done when the holdings type equals -1. This means it can be suppressed by setting holdingsType=-2, which would still flip the color on capture.
I also fixed the problem with e.p. capture in out-of-turn moves. When a piece of the same color is selected as the one that last moved, the memory of that last move (which contains the e.p. squares the move created) is suppressed during move generation for the purpose of highlighting and move selection. But immediately restored afterwards. So that you can still change your mind after a misclick, and move a piece that was on move after all, without having spoiled its e.p. rights.