fix: show standard points when custom points match standard value in broadcast player results by CloudyDino · Pull Request #2943 · lichess-org/mobile

CloudyDino · 2026-04-10T14:58:15Z

Summary

In broadcasts with custom scoring (e.g. Norway Chess armageddon format), individual game results in the player results screen could show incorrect point values compared to the web.

The root cause was in the display condition for custom vs standard points. The mobile app checked customPoints != 0.5 to decide whether to show custom points, while the web checks whether custom points are non-zero AND differ from the standard points value (link: lila/blob/master/ui/analyse/src/study/relay/relayPlayers.ts#L449). This caused a draw with 0 custom points (e.g. a classical draw in Norway Chess where points are awarded via the armageddon game instead) to display "0" on mobile instead of "½" as shown on the web.

Changes

Added a value getter to BroadcastPoints that returns its numeric equivalent (1.0, 0.5, 0.0)
Updated the display condition to compare custom points against the standard value instead of a hardcoded 0.5, matching the web logic
Added 16 unit tests covering all combinations of standard/custom points display

Before/After

Standard pts	Custom pts	Web	Mobile (before)	Mobile (after)
½ (draw)	0.0	½	0	½
½ (draw)	0.5	½	½	½
½ (draw)	1.5	1.5	1.5	1.5
1 (win)	3.0	3	3	3
1 (win)	1.0	1	1	1
0 (loss)	0.0	0	0	0

Before	After

veloce

Thanks. Will approve once the tests are re-written like explained in the code comment.

veloce · 2026-04-13T11:15:53Z

+
+/// Replicates the display logic from [_GameResultListTile] in
+/// broadcast_player_results_screen.dart to verify it matches the web behavior.
+String displayedPoints({


This is not a good way to test that. We want to actually test the real function used in _GameResultListTile, not a replicated one. Unit tests are fine if they actually test the real function, but in my opinion widgets tests are better since the flutter test framework makes it easy to write them.

This test suite should be done in a broadcast_player_results_screen_test.dart, and we need widget tests that test the actual content displayed on screen. This is how all the tests work in this repository.

I think the rewrite should be ready for review!

…broadcast player results When a broadcast round has custom scoring (e.g. Norway Chess armageddon), games where custom points equal 0 (e.g. a classical draw that goes to armageddon) were incorrectly showing "0" instead of "½". The web correctly shows the standard result by checking whether custom points differ from the standard value. Align mobile logic with the web by comparing custom points against the standard numeric value instead of a hardcoded 0.5. Fixes lichess-org#2940 Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

Tests the condition that decides when to show custom points vs standard points in broadcast player results. Covers all combinations including the Norway Chess armageddon scenario from lichess-org#2940 where a draw with 0 custom points must display ½ instead of 0. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

…s display Address review feedback: exercise _GameResultListTile directly via BroadcastPlayerResultsScreen rendering instead of duplicating its display logic in a unit test. Mock at the HTTP layer per CLAUDE.md.

veloce

LGTM!

ijm8710 · 2026-04-29T02:21:08Z

@CloudyDino should this also be changed for the colored result on the broadcast screen as well? I think the app handles it differently than web

ijm8710 · 2026-05-04T19:36:55Z

@CloudyDino should this also be changed for the colored result on the broadcast screen as well? I think the app handles it differently than web

Hey @CloudyDino just in case this one slipped through. I can create a separate issue ticket if necessary. Should it be changed here too to match web?

allanjoseph98 · 2026-05-27T11:34:57Z

Sorry I only saw this PR today. Concerning your table 1st row, web showing "½" when the points scored was 0 was definitely not intended. We always want to show the actual points scored.

ijm8710 · 2026-05-28T10:56:11Z

Sorry I only saw this PR today. Concerning your table 1st row, web showing "½" when the points scored was 0 was definitely not intended. We always want to show the actual points scored.

Hi @allanjoseph98 any chance to ask if you know how to properly calculate the denominator? I see for example for chesscom they say 9.5 is the # of games for Magnus. It appears this is because he's played 3 normal point rounds (up to 9 points) and one tiebreak round (worth up to 0.5 a point) but since the tiebreaks are not necessarily evenly distributed (for example keymer has all 3 tiebreak rounds so his is 3x3.5 for 10.5)
I'm guessing this is probably right but either way
Technically there have been 3 normal rounds so us showing 4 as a denominator right now before round 4 even starts makes zero sense to me so im assuming something is wrong whether chesscom is doing it right or it should be another way

ijm8710 · 2026-05-28T11:27:40Z

Another question too (so I posted 2 today :) )

For a draw in Armageddon in Norway

Currently an Armageddon tie as white shows on web and app as 1/2. This is almost assuredly wrong. It should be 0 right (for the games in this tournament list)
- for both the game result screen and the list of results view: should tiebreaks show with green/red or neutral? Technically black is awarded the points so one side gains and one doesn't but it's a drawn game so unsure how it should show for each color-wise
For black it's also showing as 1/2. Conversely a tiebreak win shows as 0.5. Is this intended that one uses decimal and one fractional?

Bibsara-divya for round 3 women and Westley/keymer for rounds 3 men are good references games for this

allanjoseph98 · 2026-05-28T12:39:57Z

That's why I have discouraged the use of the denominator (almost) everywhere. In the one place where it does show up, think of it as Score / No. of games played.
I have opened multiple PRs both here and for the web to close some of the consistency issues to do with custom scoring. It should be fixed in a week or 2.

ijm8710 · 2026-05-28T12:56:22Z

That's why I have discouraged the use of the denominator (almost) everywhere. In the one place where it does show up, think of it as Score / No. of games played.

I have opened multiple PRs both here and for the web to close some of the consistency issues to do with custom scoring. It should be fixed in a week or 2.

In my mind I view part 1 as the score out of the optimal score. For example in a normal 0-1/2-1 scoring format, if you score 8.5/9 you scored 8.5 out of 9 possible points
So if I had full authority, I would say it should be (as of round 3) "/9". (out of 9)
I like this because it still adheres closest to the normal non multiplier scoring system but on a weighted level.
It also gives everyone the same denominator across the board.
So in this case as of round 3 everyone would be out of 9 rather than some players having a denominator out of 4 and some having 6.
I understand your preference to not have it at all, but either way it's shown so might as well make the best of what we have

I respect your opinion so what are your thoughts on this suggestion. I thinks it's a little more effective than what we have currently

For part 2, I made some edits. Is all that I said worth a ticket in some way. With the colors and also the decimal vs fractional inconsistencies. I edited the comment to be a little clearer becuase sometimes I was taking the "games in this tournament list" and other times about the game result screen.

Lastly, I have one more suggestion to run by you first before potentially creating a Lila ticket and if that passes pushing for it on app too.
Currently on web we precede each row with a number for each game. I personally prefer it to be round based rather than game based so it's easier to reconcile that the 8th game down may be for round 7 (and that 1 game earlier was a tiebreak game).
So my suggestion would be to be like:

1 2 3 3a 4
a being for Armageddon.
Do you have any thoughts on using rounds as the row header as opposed to games? I think it'd be a little easier to follow. Perhaps my notation is not the best (could also use └Armageddon but I like 3a better) but just some way to suggest that the round 3 Armageddon game is a subset of the round 3 game that was drawn before it.

allanjoseph98 · 2026-05-29T15:57:49Z

The only reason I haven't removed the denominator is because it has slipped my mind. I would sooner do that than try to normalize scores based on theoretical max scores. The way chesscom does it (per-game) is the most straightforward and makes sense to me. I'd perhaps do it too at some point but I don't deem it an immediate necessity. What you suggest is even more convoluted. Knowing which round to define your max theoretical score on is hard to do automatically. Any broadcaster intervention is also something to be discouraged to avoid proliferation of round based settings.
I said I was fixing things. Web should be patched soon-ish. Mobile app whenever the next release is. Make a new issue after that.
Make an issue for that on lila.

ijm8710 · 2026-05-29T17:03:13Z

The only reason I haven't removed the denominator is because it has slipped my mind. I would sooner do that than try to normalize scores based on theoretical max scores. The way chesscom does it (per-game) is the most straightforward and makes sense to me. I'd perhaps do it too at some point but I don't deem it an immediate necessity. What you suggest is even more convoluted. Knowing which round to define your max theoretical score on is hard to do automatically. Any broadcaster intervention is also something to be discouraged to avoid proliferation of round based settings.

I said I was fixing things. Web should be patched soon-ish. Mobile app whenever the next release is. Make a new issue after that.

Make an issue for that on lila.

Thanks, created issue on 3 and will standby on 2

For 1, I do hope we still keep some denominator regardless. Even if it's eventually chesscom format that works (understood it's not a priority), but lmk if you want me to create a ticket

veloce reviewed Apr 13, 2026

View reviewed changes

CloudyDino and others added 3 commits April 22, 2026 11:13

test: replace unit test with widget tests for broadcast player result…

3de99dc

…s display Address review feedback: exercise _GameResultListTile directly via BroadcastPlayerResultsScreen rendering instead of duplicating its display logic in a unit test. Mock at the HTTP layer per CLAUDE.md.

CloudyDino force-pushed the fix-2940 branch from 16eb799 to 3de99dc Compare April 22, 2026 16:35

CloudyDino added 2 commits April 22, 2026 11:39

test: drop tournament-specific aside from test name

31979d3

test: match broadcast test conventions (kPlatformVariant, pump comments)

4e2e7e7

CloudyDino requested a review from veloce April 22, 2026 16:50

veloce approved these changes Apr 25, 2026

View reviewed changes

veloce merged commit dd6b720 into lichess-org:main Apr 25, 2026
1 check passed

HaonRekcef mentioned this pull request Apr 25, 2026

only display * for ongoing games #3050

Merged

allanjoseph98 mentioned this pull request May 27, 2026

Fix: broadcasts result showing "½" when points scored was 0 #3247

Merged

Uh oh!

Conversation

CloudyDino commented Apr 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Before/After

Uh oh!

veloce left a comment

Choose a reason for hiding this comment

Uh oh!

veloce Apr 13, 2026

Choose a reason for hiding this comment

Uh oh!

CloudyDino Apr 22, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

veloce left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ijm8710 commented Apr 29, 2026

Uh oh!

ijm8710 commented May 4, 2026

Uh oh!

allanjoseph98 commented May 27, 2026

Uh oh!

ijm8710 commented May 28, 2026

Uh oh!

ijm8710 commented May 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

allanjoseph98 commented May 28, 2026

Uh oh!

ijm8710 commented May 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

allanjoseph98 commented May 29, 2026

Uh oh!

ijm8710 commented May 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

CloudyDino commented Apr 10, 2026 •

edited

Loading

ijm8710 commented May 28, 2026 •

edited

Loading

ijm8710 commented May 28, 2026 •

edited

Loading