EGF vs AGA pros win-and-continue match

[Javaness2]

I don't see what is amusing about it.
(Meaning that, why would you want to use the official tournament system. It's so inflexible as to be ruinous.)

[Bill Spight]

I don't see what is amusing about it.
(Meaning that, why would you want to use the official tournament system. It's so inflexible as to be ruinous.)

In this case, would it have given a different result?

Besides, is anyone claiming that the referee could not overrule either the loss on time or the loss of a byoyomi period?

[Tryss]

Edit: Are you saying that Surma could have asked his opponent to give him more time? Well, he didn't did he?

No reason for him to do so, because his only harmfull lag was during the last period, and you can't ask for more time when the game has already finished. But he asked to resume the game, and that's as close to this as what he could have asked.

[k0n0]

his only harmfull lag was during the last period

We don't know whether it was
- a lag like in previous situations
- or completely lost packets

[Javaness2]

The point I am making is that some people have been posing the narrative that we should assume that the server's decision is final. Clearly the spirit of the situation the tournament placed itself is one in which adjustments and interruptions are permissible. If they wished that not to be the case, the organisers had a second option available to them. I don't see anything remotely amusing about that.

[Bill Spight]

The point I am making is that some people have been posing the narrative that we should assume that the server's decision is final.

I am one who does not suffer fools lightly. That is ridiculous.

Clearly the spirit of the situation the tournament placed itself is one in which adjustments and interruptions are permissible.

Such as giving your opponent extra time when requested, as Knotwilg indicated is normal. Right?

[Bill Spight]

Edit: Are you saying that Surma could have asked his opponent to give him more time? Well, he didn't did he?

No reason for him to do so, because his only harmfull lag was during the last period, and you can't ask for more time when the game has already finished. But he asked to resume the game, and that's as close to this as what he could have asked.

And you are saying that the KGS timekeeping system would have done that?

[Uberdude]

In a probably futile attempt to reduce the cross-purpose wittering, Java is referring to a special 'Tournament' KGS game mode used for KGS+ tournaments where, IIRC undos aren't allowed and possibly other stricter differences from regular games like no resume after disconnect. Normal users can't make them. The automated KGS tournament system can, maybe KGS admins can too (Java used to be one). It wouldn't surprise me if Hajin/Natalia and whoever else from the Transatlantic match organisers didn't know about this. But the line of reasoning "because they didn't use KGS tournament mode which disallows undo/resume, this implies that that undo/resume are condoned in this event, and so lag out shouldn't result in time loss" seems just about as valid to me as "let's blame Mateusz for not reporting prior lag so he loses because players have a duty to protect themselves", i.e. pretty crap but good enough for lawyer-style reasoning to justify a decision you want to pick.

[Javaness2]

Indeed. Yet, I think it's an important piece of information for those wishing to argue about what the official rules were. In actuality, I don't think anyone involved had any idea what the rules minutiae actually were [perhaps were not is better], nor did they care what they were. Explaining what the two systems are in detail is very unhelpful though. Shame on you.

[Kirby]

The point I am making is that some people have been posing the narrative that we should assume that the server's decision is final. Clearly the spirit of the situation the tournament placed itself is one in which adjustments and interruptions are permissible. If they wished that not to be the case, the organisers had a second option available to them. I don't see anything remotely amusing about that.

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.

[Bill Spight]

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.

[jann]

Besides, "KGS" means three different entities here (server, client1 and client2), with different time data (with the players only seeing their own client's one). Things went wrong exactly when KGS failed to synchronize it's three parts with tolerable accuracy.

You may know more about KGS software than I, but if Surma's client kept a record of his time usage, where is it? And, BTW, how do you synchronize three different timers? Take their average? My guess is that KGS simply resolves any difference in favor of the server's time.

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.)

[Kirby]

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.

[Kirby]

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

[tneva82]

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.

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.