12-27-2020, 08:43 AM
(This post was last modified: 12-28-2020, 02:52 AM by dale walton.)
I am having difficulty debugging a complicated script which uses ifAfterwards in a way that appeared to not be working, so I tried to isolate it, but in the simple case It seems to work fine.
In the process, though, I ran into the attached bug - at least for the Step move. Please check that it is not more general. This kind of bug is one reason why I get frustrated and seek work-arounds. Work-arounds do work -- but that makes it impossible to know what went wrong when something doesn't work.
(game "test of step to sites empty"
(players 3)
(equipment {(board (hex 3)) (piece "Disc" Each )})
(rules
(start {(set Score Each 0)(place "Disc1" 9)(place "Disc2" 10)(place "Disc3" 8)})
(play (or (forEach Piece (move Step (to (sites Empty)))) (move Pass)))
(end (if (all Passed) (byScore)))
)
)
This does not limit (to) to the elements of (sites Empty) !
-----------
I will speculate that move Step is an optimization of move FromTo where (to) is limited the the set of sites adjacent to (from) and so ignores any assignment of sites to (to), but allows the filter.
If this approach is done generally then it must be explained and each move must also document not just the defaults, but also what cannot be changed. This would encourage use of move FromTo for any complicated cases and keep simple cases optimized.
However from a script writer's point of view, everything should work as interchangeably and consistently as possible so that one doesn't have to memorize the whole corpus of the documentation, and because the documentation is not likely to be detailed enough to describe everything if everything is special. For the script writer, assigning sites to the (to) should be like performing an intersection with those sites and the adjacent sites -- or else act as a complete override of the default (but that would negate the concept of Step entirely).
No doubt there is already a system, if you document it then everyone can check and write scripts accordingly, and things that are inconsistent can be discovered and made consistent.
In the process, though, I ran into the attached bug - at least for the Step move. Please check that it is not more general. This kind of bug is one reason why I get frustrated and seek work-arounds. Work-arounds do work -- but that makes it impossible to know what went wrong when something doesn't work.
(game "test of step to sites empty"
(players 3)
(equipment {(board (hex 3)) (piece "Disc" Each )})
(rules
(start {(set Score Each 0)(place "Disc1" 9)(place "Disc2" 10)(place "Disc3" 8)})
(play (or (forEach Piece (move Step (to (sites Empty)))) (move Pass)))
(end (if (all Passed) (byScore)))
)
)
This does not limit (to) to the elements of (sites Empty) !
-----------
I will speculate that move Step is an optimization of move FromTo where (to) is limited the the set of sites adjacent to (from) and so ignores any assignment of sites to (to), but allows the filter.
If this approach is done generally then it must be explained and each move must also document not just the defaults, but also what cannot be changed. This would encourage use of move FromTo for any complicated cases and keep simple cases optimized.
However from a script writer's point of view, everything should work as interchangeably and consistently as possible so that one doesn't have to memorize the whole corpus of the documentation, and because the documentation is not likely to be detailed enough to describe everything if everything is special. For the script writer, assigning sites to the (to) should be like performing an intersection with those sites and the adjacent sites -- or else act as a complete override of the default (but that would negate the concept of Step entirely).
No doubt there is already a system, if you document it then everyone can check and write scripts accordingly, and things that are inconsistent can be discovered and made consistent.