This post was useful to me as it turns out I also wasn't checking for this case (even in 960), and was a quick fix to correct.
I guess Stockfish must have a test for this case that's only activated in Chess960 mode, whereas when not in Chess960 mode I assume the castling flags are invalid if rooks aren't on standard start squares and don't allow castling.
That's because you're doing something wrong!
Can you figure it out?
Hint: do you SF expect to know that you are giving a Chess960 fen?
True. But that's because the SF implementation of casting is clumsy. If you do it well, the code can be 100% FRC agnostic.
In Demolito, everything is written for FRC, and normal chess as just a particular starting position. There is not a single Chess960 in the code, except to deal with the UCI protocol inconsistency. If the UCI protocol could be corrected, there would be no need for it.
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
That's because you're doing something wrong!
Can you figure it out?
Hint: do you SF expect to know that you are giving a Chess960 fen?
True. But that's because the SF implementation of casting is clumsy. If you do it well, the code can be 100% FRC agnostic.
In Demolito, everything is written for FRC, and normal chess as just a particular starting position. There is not a single Chess960 in the code, except to deal with the UCI protocol inconsistency. If the UCI protocol could be corrected, there would be no need for it.
To be fair to Stockfish (and myself), I didn't expect it to know that I wanted Chess960, I just got the UCI syntax wrong for telling it. But, you make a good point that special-casing for Fischer Random is not really necessary. Note: Winboard too has a variant command for "fischerandom".
That's because you're doing something wrong!
Can you figure it out?
Hint: do you SF expect to know that you are giving a Chess960 fen?
True. But that's because the SF implementation of casting is clumsy. If you do it well, the code can be 100% FRC agnostic.
In Demolito, everything is written for FRC, and normal chess as just a particular starting position. There is not a single Chess960 in the code, except to deal with the UCI protocol inconsistency. If the UCI protocol could be corrected, there would be no need for it.
Likewise for Ethereal. If UCI could handle O-O-O and O-O, there would be no need for any special code at all.
void moveToString(uint16_t move, char *str, int chess960) {
int from = MoveFrom(move), to = MoveTo(move);
// FRC reports using KxR notation, but standard does not
if (MoveType(move) == CASTLE_MOVE && !chess960)
to = castleKingTo(from, to);
Above is the only line of code that cares at all about whether its FRC or not.
#WeAreAllDraude #JusticeForDraude #RememberDraude #LeptirBigUltra "Those who can't do, clone instead" - Eduard ( A real life friend, not this forum's Eduard )
I am still running Chess.js on the depth 6 results…
nrbbnk1r/pp2pppq/8/2pp3p/3P2P1/1N6/PPP1PP1P/1RBBNKQR w HBhb - 0 9. Chess.js perf depth 6 on my machine: 2526 seconds. Stockfish 11: Below 9 seconds! Clearly, there is some room for improvement here. =)
Sesse wrote: ↑Thu May 14, 2020 10:33 am
I am still running Chess.js on the depth 6 results…
nrbbnk1r/pp2pppq/8/2pp3p/3P2P1/1N6/PPP1PP1P/1RBBNKQR w HBhb - 0 9. Chess.js perf depth 6 on my machine: 2526 seconds. Stockfish 11: Below 9 seconds! Clearly, there is some room for improvement here. =)
SF is fast here ! Mostly because it doesn't apply leaf nodes
Instead of a big ass list of FRC fens. One could simply play 100000 games against some stable FRC engine to see there's no illegal moves. Some study like positions are ok for unit testing.
About this position: [d]nrbbnk1r/pp2pppq/8/2pp3p/3P2P1/1N6/PPP1PP1P/1RBBNKQR w HBhb - 0 9
SF: Need to pipe in stdin and time it because it lacks functionality. But its movegen is fast.