search

lichess-org / api

Lichess API documentation and examples
https://lichess.org/api
GNU Affero General Public License v3.0
442 stars 147 forks source link

FEN compatibility issue when using "lichess.org/api/cloud-eval" endpoint. #171

Closed d-luca727 closed 2 years ago

d-luca727 commented 2 years ago

When sending a query to the endpoint lichess.org/api/cloud-eval I get a failed request even though I have sent a completely valid FEN (it worked inside the lichess board editor).

Basically from what I've understood the API requires X-FEN and doesn't accept FEN, e.g. sending a request with FEN ?fen=rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq e3 0 1 fails meanwhile sending the same FEN without the en passant field (i.e. ?fen=rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq - 0 1) works.

I'm using chessjs for move validation and chessground for UI.

I have tried to convert from FEN to X-FEN but haven't found anything helpful and honestly I don't know if that's even possible since X-FEN is an extension of FEN.

benediktwerner commented 2 years ago

I have tried to convert from FEN to X-FEN but haven't found anything helpful and honestly I don't know if that's even possible since X-FEN is an extension of FEN.

It's very much possible. You just need to change the en passant square to - in the case where there is no pawn that could possibly do en passant, i.e. for e3, if there's no black pawn on d4 or f4.

But the API probably should still accept normal FENs as well.

d-luca727 commented 2 years ago

I've successfully encoded the en passant notation but now I get failed requests because of what I suspect being a castling rights notation difference.

For instance this request fails https://lichess.org/api/cloud-eval?fen=r1bqkb1r/ppp2ppp/2n2n2/3pp3/4P3/2NPB3/PPPQ1PPP/R3KBNR b KQkq - 1 5 , and It's strange since I've checked the X-FEN wikipedia page which states that

The new and crucial point of the arrangement is that the castling rights provided by this as default are related to the outermost Rook of the affected side. If instead an inner Rook is associated with that right, the traditional castling tag will be replaced by the file letter of the involved Rook, using upper case for White.

so unless I've completely misunderstood, the notation remains the same unless we have to deal with a 960 position where there are two rooks on the same castling side and only in that specific case we would specify the exact square. I have however tried using a different notation trying to replace the KQkq with the specific castling squares ("AHah" for instance) and even though it works inside the board editor I still get failed requests.

benediktwerner commented 2 years ago

There simply isn't any cloud analysis for this position so it's expected to fail. You can check the position on Lichess and it also won't give you one.

d-luca727 commented 2 years ago

Yeah later on I figured out it wasn't a notation problem and I simply forgot to edit my message to let you know. I really thought it was still a FEN issue because requests would fail every time I reached a position where castling was possible so I thought that was it. Well, thanks for helping out !