+- 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: "(expand origin:(from)" bug in "(to " clause (/showthread.php?tid=367)
"(expand origin:(from)" bug in "(to " clause - dale walton - 01-15-2021
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.
RE: "(expand origin:(from)" bug in "(to " clause - dale walton - 01-16-2021
I am giving up on trying to implement the Throngs move as a single decision step:
From what I see in the Full moves and warnings of some of my compiled attempts, everything within a single decision move is essentially concurrent, so iterations with consequences are randomly overlapping each other for example with state assignments, and the intermediate states cannot be queried (at least not reliably).
For example, I was able to pre-add discs and assign them state values according to the count needed to reach them, except some states were assigned multiple times and adding a comparison to the existing assignment did not prevent overwrites contrary to the condition. Further, when trying to do a second wave of additions to supplement the first additions (all before the desision move selection) the game hung durring play due to inability to draw the components.)
Thus, I am seeing each branch of iterations and of (and) statements, though launching sequentially, but are not constrained to complete in sequence - so you CAN have conditions that are both true and false at the "same" time (not same instant of course, but time is fuzzy here) if the data from each branch is writing to the same registers. This may be your design, or a problem with proper closures - I don't presume to know as I am not a JS programmer, but come from a procedural background.
In any case, let's call it the design. Then I don't see any workarounds for enforced intermediate state updates without using decision moves, and the system also complains if a "decision move" consist of moves without a decision (by design), so the moves cannot even be automated across several "decision" Moves. There seems to be no way I can reliably "play out" the possible combinations, and then base a selection upon them.
Maybe there is something in the deduction puzzle ludemes, but the math is over my head, and the documentation says essentially "don't even think about using it in games" Is there a way this could somehow be used to automate a series of move possibilities to prepare for a selection? i.e. create a "result" of all sites reachable within a certain number of moves including alternatives and constraints.
- Fortunately I can implement this as a series of decision moves, without being too tedious for Human players.
So I will do it that way.
But this will leave the AI with way too many possible redundant moves to process efficiently. - and possibly several AI moves per turn to wait for.
The good side, is all this mental exercise is helping me to understand how to write scripts better and faster.
Sorry for venting my frustrations here, but I needed to get that out. I don't know if there is anything you can do to help.
RE: "(expand origin:(from)" bug in "(to " clause - Michael - 01-16-2021
Can't we have something like a repetition-parameter on (sites To) which takes integers and is set to 0 by default, such that, if this is set to a positive number, the region also includes the to-sites of the repetitions, which each tries to treat the the to-sites of the previous iteration as the from-sites of the next? (If the move has no (from), nothing happens..) Is this outside the realm of possibility?