Ferdy wrote:
There should not be a problem with this, if in check, you really need the move, the same if not in check, the engine most ofen needs the move to get ahead with the active piece placement, unless the position is a zugzwang. Did you brutally test this with 30k games or more .
My initial thought is not giving bonus if in check, so you avoid checks in eval, with I think it should be more problematic than having the initiative. Anyway it needs lots of games to test, I suspect. Different engines could value that bonus differently
Deep in qsearch I use the eval even when in check, a trade-off for speed against accuracy. But I search non-capture check moves at early plies in qsearch before going deeper.
All test I did introducing check moves in qsearch (early or later) did bad for me. I dont know why. Maybe having a special check_scape gen moves routines would help a lot.
How do you do non-capture check moves? You have to make them to know if it checks, isn't it?
Ferdy wrote:
There should not be a problem with this, if in check, you really need the move, the same if not in check, the engine most ofen needs the move to get ahead with the active piece placement, unless the position is a zugzwang. Did you brutally test this with 30k games or more .
My initial thought is not giving bonus if in check, so you avoid checks in eval, with I think it should be more problematic than having the initiative. Anyway it needs lots of games to test, I suspect. Different engines could value that bonus differently
Deep in qsearch I use the eval even when in check, a trade-off for speed against accuracy. But I search non-capture check moves at early plies in qsearch before going deeper.
All test I did introducing check moves in qsearch (early or later) did bad for me. I dont know why. Maybe having a special check_scape gen moves routines would help a lot.
How do you do non-capture check moves? You have to make them to know if it checks, isn't it?
There is no need to make the move on the board, for example, when generating a knight move, determine all its knight_to_sq[], then generate a knight move but use the opponent's king and determine its opp_king_to_sq_knight_move[], if there is a common square, between knight_to_sq and opp_king_to_sq_knight_move then a knight move to that common sq is now a candidate move, there can be more than one common sq. For sliders, just slide the piece and slide the opp king like the piece, the common sq will become a candidate for that piece. Discovered check is a little bit complicated but it is solvable. In bitboard this is easier.
.