you have to take the squirrel with the commoner on ist first line to reproduce the promotion message.
OK, I see. This kind of sick behavior can occur with the modification I made to the input routine for handling multi-leg moves: if you click a destination that has multiple moves to it, it requires a third click to disambiguate those. (And for the first click it highlights the 'via' square rather than the final destination.) But if even after that several moves are left that match the input clicks (that are not identical; because duplicats would be removed to begin with), it just assumes that this must be because they differ in promotion choice (as apparently origin, destination and via square are the same), and throws up the promotion popup.
I don't see how in this case duplicat moves would be prodused here; the Commoner has a simple KingGraph.
[Edit] OK, I see. The move is also a move that would be induced by the Dervish on d10. This is what causes teh duplicat. But apparently it is not recognized as an exact duplicat. This comparison is very picky: even if the properties are the same, but appear in adifferent order, it doesn't think its a duplicat. I will check it out. For the efficiency of the AI it would be better if not even exact duplicats were generated. But it would be quite a hassle to figure out which types already have the move you want to induce.
[Edit2] It seems the move as it is normally generated has a extra ep: false property in it, and the induced move that I generated because of induction by the Dervish doesn't have that. So the input routine doesn't see them as duplicats, and hence assumes that they must differ in promotion piece. Not all moves appear to have this redundant ep: false property, though, so I should test carefully for when to add it.
OK, I see. This kind of sick behavior can occur with the modification I made to the input routine for handling multi-leg moves: if you click a destination that has multiple moves to it, it requires a third click to disambiguate those. (And for the first click it highlights the 'via' square rather than the final destination.) But if even after that several moves are left that match the input clicks (that are not identical; because duplicats would be removed to begin with), it just assumes that this must be because they differ in promotion choice (as apparently origin, destination and via square are the same), and throws up the promotion popup.
I don't see how in this case duplicat moves would be prodused here; the Commoner has a simple KingGraph.[Edit] OK, I see. The move is also a move that would be induced by the Dervish on d10. This is what causes teh duplicat. But apparently it is not recognized as an exact duplicat. This comparison is very picky: even if the properties are the same, but appear in adifferent order, it doesn't think its a duplicat. I will check it out. For the efficiency of the AI it would be better if not even exact duplicats were generated. But it would be quite a hassle to figure out which types already have the move you want to induce.
[Edit2] It seems the move as it is normally generated has a extra ep: false property in it, and the induced move that I generated because of induction by the Dervish doesn't have that. So the input routine doesn't see them as duplicats, and hence assumes that they must differ in promotion piece. Not all moves appear to have this redundant ep: false property, though, so I should test carefully for when to add it.