+- 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: Trust (/showthread.php?tid=349)
Trust - dale walton - 12-27-2020
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.
RE: Trust - Eric Piette - 01-04-2021
Hi,
I think you got it when I read the last part of your message, that's normal.
A step move is working only to the sites directly related to direction specified.
Consequently if you do not specified any direction, the piece can move to any adjacent sites.
BUT to restrict that, you need to specify a condition on the 'to' site.
Example:
(move Step
(to if:(is Empty (to)))
)
And not a RegionFunction, which will have no sense here because the regionFunction is implied by the direction of the step move. So going to all the empty sites will be just not possible here with a step move, consequently that RegionFunction is just ignored by the (move Step ...) ludeme.
Regards,
Eric
RE: Trust - dale walton - 01-05-2021
So then this is a category of information needed for every move in the documentation.
You give information about what defaults are,
but we also need standard information, by move, about what is ignored, not permitted, and/or what is not ignored, but rather changes the nature of the move.
It needs to be at the move documentation level because the utility level needs to be more general.
It will get lost if it is only an answer in the forum.