01-01-2021, 05:21 PM
(This post was last modified: 01-02-2021, 05:04 AM by dale walton.)
The attached code which I am debugging offered an unexpected choice - The move has two branches that depend on the type of piece being removed. since only one type of piece is being removed there is no choice to make.
The value for <Multi:capture> in the Occupied by: option was: NonMover which seems to be working as both the white and black hexes were offered for capture.
The problem is that after clicking the red dot next to the white disc, a popup appeared offering a choice between replacing the hex location with a disc or with a hex - but the logic is that the choice depends on what was in the jumped location.... Either choice was allowed by the popup the replacement with disc / hex was made accordingly, but the game logic is meant to specify hexes only replace discs / discs only replace hexes, while simultaneously, ownership changes to the mover.
------------------------------
FWIW, I previously had all the actions in the apply section without using a pending to keep the (between) location, but that was causing the program to make a lot more errors ( - and trying to solve it with a (then (add...)) inside the applied moves caused the program to hang as well.) - You might look at whether those approaches reveal more about the bug, and/or whether the compiler needs to guard against such things...
Edit: I also got this choice coming up in another version in which
(then
(and
(remember Value (value Pending))
(if (is In (value Pending) (sites Occupied by:Player component:"Disc"))
(and
{
(remove (value Pending))
(add (piece (id "Hex" mover)) (to (value Pending)))
(addScore Mover 10)
}
)
(and
{
(remove (value Pending))
(add (piece (id "Disc" mover)) (to (value Pending)))
(addScore Mover -10)
}
)))))
In this case both boxes read the same except for having or missing the - before the 10: i.e.
[P1+=-10, Pending=6, D2-B2][Or([Lgame.rules.play.moves.Moves;@74ad62d6),Or([Lgame.rules.play.moves.Moves;@39e48495)]
Note that there is no end square bracket after the @#####.
A separate bug issue: Using "Player" in the Occupied by: test above always activates one branch of this code regardless of whether -10 or +10 is chosen,
Using "Each" activates the other branch. but leaving the "by:" clause out -which is what I wanted to do, causes a garbage compiler error, even though the "by:" clause is optional in the documentation. What works for the logic seems to be to use Occupied by:All.
But the selection popup still appears.
Possibly related: I separately noticed that (and (...) (...) (then)) does the contents of (then) twice.
I think I understand the the problem in the quoted code: component takes "name of component" so this must match to the by: role? - but that still doesn't explain why it "half" works. And it would be a nuisance if one needs a "forEach Player" ... somewhere in here...
-------------------
Further update. I managed to workaround this by totally separating the two cases, thus avoiding the condition. --- But then it popped up again when I tried to extend the logic to NonMover - So it does seem I do need to implement the move forEach player since I am writing for optional numbers of players... -- Even though sites Occupied by:<roleType> shows any role is allowed - can this be fixed? So that (sites Occupied by:NonMover component:"Disc") and (sites Occupied component:"Disc") work as they should and one doesn't need to provide an unknown and hard to generate list like {"Disc0" "Disc2" "Disc3"} etc.
The value for <Multi:capture> in the Occupied by: option was: NonMover which seems to be working as both the white and black hexes were offered for capture.
The problem is that after clicking the red dot next to the white disc, a popup appeared offering a choice between replacing the hex location with a disc or with a hex - but the logic is that the choice depends on what was in the jumped location.... Either choice was allowed by the popup the replacement with disc / hex was made accordingly, but the game logic is meant to specify hexes only replace discs / discs only replace hexes, while simultaneously, ownership changes to the mover.
------------------------------
FWIW, I previously had all the actions in the apply section without using a pending to keep the (between) location, but that was causing the program to make a lot more errors ( - and trying to solve it with a (then (add...)) inside the applied moves caused the program to hang as well.) - You might look at whether those approaches reveal more about the bug, and/or whether the compiler needs to guard against such things...
Edit: I also got this choice coming up in another version in which
(then
(and
(remember Value (value Pending))
(if (is In (value Pending) (sites Occupied by:Player component:"Disc"))
(and
{
(remove (value Pending))
(add (piece (id "Hex" mover)) (to (value Pending)))
(addScore Mover 10)
}
)
(and
{
(remove (value Pending))
(add (piece (id "Disc" mover)) (to (value Pending)))
(addScore Mover -10)
}
)))))
In this case both boxes read the same except for having or missing the - before the 10: i.e.
[P1+=-10, Pending=6, D2-B2][Or([Lgame.rules.play.moves.Moves;@74ad62d6),Or([Lgame.rules.play.moves.Moves;@39e48495)]
Note that there is no end square bracket after the @#####.
A separate bug issue: Using "Player" in the Occupied by: test above always activates one branch of this code regardless of whether -10 or +10 is chosen,
Using "Each" activates the other branch. but leaving the "by:" clause out -which is what I wanted to do, causes a garbage compiler error, even though the "by:" clause is optional in the documentation. What works for the logic seems to be to use Occupied by:All.
But the selection popup still appears.
Possibly related: I separately noticed that (and (...) (...) (then)) does the contents of (then) twice.
I think I understand the the problem in the quoted code: component takes "name of component" so this must match to the by: role? - but that still doesn't explain why it "half" works. And it would be a nuisance if one needs a "forEach Player" ... somewhere in here...
-------------------
Further update. I managed to workaround this by totally separating the two cases, thus avoiding the condition. --- But then it popped up again when I tried to extend the logic to NonMover - So it does seem I do need to implement the move forEach player since I am writing for optional numbers of players... -- Even though sites Occupied by:<roleType> shows any role is allowed - can this be fixed? So that (sites Occupied by:NonMover component:"Disc") and (sites Occupied component:"Disc") work as they should and one doesn't need to provide an unknown and hard to generate list like {"Disc0" "Disc2" "Disc3"} etc.