If the state of the board has been changed by one player, stop the other player from accepting the score for two or three seconds. This would prevent someone accidentally accepting the score just as another player has marked stones dead/alive. You could also have the message “board state changed” appear above the accept score button just to make it abundantly clear that the living status of stone has been recently changed.
15 Likes
I have previously suggested that the accept score command from client to server should not simply accept the score as currently stored on the server on receipt of the command, but include (a hash of) the board position and score markings that the client user saw at the time of them deciding to accept the score, but was told this is already how it works. But given the continued problems with score changes and cheating being inadvertently accepted I agree adding in some delays would be a good idea. To avoid these delays compounding and being annoying I would also suggest they come with a change to a batch mode of score markings: rather than each client’s marking of a chain/region as alive/dead/neutral being sent to the server and relayed into the other client’s view immediately (with its current simultaneous change problems), each client should build up that state of all chain markings locally, and only once they are happy with the entire board state do they click a “propose markings for scoring” button which sends all those markings to the server. If the other user proposes the same set of markings that is the agreed score. If not the differences are highlighted and the process repeats until they come to agreement, or there is some timeout with auto-score or moderator intervention process.
4 Likes
Yes, I’m pretty sure it is - I investigated a case recently (that person complaining about this) and this is what I thought I was seeing: an accept being sent with a board that does not match the latest the server has - which results in the status of that player being “not accepted yet”.
I think this is a different problem than the proposed delay solves.
The delay solves the problem of the board that they are going to accept getting updated without the player noticing … presumably while their finger is in flight towards accept on the score they want to accept.
I clicked like on the OP’s idea because I do like it, but I didn’t chime in further at that time because I have deja-vu about this. I feel like we’ve been around that solution before and yet we no longer have it … must be for some reason 
4 Likes
See my edit, without a change to batch mode too, a delay would get quite annoying if you are both marking 20 dead stones.
2 Likes
I guess the delay counter would just restart on each new stone marking update, so that’s not really too bad?
It’s net the same as if they’re batched up and sent with the last one…
1 Like
This used to exist, I believe. See this PR which removes the 1.5s timer to disable the button.
2 Likes
Please don’t…this might break 3rd party clients that don’t know to listen for a delay 
Also i don’t like the idea of not being able to accept immediately but i also don’t deal with as many score cheaters as beginners probably do.
FWIW, I think the delay was just implemented client-side when it did exist. Which seems like the right choice.
Server-side, requiring the full list of removed stones in the accept message should be sufficient.
At Use AI scoring to eliminate score cheating - #32 by PJTraill I proposed what seems to me a reasonable interface for scoring (not by using AI!). Essentially, players should adjust markings independently, be informed of disagreements after both have done so, and resume play if they cannot reach agreement. This removes the need for the delay proposed by OP.
4 Likes
^^ Isn’t this what we already have, pre-populated by the auto-scorer?
Oh, I see a difference - if the players don’t submit agreeing scores play resumes.
I reckon this is just another way of implementing a delay TBH.
Did you follow the link and scroll to the proposal at the end? The main difference is that your board is not updated by your opponent’s markings. Instead, once you have marked dead groups to your satisfaction, you are told where you’re opponent disagrees. That may lead players to change their markings to agree. If not, play resumes.
There is no delay involved in the sense of waiting a fixed time before relaying information. Instead you wait for your opponent to be ready. Of course we would need a timeout for that, as there is now for accept stones. The whole point is to avoid a race condition.
1 Like
I like that proposal a lot!
One technical/UI challenge would be how to show the user two states is the board (your own and your opponents proposal). Although what we really need is to just show where the opponent disagrees, which could be done with some kind of highlight. Or maybe the board could briefly flash the opponent state to highlight where the changes are?
Sounds solvable for sure, but probably requires a fair bit of tinkering to find what works the best for everybody.
2 Likes
I think some sort of highlight of the disputed stones would do the job: perhaps simply a cross overlaid over the marking on each stone, red to stand out for those with normal colour vision (while everyone can see the cross). I am not a fan of flashing, which is too easily missed, and no longer there while you are thinking about the reasons for and consequences of changing the markings.
1 Like