(move <from> <to>) bug

[Michael]

I have attached a .lud where one can move neutral pieces closer to the central cell, and this "transforms" them into non-neutral pieces. The bug is the following:
Even though <from> is set to (sites Occupied by:Neutral), in some cases Ludii allows the player to move from a cell not occupied by a neutral piece. Try moving one step inward from the ring next to the outer ring. What happens is that the next player is allowed to move from the non-neutral piece you just "created".

Here is an image of the situation (the grey circles are neutral pieces):

Edit: If I use (forEach (sites Board) if:(= 0 (who at:(site)))) instead of (sites Occupied by:Neutral) the problem disappears.

[Eric Piette]

Hi,

I tried the file you shared and I did not get that issue.
Do you have a trial for me to reproduce the problem?

Regards,
Eric

[Michael]

Hi,

I tried the file you shared and I did not get that issue.
Do you have a trial for me to reproduce the problem?

Regards,
Eric

Here are the moves that lead to the issue illustrated in the image.

[Eric Piette]

Hi,

Ok I finally fixed the bug in our dev version. That will be published with the next release (probably today or tomorrow).
That was a pretty complex bug to understand for a rare case in reality with no link with the neutral pieces, so this is good to detect it and fixed it. Thanks for the report.

Because you move a piece type on another piece of the same type. Then add another piece type on the (last From) location and swap these pieces.
But, when you move a piece type on another of the same piece type, in reality the count should be two. Because the "what" data is the same but you have now 2 pieces of the same type on that site (so the "count" data of that site should be 2). However if the game does not activate the count, the piece at the (to) location has to be removed before to place the new piece (even if that's the same piece type). And to detect the "occupied" sites we have different internal structures in Ludii and for that specific case, the data of that structure was not correct.

Anyway that's now fixed ;)

Thanks for that.

Regards,
Eric