I was wondering if we should not split up the fairy-move-model. There currently are two things in that, which are largely independent. One is the graph functions for common fairy pieces, and the cbPiecesFromFEN. These are for use during game definitions. The other consists of a lot of wrapper routines, for move generation and performing them. These are used during playing, and only needed for pieces with various forms of locust capture. They needlessly slow down the AI in variants that do not have such moves. Variants like Capablanca Chess now suffer from that, just because they generate the pieceTypes from a FEN.
So perhaps we should have bot h a fairy-piece-model and a fairy-move-model.
I was wondering if we should not split up the fairy-move-model. There currently are two things in that, which are largely independent. One is the graph functions for common fairy pieces, and the cbPiecesFromFEN. These are for use during game definitions. The other consists of a lot of wrapper routines, for move generation and performing them. These are used during playing, and only needed for pieces with various forms of locust capture. They needlessly slow down the AI in variants that do not have such moves. Variants like Capablanca Chess now suffer from that, just because they generate the pieceTypes from a FEN.
So perhaps we should have bot h a fairy-piece-model and a fairy-move-model.