Single Comment

OK, I think I fixed it. The Betza compiler now refrains from inserting these 'loop directives' in the legs sequence when the NewClick move-entry method is used. I had to change some tests in the assignment of click sequences (which already relied on the presence of these directives) too. Distant or sliding rifle captures do not require the click to the final destination. This might be a folly, though, as it causes ambiguity when both the rifle and normal capture are allowed on the piece. Perhaps I should make this subject to a Diagram parameter autoComplete, and in general require all clicks, but consider the move entered when there is only one matching move left in the list, and at least two clicks have been given.

I am not even sure that swapping the order of locust victim and destination is always harmless, or whether it could lead to ambiguities too.

Anyway, I uploaded the fixed betza.js. (Flush browser cache!) It seems to make double and single burns as I intended them, clicking the destination first, and then 'picking off' the burn victims. Where clicking the same victim twice does a single burn. This was in combination with a Demon that moved like:

cabKcabacabKshQshmpyacabQshmpyacabmpacabQ

It did not forbid burning of a Demon with the killsZone() routine you had made. But when I made my own, that only cares about this aspect of the rules, it did work:

function killsZone(x2, y2, piece, color, x1, y1, ex, ey)
{
  if(kills == 0 || x1==x2 && y1==y2) return 0; // normal move or igui always allowed
  if((board[killY[0]][killX[0]] & 511) == 35) return 1;
  return (kills > 1 && (board[killY[1]][killX[1]] & 511) == 35);
}

So it is probably because your routine is not yet adapted to the new situation.

The extensive testing you do in BadZone() slows things down enormously. It is questionable whether this variant can ever be played by the Diagram's AI, (it outlasted my patience even at 2 ply), but this extra processing certainly doesn't help. If you need this amount of programming to make it work, it might be simpler to just replace some functions of the original script by slightly modified ones of your own. JavaScript allows you to redefine a function.

E.g. the function NextLeg(), which is the core of the AI's move generator, contains a line

      if(f & 16) NextLeg(ff, fr, x, y, rg>1?len:iso, d+1); // p/g leg never final; do nothing here and continue

which takes care of continuation of a hopper move (the 'hop off') when the current leg has hit a mount, which at that point is stored in the variable 'victim'. You could clone that routine, and supplement the condition f & 16 with a test whether the piece types allow the hop:

      if(f & 16 && jumpClass[victim&511] < jumpClass[board[fr][ff]&511])
        NextLeg(ff, fr, x, y, rg>1?len:iso, d+1); // p/g leg never final; do nothing here and continue

when you have initialized an array jumpClass[] for all the piece types. That would releave you from all the checking after the moves are generated.

The way you treat freezing only seems to work if you generate moves for a single piece, and it is not clear how 'frozen' ever gets reset. I suppose you could make use here of the fact that the move generator generates moves piece by piece, and only redo the scan of the surroundings of the piece when the current piece is different from that of the previous call. If there are only few freezers, it might be much faster (considering the large number of pieces in this variant) to first locate the freezers, scan the board for their enemy neighbors, and temporarily replace those for dummies during the move generation. (This would require you to provide your own modified version of the (very small) routine GenAll().)