Ludii Forum
count-parameter bug? - Printable Version

+- Ludii Forum (https://ludii.games/forums)
+-- Forum: Problems (https://ludii.games/forums/forumdisplay.php?fid=5)
+--- Forum: Grammar Problems (https://ludii.games/forums/forumdisplay.php?fid=24)
+--- Thread: count-parameter bug? (/showthread.php?tid=261)

Pages: 1 2


count-parameter bug? - Michael - 11-18-2020

In the attached .lud you are supposed to be able to move a whole stack, and then the stack should grow in size by 1.

When I do not use the parameter "count:(size Stack at:(from))", the adding of the extra piece works fine. But when I add that parameter (which I need, since this move is a whole stack move) strange things happen:

First: If I move a stack from cell 0, it moves and no piece is added anywhere.
Second: If I move from some other cell than 0, a piece is added to (last From) instead of (last To).

So the stack does not grow in either case.


RE: count-parameter bug? - Michael - 11-22-2020

After having tried many variations and encountered many strange behaviors, these two changes makes it work:

(1) Set "stack" to true in (move <from> <to>)
(2) Change the code in (play) from "("MoveWholeStack")" to "(forEach Piece ("MoveWholeStack"))"

(1) seems contrary to what I thought I just learned: No matter where a "stack"-parameter is set to true, it will be true globally.

So I think I have found a way to make this work, but I really want to know if it was supposed to work in the first .lud also. There seems to be something off here.


RE: count-parameter bug? - Eric Piette - 11-23-2020

Hi,

If one ludem uses a stack option, the model of the state of the game becomes a stack model. Consequently, the default behavior will be to stack the pieces (placing a piece on top of another for example rather than removing it for the flat model).

However, that does not mean you can not provided the "stack:true" parameter for the others ludemes, because that parameter modifies the result of the computation of the class corresponding to the ludeme and also of the actions computing thanks to a Move ludeme. That's why here the "stack:true" parameter is important for your game.


In looking the last submitted file, I would advice you to modify it a bit in using the "top:true" parameter of (forEach Piece) to look only the top pieces of each stack owned by the mover and to have only (from) in the (from ...) condition of "MoveWholeStack". That would make the description much nicer and efficient.

Here what I suggest:

Code:
(define "MoveWholeStack"
    (move
        (from)
        (to
            (sites Direction
                from:(from)
                stop:(is Occupied (to))
            )
        )
        count:(size Stack at:(from))
        stack:true
        (then
            (add (to (last To)) stack:true)
        )
    )
)

(game "MoveCountTestWorks"
    (players 2)
    (equipment
        {
            (board (hex 5))
            (piece "Disc" Each)
            (piece "Disc" Neutral)
        }
    )
    (rules
        (start {
            (place "Disc1" 0)
            (place "Disc2" 1)
        })
        (play
                (forEach Piece ("MoveWholeStack") top:true)
        )
        (end
            (if
                (no Moves Next)
                (result Mover Win)
            )
        )
    )
)

Regards,
Eric


RE: count-parameter bug? - Michael - 11-23-2020

Thank you :)
I must ask, though: Is (is Occupied (to)) really equivalent to (< 0 (who at:(to)))? Aren't cells with neutral pieces in them occupied?

I have tried to put this together in a game I'm working on, but I got an error message, even though it compiles. I can't remember what it said in 1.1.1, but I downloaded 1.1.2 and there the error message is "VC_ERROR: Error detected when attempting to draw COMPONENTS". And in 1.1.2 nothing is drawn. In 1.1.1 the neutral pieces were drawn.


RE: count-parameter bug? - Eric Piette - 11-24-2020

Hi,

The problem comes from the fact that you are using the "Each" parameter in the (forEach Piece...). That parameter is working only for the piece equipment in the current version. I am going to handle it to in that ludeme for the next release. But for your current description I advice you to replace


Code:
(forEach Piece ("MoveWholeStack") Each top:true)

by

Code:
(forEach Piece ("MoveWholeStack") All top:true)

However after playing the game, I found another bug in the code of one our action class corresponding to the stack move. So I just fixed it. Consequently to be able to continue to work on your game, it would be better to wait for the next release.

For the question "I must ask, though: Is (is Occupied (to)) really equivalent to (< 0 (who at:(to)))? Aren't cells with neutral pieces in them occupied?"
No this is not equivalent, sites occupied by a piece have to have the what different to 0, not the who.

Regards,
E



RE: count-parameter bug? - Michael - 11-25-2020

I'm having two problems with a game I'm working on. I'll post them in separate posts. This is the strangest one.

In the attached .lud you are supposed to be able to move any neutral piece outward (so its distance to the center increases). But there are many places I am not allowed to move the neutrals on 21, 22, 29, 31, 38 and 39 to, even though they are further from the center. Try to move from 29 to 28, say.

The strange thing is: This only happens when I have the white piece on the center cell and have ("MoveZeroStack") inside (or) together with ("MoveWholeStack"). If I have simply (forEach Piece ("MoveZeroStack") Neutral top:true) in (play) and simply (place "Disc0" (sites Board)) in (start) this behavior goes away, even though nothing is changed in ("MoveZeroStack").

The other problem pertains to the same .lud:

I can't get (apply) to work in ("MoveWholeStack"). I have "(apply (remove (to) count:(size Stack at:(to))))". My thought was that this will remove all pieces in (to) before it moves the relevant stack there. For example: If I move the white piece in the center to 28 I want the neutral piece at 28 to be removed so the white piece does not land on top of it. This is not what happens, however. Nothing is removed, and the white piece ends up on top of the neutral piece.

What am I doing wrong?


RE: count-parameter bug? - Eric Piette - 11-26-2020

Hi,

That's a bit hard for me to provide a complete useful answer to the first problem but that's seems to be due to your condition in "MoveZeroStack", that one:

if:(<
(count Steps (from) (centrePoint))
(count Steps (to) (centrePoint))
)

So as far I understand what you try to do, the legal moves seems "correct".
And if you remove the piece in the middle, the condition stop:(< 0 (who at:(to))) is never reached, so the if: is never checked, that's why that seems works in that special case.

For the second question, I just did not understand it. That's always better to have only question by post with an example. So if you can make one to illustrate what you would like to have, maybe I can help more with that.

Regards,
Eric


RE: count-parameter bug? - Michael - 11-26-2020

(11-26-2020, 01:57 PM)Eric Piette Wrote: That's a bit hard for me to provide a complete useful answer to the first problem but that's seems to be due to your condition in "MoveZeroStack", that one:

            if:(<
                (count Steps (from) (centrePoint))
                (count Steps (to) (centrePoint))
            )

So as far I understand what you try to do, the legal moves seems "correct".
And if you remove the piece in the middle, the condition  stop:(< 0 (who at:(to))) is never reached, so the if: is never checked, that's why that seems works in that special case.

I don't think I got across how weird the behavior is. Having or not having a piece in the cetrePoint doesn't make a difference in itself. So ("MoveZeroStack") seems to work fine. The trouble is when I have a piece there and the following in (play):
Code:
(or
    (forEach Piece ("MoveWholeStack") Mover top:true)
    (forEach Piece ("MoveZeroStack") Neutral top:true)
)

The (or) is causing trouble. If I instead only have
Code:
(forEach Piece ("MoveZeroStack") Neutral top:true)
the problem goes away. 

How can the logic of ("MoveZeroStack") change just because it is inside (or) together with ("MoveWholeStack")?

Also: Site 28 is 2 steps away from the centrePoint, and site 29 is 1 step away from the centrePoint. 2 is greater than 1. It shouldn't matter what is at the centrePoint. So if 29 is (from) and 28 is (to) the condition
Code:
(<
    (count Steps (from) (centrePoint))
    (count Steps (to) (centrePoint))
)
holds, and it should be possible to move from site 29 to site 28.

In the picture I have clicked 29 and it shows me all the places that I should be able to go. Those dots are in the right places. But when I try to move to 28 I get a message saying it is not a legal move.


RE: count-parameter bug? - Eric Piette - 11-26-2020

Hi,

If I do what you suggest in removing the or and keeping only the line
(forEach Piece ("MoveZeroStack") Neutral top:true)

I got the same result for the neutral pieces.

(Or ...) has no impact in something inside, that's just a logical boolean or operator between moves.

The difference is when the centre piece is not there.

Regards,
Eric


RE: count-parameter bug? - Michael - 11-26-2020

(11-26-2020, 04:10 PM)Eric Piette Wrote: Hi,

If I do what you suggest in removing the or and keeping only the line
(forEach Piece ("MoveZeroStack") Neutral top:true)

I got the same result for the neutral pieces.

(Or ...) has no impact in something inside, that's just a logical boolean or operator between moves.

The difference is when the centre piece is not there.

Regards,
Eric
Here is a trial where I move from site 29 to site 28 when there is a piece in the center.

Edit: I have attached a gif of what happens when the (or) is added back in.