02-14-2021, 07:43 PM
I had a bit of feedback on the implementation of Throngs, so I am trying to make play smoother and more understandable with a reworking to use select for the intermediate destinations.
It is now almost working. Here are some of the problems:
1) doing this with Select. - The move commands should know when from is (last To) and the previous mover is the current mover, that the from does not need to be selected, but nothing I tried could make this work.
Work-around store last To to pending or to a variable and select the destination only. result: blue dots for moves instead of red. (but if "MoveFriendly" uses (move (from) (to) ) it has red dots. and different behavior:transparent when selecting the piece.
2) to make it clear which piece is moving and how much further, I added state.
Problem for the "MoveFriendly" as in a (move....) the piece state can't be updated in the (from ... (apply..)) and the piece is thus not refreshed to show it when the first (blue dot) selection is made.
-- for consistency I tried simply selecting, then changing the piece state and MoveAgain, but
3) Piece state and variable states are either not considered as games states, or the program does not yet allow such moves to be treated as moves. It gives a Blue dot for the select, but the (set...) actions were not performed (probably because no piece movement occurred, thus on the MoveAgain, the capability of the pieces to now move was not there....
-- I did not check whether this would work with pending, but all stored variables are part of the game state and must be hashed as such or explictly excluded (But variables are needed BECAUSE they carry state information.
Thus the attached version is not working as intended for selection an existing piece on the board.
FYI, I am also using a technique of clicking on the piece to clear the remaining power not to be used, rather than a pass - this is working OK.
4) Misc, that I despair of isolating for you, so just mention in passing:
In the process of changes, I noticed problems with using a condition to change a variable, that in a subsequent state before the decision, was used in another condition. This failed differently when using do to make the conditional assignment and when using the then clause of the first if.
It gave an if you see this warning in a implemented Ludii game... warning for player 0
I avoided the problem by restructuring the code.
I have previously found (then clauses as part of (and), - after the choices - , execute multiple times as evidenced by dupilcate variable assignments showing in the moves, I also try to avoid this construction .....
It is now almost working. Here are some of the problems:
1) doing this with Select. - The move commands should know when from is (last To) and the previous mover is the current mover, that the from does not need to be selected, but nothing I tried could make this work.
Work-around store last To to pending or to a variable and select the destination only. result: blue dots for moves instead of red. (but if "MoveFriendly" uses (move (from) (to) ) it has red dots. and different behavior:transparent when selecting the piece.
2) to make it clear which piece is moving and how much further, I added state.
Problem for the "MoveFriendly" as in a (move....) the piece state can't be updated in the (from ... (apply..)) and the piece is thus not refreshed to show it when the first (blue dot) selection is made.
-- for consistency I tried simply selecting, then changing the piece state and MoveAgain, but
3) Piece state and variable states are either not considered as games states, or the program does not yet allow such moves to be treated as moves. It gives a Blue dot for the select, but the (set...) actions were not performed (probably because no piece movement occurred, thus on the MoveAgain, the capability of the pieces to now move was not there....
-- I did not check whether this would work with pending, but all stored variables are part of the game state and must be hashed as such or explictly excluded (But variables are needed BECAUSE they carry state information.
Thus the attached version is not working as intended for selection an existing piece on the board.
FYI, I am also using a technique of clicking on the piece to clear the remaining power not to be used, rather than a pass - this is working OK.
4) Misc, that I despair of isolating for you, so just mention in passing:
In the process of changes, I noticed problems with using a condition to change a variable, that in a subsequent state before the decision, was used in another condition. This failed differently when using do to make the conditional assignment and when using the then clause of the first if.
It gave an if you see this warning in a implemented Ludii game... warning for player 0
I avoided the problem by restructuring the code.
I have previously found (then clauses as part of (and), - after the choices - , execute multiple times as evidenced by dupilcate variable assignments showing in the moves, I also try to avoid this construction .....