01-15-2021, 06:25 AM
(This post was last modified: 01-15-2021, 07:14 AM by dale walton.)
This should be rare, but may help if there are also problems like this for other commands.
In the following, using from does not work in the "(expand origin:" i.e. no expansion occurs; but using (last From) or (last To) shows moves possible in the expanded areas around those sites.
(move
(from
(sites Occupied by:Mover)
)
(to
(expand
origin:(from)
Orthogonal
)))
This was on a tri Hexagon based board, but I assume that is not relevant.
--------------------------------------------
I also experiences a separate issue when trying to use an (apply) in the (move (from (...) if (... ) (apply ...))) ...
or using for example
(move (from) (to (forEach (sites ... if:(...) (apply (set ... (then ...(remember ...)))) if:(is In (to) (sites Remembered))) to achieve consequential states (then) inside the (to)
I am testing these things because I would like to do selections on sites that require some consequences beyond this in order to make the selection.
When I alternatively separate a (move (from) (to) ) into separate (move Select ... (then (moveAgain)) and (move (from (last To)) (to ...)); the compiler didn't like to just do a select move with no consequence to the position. -- (move Remove ... (then (moveAgain))) compiles, but then the move history looks confusing for the purpose of simulating a move from-to.
The move I am ultimately trying to implement is an all-in Throngs move: ie a series of hops-to-empty of any distance in Orthogonal Directions, but the total travel distance does not exceed a given parameter.
I have also tried the approach of chaining ifAfterwards requirements without success.
I have worked out a fairly efficient algorithm for it if you would be willing to implement it as a separate Ludeme.
It requires n states to calculate if the overall distance is n, but the branching can be reduced from what a straight-forward approach might give.
(an alternative algorithm requires a 2 D array (site + value), hence the desire to apply values to sites in a separate post.) - It still would require iteration, but individual values in the array would only be set once per value.
Implementing as a series of individual regular moves makes the AI very slow and the tree it searches heavily redundant.
You might have some puzzle solving ludemes that could be put to use, but the documentation suggests that is not possible, and I have no Idea of how to use them.
In the following, using from does not work in the "(expand origin:" i.e. no expansion occurs; but using (last From) or (last To) shows moves possible in the expanded areas around those sites.
(move
(from
(sites Occupied by:Mover)
)
(to
(expand
origin:(from)
Orthogonal
)))
This was on a tri Hexagon based board, but I assume that is not relevant.
--------------------------------------------
I also experiences a separate issue when trying to use an (apply) in the (move (from (...) if (... ) (apply ...))) ...
or using for example
(move (from) (to (forEach (sites ... if:(...) (apply (set ... (then ...(remember ...)))) if:(is In (to) (sites Remembered))) to achieve consequential states (then) inside the (to)
I am testing these things because I would like to do selections on sites that require some consequences beyond this in order to make the selection.
When I alternatively separate a (move (from) (to) ) into separate (move Select ... (then (moveAgain)) and (move (from (last To)) (to ...)); the compiler didn't like to just do a select move with no consequence to the position. -- (move Remove ... (then (moveAgain))) compiles, but then the move history looks confusing for the purpose of simulating a move from-to.
The move I am ultimately trying to implement is an all-in Throngs move: ie a series of hops-to-empty of any distance in Orthogonal Directions, but the total travel distance does not exceed a given parameter.
I have also tried the approach of chaining ifAfterwards requirements without success.
I have worked out a fairly efficient algorithm for it if you would be willing to implement it as a separate Ludeme.
It requires n states to calculate if the overall distance is n, but the branching can be reduced from what a straight-forward approach might give.
(an alternative algorithm requires a 2 D array (site + value), hence the desire to apply values to sites in a separate post.) - It still would require iteration, but individual values in the array would only be set once per value.
Implementing as a series of individual regular moves makes the AI very slow and the tree it searches heavily redundant.
You might have some puzzle solving ludemes that could be put to use, but the documentation suggests that is not possible, and I have no Idea of how to use them.