The NewClick entry system is based on the AI: it uses the move generator of the latter to create a list of moves, and then after each click eliminates the moves that do not correspond to the clicks received so far, until only a single move is left. So getting it done in the AI's move generator is all that is needed. But indeed this does not use the 'clicks' array, as during thinking no one is clicking.
The AI's move generator uses a routine StackMove() to add a move to the list, and this calls BadZone() to vet the move for user-supplied restrictions on the Betza notation. This StackMove() gets the origin and destination squares passed as arguments, but not the locust squares. These are 'passed' as global variables: 'kills' indicates how many locust squares there are, and arrays killX[i] and killY[i], 0 <= i < kills contain the coordinates of these squares. For backward compatibility killX[0] and killY[0] are passed to BadZone(), but not any additional locust squares.
BadZone() can access these global variables just as easily as StackMove() does it, so you could base your move vetting on those.
A complication is that e.p. squares are also passed in the kill array (a variable 'eps' indicates how many of the kills are e.p. squares). But I guess that you won't have any e.p. capture in Shogi variants, so you won't have to deal with that.
The NewClick entry system is based on the AI: it uses the move generator of the latter to create a list of moves, and then after each click eliminates the moves that do not correspond to the clicks received so far, until only a single move is left. So getting it done in the AI's move generator is all that is needed. But indeed this does not use the 'clicks' array, as during thinking no one is clicking.
The AI's move generator uses a routine StackMove() to add a move to the list, and this calls BadZone() to vet the move for user-supplied restrictions on the Betza notation. This StackMove() gets the origin and destination squares passed as arguments, but not the locust squares. These are 'passed' as global variables: 'kills' indicates how many locust squares there are, and arrays killX[i] and killY[i], 0 <= i < kills contain the coordinates of these squares. For backward compatibility killX[0] and killY[0] are passed to BadZone(), but not any additional locust squares.
BadZone() can access these global variables just as easily as StackMove() does it, so you could base your move vetting on those.
A complication is that e.p. squares are also passed in the kill array (a variable 'eps' indicates how many of the kills are e.p. squares). But I guess that you won't have any e.p. capture in Shogi variants, so you won't have to deal with that.