💡📝H. G. Muller wrote on Sun, Jan 22, 2023 10:32 AM UTC:
The NewClick entry system is still experimental, and in general I try to avoid auto-completion. But there is one exception: I put in a heuristic that classifies a locust capture eaither as 'shooting' or 'trampling' (depending on whether the leg after it goes back to the square the previous leg came from), and swap the click order of the two legs in that case. So that you can first click the final destination, and only then what you shoot. This seemed more naturally, e.g. in the case of the Forest Ox of Odin's Rune Chess.
Perhaps this now interferes with what you are trying to do, and needs some refinement. Can you be more specific on what goes wrong?
With BadZone() you should be able to restrict the list of moves that is generated, suppressing the burns you don't want. If this will lead to a list from which the NewClick() algorithm cannot properly select the one you want, this should count as a defect in NewClick(). Not as a problem with using killX/Y in BadZone().
The NewClick entry system is still experimental, and in general I try to avoid auto-completion. But there is one exception: I put in a heuristic that classifies a locust capture eaither as 'shooting' or 'trampling' (depending on whether the leg after it goes back to the square the previous leg came from), and swap the click order of the two legs in that case. So that you can first click the final destination, and only then what you shoot. This seemed more naturally, e.g. in the case of the Forest Ox of Odin's Rune Chess.
Perhaps this now interferes with what you are trying to do, and needs some refinement. Can you be more specific on what goes wrong?
With BadZone() you should be able to restrict the list of moves that is generated, suppressing the burns you don't want. If this will lead to a list from which the NewClick() algorithm cannot properly select the one you want, this should count as a defect in NewClick(). Not as a problem with using killX/Y in BadZone().