My view wasn't that the server's decision was necessarily final. Rather, that the initial default "ruling" is a loss by time, per what happened on KGS. Given the situation, this doesn't necessarily seem fair, so we have a referee who can overrule KGS's decision, and make an exception to the normal timekeeping rules. And from the sounds of it, this was initially considered, even to the point of resuming the game.

Through the various information that was (non-publicly and unofficially) discussed, the end decision of the referee was to accept KGS's decision, and not make an exception for Mateusz.

We've been arguing for pages about whether this referee decision was a good one, but I never viewed the argument as one to say that a server decision is final, and not possible to be overridden. The fact that the referee considered overruling the server decision is evidence that it's possible.

_________________
it's be happy, not achieve happiness

For those crafting conditions of contest for go tournaments over the internet, a discussion of minutiae may be important. But I did not think that was what was going on here.

_________________
The Adkins Principle:

At some point, doesn't thinking have to go on?

— Winona Adkins

I think it's a great idea to talk during sex, as long as it's about snooker.

— Steve Davis

I don't know KGS internals specifically, only speculating. In rudimentary applications like KGS is supposed to be clients time data is only kept in memory and not recorded permanently (even though that would not be rare in the gaming world), and synchronization with the server is done periodically (with each move for example). So in the given moment the clock should have been frozen at client1 on the -10sec mark, flag fallen at server, and client2 may have shown a time that was only slightly drifted from the server's time. Even if syncronization is done in favor of the server (again, there are other solutions in the gaming world), that is still not automatic and continuous, so there are times when there ARE three different time data concurrently - like in this case.

BTW, one point that may be interesting for those lawyering approaches is whether the connection restored after the 10-20 sec outage or not. This may have also been witnessed by proctor but I never saw a mention of it. And strictly speaking this could make the difference between an undetected disconnection and a timing malfunction. (Not that would make a big difference to reality: a technical problem/failure that was not remedied correctly.)

FWIW, lag has been an issue sometimes for first person shooter games, and different semantics are sometimes adopted. For example, you can give advantage to the shooter’s side so if that guy’s client says he got the opponent, it’s true. Or you can give advantage to the other guy so that if it doesn’t seem he was shot on his client, then he wasn’t. Or you can play with lag metrics on the server and have different rules.

This isn’t my field of expertise, so i don’t have all of the details, but i do recall there being various options you c an adopt to make rulings in the face of lag for these real time games.

_________________
it's be happy, not achieve happiness

Here's an example: https://link.springer.com/chapter/10.10 ... -90415-3_5

_________________
it's be happy, not achieve happiness

If either client has priority then that opens up cheating so if that route would be here then rather than issues about lag you could easily have issues about cheating accusations. There's a reason why smart clients are discouraged heavily in favour of smart server.

Yup, I agree that adding rules to client makes cheating easier. Though, cheating is already possible on client side via computer assistance.

Anyway, what’s your idea for a smart server that addresses the lag problem?

_________________
it's be happy, not achieve happiness

It seems like you could easily have the client send a timestamp along with the move, not as a replacement for allowing the server time to be definitive, but as a way to offer the player feedback about the health of their connection. You could even quietly allow some very limited number of "grace" moves played late without affecting 99% of matches, and I don't think that's a policy that would be likely to be abused. I mean, it's certainly no worse than "pausing" a game by escaping and then immediately coming back to it to resume, and I don't think that I've ever had someone do that on KGS.

At the very least, if you recorded client vs server timestamp data a third party who had to make a decision about how to handle a claim of lag in an important match would have better data to do so.

After doing some research, I believe Kim Myungwan's final decision, although unfair to Mateusz and not in the "spirit of the game", is in fact, the correct decision, given the difficulty of the situation and the details of what had transpired. I still believe that Eric should have come out to resign the game in order to save the tournament from controversy, but again, it may be an unfair burden to Eric.

I also want to reference the rules here from chess.com's speed chess tournament with a prize of 10000 USD, a tournament with similar stakes and where the time control is even more important:

"No mouseslips or takebacks. There will be no rulings made to allow for "mouseslips," "takebacks" or the reversal of any move or result that happens due to loss on time because of "lagging connections," disconnections or any other online-chess-specific glitches that may occur. The player is acknowledging to be comfortable with Chess.com's online board and piece play format, and guaranteeing his/her own stable connection.

Accidental draw offers, resignations, or losses by flag via disconnection will count and the result will not be reversed. Any game results incurred due to user error by the player with the Chess.com board, pieces, buttons, or any other part of the interface are final, including but not limited to draw offers, draw acceptance, resignations, premoves, autoqueen, accidental underpromotion, any and all mouseslips, accidental clicks, or accidentally losing on time. Players are responsible for being familiar with the Chess.com interface."

Had the organizers written down such tournament rules or conditions of contest, there would have been no controversy. They are currently drafting at least temporary rules for the rest of this tournament, which should satisfy all concerned.

_________________
The Adkins Principle:

At some point, doesn't thinking have to go on?

— Winona Adkins

I think it's a great idea to talk during sex, as long as it's about snooker.

— Steve Davis

If you have to rule out a resumption because you were not there to administer it, then it is difficult to see how a referee could place the adjective correct in any subsequent decision they make.

_________________
North Lecale

Fortunately, that is not necessary.

_________________
The Adkins Principle:

At some point, doesn't thinking have to go on?

— Winona Adkins

I think it's a great idea to talk during sex, as long as it's about snooker.

— Steve Davis

In the menu File > Server stats, a "Response Time" is indicated. I wonder if its variations are slow enough to predict lag problems?

Actually, that make much sense in the chess.com tournament, because a single match is played in 3 hours over ~30 games. That's it, a match has about the same duration than in our tournament, but each individual game is much (much) shorter.

And as you said, time control is much much more impactfull.

I notice the new rules have been posted on https://transatlanticgo.org/.

Next match is on Sunday!

and on OGS rather than KGS

I wonder what made them switch to OGS. I imagine it was the lag. Can players use the score estimator during the game.
On an important note though, it is good to see that they have updated the rules to something practical.

_________________
North Lecale

So they've decided to use the proctor/local referee to avoid lag causing a loss on time in the final byo-yomi period, but that lag can cause loss of prior byo-yomi periods. OGS has the following 'feature': when lag or potentially other issues prevent successful submission of your move a message pops up "Error Submitting Move". This blocks user interaction with the board so you cannot attempt to play again, even if your network connection has recovered. It used to be that the user had to then manually refresh the page, which for me would often take between 30 seconds and a minute (when playing on my phone, I think it reloads lots of heavy javascript libraries), but in the last year or so OGS has changed that after this error message it forces a page refresh. So if this "Error Submitting Move" detector is over eager it can easily cause loss of byo-yomi periods.

Also, the facebook post has a-d not a-c:


So if Ali tells them there is a non-zero possibility of lag what next? He should go play in his local university with a beefy connection instead of at home? Or simply stating this fact earns him more lenient treatment in the case of lag?

I have had the same annoying experience with OGS when it was having a major lag session. Refresh often just meant I saw a loss on time pop up. Recently it didn't see anything like that, so I kind of assumed that they had fixed that killer feature.

How will they handle the big issue of guests logging in with handles like AtariAtO5 ?

_________________
North Lecale

On reflection rule (b) does look a bit comical. Ali will presumably still be in Amsterdam for the match, let's hope the connection there is reasonable, and that he hasn't been on a bender after the tournament.

_________________
North Lecale