But for other fairy piece games where a piece can move in a weird way, it becomes very difficult to do and very bulky. For example long-leapers jump over pieces, chameleon acts like the piece it is in contact with...
So the in_check routine I have now almost does a whole move generation to test if a king is in-check or not. There aren't too many tricks you can do to alleviate this problem specially when you are trying to write a 'general' engine. So I discarded that routine and got a speed bump of 4X i repeat 4X

I let the king be captured like TSCP does in qsearch and score the position as a loss. Only downside I observed is it is dumb in detecting mates and stalemates. Is curing this problem with in_check worth it? I don't know.
I am thinking of a way to detect a king was in check after it got captured and trace back up a ply or so, to do the extension. But this is not accurate and I don't know if it will improve this problem.
Also I have found that generating evasions in qsearch is a loss atleast for my engine. It wins by 70-30 against the one which does correct evasion generation. The implementation is a bit different from TSCP's. I do not null move in qsearch (stand pat) when being in check. Then I try only captures, so if a capture happens to defend well against the check, all is well and eval is accurate. Otherwise it is a loss since we didn't do the stand pat. This seems to work very well in most cases and I would say it made it more tactically aware regarding king attacks(no king safety in eval) , if I was not biased
