Ludii Forum
Incorrect behaviour induced by unrelated changes - Printable Version

+- Ludii Forum (https://ludii.games/forums)
+-- Forum: Problems (https://ludii.games/forums/forumdisplay.php?fid=5)
+--- Forum: Ludii Player Problems (https://ludii.games/forums/forumdisplay.php?fid=6)
+--- Thread: Incorrect behaviour induced by unrelated changes (/showthread.php?tid=347)



Incorrect behaviour induced by unrelated changes - slimy_asparagus - 12-24-2020

I have managed to isolate the bug I mentioned in the "pass Dialog" thread. The attached .lud file works correctly. To see the effect you need to have legal moves showing turned on.

The test moves are that P1 moves from 113 to 147 and then onto 181. Nothing should be removed from the board and you should then be able to move onto 149, which will remove the piece at 165.

However if you uncomment the line "// (place "Leader1" {87})" then suddenly it does not work correctly. The move from 113 to 147 works. But the move from 147 to 181 creates a legal move of touching 164, which should not be legal.

The problem seems to disappear if instead of placing the piece at 113 I place it at 147 and skip the first move.

Also once the bug has been triggered you can no longer restart the game. You have to close Ludii and start again.


RE: Incorrect behaviour induced by unrelated changes - Eric Piette - 01-04-2021

Hi,

Ok that's not a bug but a problem in your description.
I will not be specific to the case where the leader piece is there or not but just explaining in a general way.

Your play moves are:


Code:
(play
    (or
        (forEach Piece)
        (if "SameTurn"
           (move Pass)
        )
    )
)

So here, at any move you check the move generator in each piece and if the move is in the same turn you can pass.

BUT in the move generator, you check also the "SameTurn" for the movement of the piece.
Consequently for each piece you will check that in allowing a (move Hop ....) from the last To.
That is a problem.

That "SameTurn" check, should not be in the piece generator but in the (play ...) with the (move Pass ...) because that move is not related to each piece but to the last piece moved.

For the GUI bug you mentioned with your example with the leader piece and the restart of the game, that's something else not related to that issue, but I notified Matthew and he will fix it.

Regards,
Eric


RE: Incorrect behaviour induced by unrelated changes - slimy_asparagus - 01-04-2021

Thanks Eric,

I am a little puzzled because in this other thread (pass Dialog), you said the code was fine. And that was doing exactly the same thing of having "SameTurn" in both the move generator and the <play> section. I am still thinking through what the implications of  "SameTurn" only being allowed in the <play> section would be.


RE: Incorrect behaviour induced by unrelated changes - Eric Piette - 01-04-2021

Hi,

That was fine according to the problem exposed.
But yes in the pieces moves generator, only the moves related to all the pieces of that type should be in it. For any special case such as that one, that should not be in that to compute what you expect.

Regards,
Eric


RE: Incorrect behaviour induced by unrelated changes - slimy_asparagus - 01-05-2021

I have worked out how I am going to restructure this code so that all the moves are inside the play rules. However I get stuck, when I get back to adding in "move Hop". I have simplified back down to a new test file.

I just get a load of VC_ERRORS and no pieces are shown. I can get normal step moves to work. It is just the "move Hop" bit.


RE: Incorrect behaviour induced by unrelated changes - Eric Piette - 01-05-2021

Hi,

That's a bug. I fixed it.

However, I saw in your description you are using a RegionFunction in the (from ...) of Hop and not an IntFunction
That will not work as you expect. If no IntFunction is provided in entry of Hop, the default is used which is (from) corresponding to the site of each piece in calling (forEach Piece) in the play rules.
I advise you to define this hop move in the piece generator and to use (forEach Piece).

Regards,
Eric


RE: Incorrect behaviour induced by unrelated changes - slimy_asparagus - 01-06-2021

(01-05-2021, 04:51 PM)Eric Piette Wrote: I advise you to define this hop move in the piece generator and to use (forEach Piece).

Eric,

Earlier in the thread you advised me to move the "SameTurn" out of the piece generator into the <play> section:


(01-04-2021, 09:13 AM)Eric Piette Wrote: That "SameTurn" check, should not be in the piece generator but in the (play ...) with the (move Pass ...) because that move is not related to each piece but to the last piece moved.
I was in the process of attempting to do that, but I hit the current problem before I ever got as far as putting the "SameTurn" check back in.

That is why I am now presenting you with my attempt to put a "move Hop" in the <play> section.

You are telling me to do A, and then when that fails, telling me to do B. And when B fails you tell me to do A.

Now as it happens I can see a way to do it either way.

If I am going to put everything in the <play> section, then I need to know how to make "move Hop" work there. I have reread your explanation and I think I get what you are trying to say. However I was not able to use it to make "move Hop" work in the play section. In particular why can I make a "move <from> <to>" work in the <play> section but not a "move Hop"?

If I am going to put everything in the piece generator, then I need to have only  one sort of piece for each player (so it is like the example in the Pass Dialog thread) and I will simply distinguish major and minor versions of the piece by their state (or perhaps value).
However that seems to hit an issue. For this approach to work I believe I need to do something like:


Code:
// #1 - Name of piece
(define "MinorPieceGraphics"
    (piece Rename piece:#1 "disc" state:0)
)
(define "MajorPieceGraphics"
    (piece Rename piece:#1 "pawn" state:1)
)

So we rename the piece differently depending on the state.

So which of these two approaches is more feasible?

1. having "move Hop" in the <play> section
2. having Rename take "state" into account.


RE: Incorrect behaviour induced by unrelated changes - Eric Piette - 01-06-2021

Hi,

On the other thread I told you to put all the stuff related to all the pieces in the move generator of the piece in calling (forEach Piece) and everything which is more specific (so not related to ALL the pieces) not in the move generator.
So for your cases, a pass move or something for one single piece to replay in checking "SameTurn" that's not for all the pieces so that should not be in the move generator of a piece, but for a hop move for ALL the pieces that should be in the move generator of the piece.

You can not simply say I want to put everything in the play or everything in the move generator. Each part of the logic has a right place according to what you want them to do.

Regards,
Eric


RE: Incorrect behaviour induced by unrelated changes - slimy_asparagus - 01-07-2021

(01-06-2021, 07:50 AM)Eric Piette Wrote: Hi,

On the other thread I told you to put all the stuff related to all the pieces in the move generator of the piece in calling (forEach Piece) and everything which is more specific (so not related to ALL the pieces) not in the move generator.
So for your cases, a pass move or something for one single piece to replay in checking "SameTurn" that's not for all the pieces so that should not be in the move generator of a piece, but for a hop move for ALL the pieces that should be in the move generator of the piece.

You can not simply say I want to put everything in the play or everything in the move generator. Each part of the logic has a right place according to what you want them to do.

Regards,
Eric

Eric,

I have spent some time trying to think through what you are trying to tell me here. Eventually I think I worked it out and it seems to work.

This is a simplified account which ignores regions on the board and the different piece types. I am assuming that "MoveStep" is a macro that captures my needs for a step move and similarly for "moveHop". However I assuming that "moveHop" also takes an IntFunction as an optional parameter that restricts the (from) of the Hop to a single site containing a piece belonging to the Mover.

In the piece generator I need to specify the moves as:

Code:
(or
   ("MoveStep")
   ("MoveHop")
)


In the <play> section I need to have:


Code:
    (if "SameTurn"
        (or
            ("MoveHop" (last To))
                (move Pass)
        )
                (forEach Piece)
    )

As I said this seems to work.