lichess-org / lila

♞ lichess.org: the forever free, adless and open source chess server ♞
https://lichess.org
GNU Affero General Public License v3.0
15.08k stars 2.23k forks source link

Analysis board does not display result #10684

Closed dlbbld closed 1 year ago

dlbbld commented 2 years ago

The analysis board does not display when checkmate, stalemate or insufficient material is reached. That must be there, it is essential game information.

Stalemate on board - result not displayed

When a game is imported, the result of the imported game is displayed. Though when the moves are changed, the result is not aligned due to the above. This ends then in strange situations with like Black win on the board but result indicating White win.

When importing the below game on the analysis board: 1. e4 e5 2. Bc4 a6 3. Qh5 h6 4. Qxf7# AB - importing

The result is Checkmate • White is victorious, as expected. AB - after import

However, when changing the game, for example, deleting White's fourth move and changing to checkmate by Black, the result is still Checkmate • White is victorious. But obviously now the result Checkmate • Black is victorious is expected instead: 1. e4 e5 2. Bc4 Bc5 3. Qh5 a6 4. Kf1 Qf6 5. h3 Qxf2# AB - after change

stevage commented 2 years ago

Yep, came here to report the same issue. It's very confusing that nothing is said when a stalemate happens:

image

dlbbld commented 1 year ago

I think it's ok to close my unobserved issues, so they are of no interest to others. If there is any planned work, at the very least, one should label the issue. But the issue has no label, so closing is appropriate to avoid stale issues. Unfortunately, I cannot work on this and do not want to overload others.

dlbbld commented 1 year ago

I am closing the issue as it does not interest me anymore. I got used to it, and the issue may be a bit too detailed and might need a more general idea anyway.

The work of developers deserves the most respect. But on the other side, creating issues is also a little bit of work. I do not like that the issue did not even get a label after half a year and that there is no attention on this work. I have had enough of this, and to keep the tracking system alive, it's appropriate to close it as stale.

benediktwerner commented 1 year ago

All you're doing by periodically closing random issues is putting more work on developers by making us read pointless close notifications and making it harder to track whether something has been fixed. Even more so if you intentionally spite-re-close it after a developer has re-opened it. A bug like this doesn't just become stale and nobody likes immature behaviour like this.

Open issues don't hurt anybody and whether it's labelled as a bug or not is completely irrelevant. If you for some reason care about it getting labelled, you can just file the issue as a bug in the first place and then it will automatically get labelled.

schlawg commented 1 year ago

About the issue itself - it seems valid, a defect in the software, and looking into it could be a good learning opportunity. Preserving both the import history and the changed result in some way might get kinda complicated for arguably little reward so I'm not surprised it hasn't been resolved yet.

I wouldn't worry about the label status as most contributors don't have permission to do that. I personally would jump on this if I weren't completely immersed in something else right now, maybe let this one live?

P.S. I've been on own-issue closing binges myself, but they never seem to be as cathartic as I had planned. ;p