Anyone else have a problem with this?

[Bantari]

@SpongeBob:

Off-topic response for daal:
On KGS there is the always present problem of lagging. Not on Tygem, where your stone is placed immediately, not after a response from the server reaches you. This makes for a whole different playing experience, imo. Another aspect is byo-yomi voice- and mouse-cursor-counting.

Not sure any of that has anything to do with being "technologically superior." To me its user/programmer preference which options you implement or not, and how.
Do you even know what technology is Tygem based on? Just curious, since I don't have a clue.
And what is KGS Server? C? C++? Java? I don't remember...
Once we know, we can discuss.

[Kirby]

Somebody expressed their preferred server - and it wasn't KGS. I think we all know where this thread is headed! Take cover before the flame war ignites!

[calantir]

You could also try OGS. Once you clear your initial provisional games, you're non-provisional for good, no matter how infrequently you play. I'd be happy to clear the provisional games for you since your rank is well established (if you're AGA 4d or so, you're probably OGS 2d). The only drawback is that it might take you a bit longer to find a game on OGS than on KGS, as the dan population is still growing.

[PeterHB]

Hi SpongeBob,

On KGS there is the always present problem of lagging. Not on Tygem, where your stone is placed immediately, not after a response from the server reaches you. This makes for a whole different playing experience, imo.

But that's an illusion, isn't it. No server can guarantee zero lag, because there are always intermediaries -- say, your ISP crashes; or any hiccup anywhere between your client and the server half the globe away -- so the author has to make a choice: either show the new move immediately on the client side, regardless of whether the move itself has actually reached the server, or, wait for the server response, then show the move.

Some people, like you, are happy to see the immediate placement of the move on your client, even if it takes a minute or longer to receive the server response. Even if it never reaches the server in the first place.

Another choice is to wait for the server response.
In this second option, if there is indeed a lag,
you find out about it sooner, because you experience the delay.

In the first option, you see your move immediately on your client,
but if there's a minute (or, infinite) delay,
you won't notice something has happened until later (could be much later).
You prefer this option.

So the issue here is not about the lag, which can happen
any time, anywhere, beyond the control of any client
Tygem or otherwise, but people's preferences for the UI.

Another approach, which I have never seen but maybe someone has already done it:
show the move immediately on the client side, and simultaneously show the server response; and if there is any lag at all, show the lag in real time.
So if the client does not receive a server response,
then start a stopwatch and display the lag, in real time.
If/when the client finally gets the server response,
then close and reset the stopwatch.
This seems to get the best of both worlds.

This does seem to be a UI issue. My suggestion would be to show the stone placement in the client immediately, but with a spinning line on it. Then when the confirmation is received back from the server, remove the spinning line. i.e. trying to have the best of both worlds.

[SpongeBob]

Continuation off-topic discussion

You are right, EdLee, to some degree this is an illusion - the signal still has to go to the server and back (latest when my oppent has played his response). But this illusion works perfectly. You just never experience any lag and can click on the last second of your byo-yomi period. I would rather avoid that on KGS . Maybe their servers do have a better response time than KGS's, too.