Is KGS developement dead or just slow?

[asura]

That the stone sound helps to notice when a stone get played is a real effect no matter of the age. While in a slow game it doesn't matter much if you see the move a few seconds later - it can be also an advantage if you don't interupt your thinking - in a 10 sec blitz it's quite much.
(Even more severe is if the byo yomi warning is missing)

If I play without sound I try to look regulary on the last stone that I've played, then when I don't notice the new stone I see that the mark from the my stone is gone.
The bad thing with this is that when i look on my last stone I often regret to have played there...

[Boidhre]

I disagree with neither of you about KGS's origins. I don't speak specifically about them because, well, I wasn't around for the transition from IGS to KGS by the Western community and have only read about it here and there. My point was that it doesn't matter now. KGS is no longer the young, game-changing server that it was back in the day. It could be quite a bit behind other servers and still hold onto members in the short term just due to the inertia effect you both mention regarding the early days of KGS taking people from IGS. Pointing to server populations as a measure of how good a server is generally is incorrect, just as pointing to IGS in the early days of KGS and saying it was a better server because it had the big population would be equally odd.

I always used think of OGS (RIP) and DGS. I found DGS horrible in comparison to the feature set of OGS, I could never understand why DGS was so, so much larger until I remembered the inertia effects in post-monopoly markets.

This is more or less missing the point I'm trying to make, allow me to summarize it:

An important (perhaps the most important?) feature of a go server is having a person or core group of people putting a large amount of energy into it for an extended period of time. There is no shortcut to this step.

This is true. Apologies that I missed it. I'd add that having a core, visible, group of users will be very important too. For any site to grow big it'll grow organically due to the community not due to the people admining/running it. Though, remove the admins and the thing falls apart usually.

[raptor]

KGS has a sound rank system

now if it also had a sound system..

and sometimes you can even chat with someone about god

yes, when no admins are on, or you will be banned

someone even already posted on this forum details how he fixed the sound bug by hacking the client himself apparently, but didn't release it cause wms said he doesnt want that or something. and that was like ages ago?

disclaimer: i havent checked google+ cause I dont do google+.

edit: I found the sound bug threads
wms stating he's going to fix it in july 2012:
viewtopic.php?p=105903#p105903
c.blue was it who said how he fixed it himself:
viewtopic.php?p=122502#p122502

[raptor]

Holding up the efforts of William to create an html5 client that nobody asked for

An html5 client would fix all java related issues (including the sound bug) as well as enable playing on iOS devices. I would say that these things have most definitely been asked for. Also people seem to be pushing for browser based clients (even if I don't agree with them). The fact that he keeps a blog of development progress seems to make it harder to claim development is dead.

I dont know a single go-playing person who would not prefer a stand alone client over browser nonsense. We've talked about kgs and everyone much rather wants an actual client app.

[Bantari]

Holding up the efforts of William to create an html5 client that nobody asked for

An html5 client would fix all java related issues (including the sound bug) as well as enable playing on iOS devices. I would say that these things have most definitely been asked for. Also people seem to be pushing for browser based clients (even if I don't agree with them). The fact that he keeps a blog of development progress seems to make it harder to claim development is dead.

I dont know a single go-playing person who would not prefer a stand alone client over browser nonsense. We've talked about kgs and everyone much rather wants an actual client app.

You are living in a small world.

But this is not the point in having a browser-based client. Its not about "I rather have in-browser" or "I rather have stand-alone". Its about access in portables, and then maintenance of one app versus many. Browser-based approach lets you access all devises with pretty much one codebase. Stand-alone solution requires a few (at least 2, I guess) applications. And for one-person show - its a BIG difference.

You know people who like playing via their portables, I assume?

[walpurgis]

I dont know a single go-playing person who would not prefer a stand alone client over browser nonsense. We've talked about kgs and everyone much rather wants an actual client app.

Does anyone know if CGoban3 will continue to work and/or be supported or upgraded once the html5 client finally goes live?

[Bonobo]

For me the issue has never been “actual client app vs. browser app”, it’s about the use of Java.

If I could have a native OS X app with all features of CGoban (without the latest sound “feature”, that is ) this would make me MOST happy. I’d even PAY for it. I’d even pay IN ADVANCE for it if I knew it would motivate WMS.

I can imagine that for quite a few people who call(ed) for HTML5/web application for KGS the main reason was that they don’t want to use Java any more, and that most of them would be just as happy, if not even happier, if they could get a native application for their respective OS. At least for me this is the case.

The downside of the web version, for me, is that it only runs with internet connection, obviously. And CGoban still is the SGF editor which I best know to use.

Greetings, Tom

[Bantari]

For me the issue has never been “actual client app vs. browser app”, it’s about the use of Java.

If I could have a native OS X app with all features of CGoban (without the latest sound “feature”, that is ) this would make me MOST happy. I’d even PAY for it. I’d even pay IN ADVANCE for it if I knew it would motivate WMS.

Same here.

I can imagine that for quite a few people who call(ed) for HTML5/web application for KGS the main reason was that they don’t want to use Java any more, and that most of them would be just as happy, if not even happier, if they could get a native application for their respective OS. At least for me this is the case.

I though the Java thing was only because iPad does not support it... I am running Java and CGoban on my OSX, and Java is pretty much the only thing I use it for these days - but I have absolutely no complains. So for me, it is strange if people don't want to use Java... what is wrong with Java? Other than the obvious sound issue people are complaining about? (And I don't even know if the sound works on my computer - like DrStraw, I turned the ugly thing off right at the beginning.)

The downside of the web version, for me, is that it only runs with internet connection, obviously. And CGoban still is the SGF editor which I best know to use.

There is really no reason I can think of not to keep using the CGoban for SGF editing purposes if you really like it.

But I guess if there is a need, somebody will fill it, so maybe we should expect a new, killer-featured SGF editor to be written by some enterprising soul in the near future? Hint hint... I mean - people are saying so often about how we could develop a better KGS client if only WMS open-sourced the protocol... how about starting small - just write a better SGF editor? Its a much simpler task, no? See it as a challenge to all those who ask/demand CGoban protocol to be opened so they can write clients.

[hyperpape]

In order of awesomeness:

1) A fully functional native app for every platform I use (that's three currently, but I might swap one of those three out for a new one before too long). Oh, and each of them should be consistent with that platform's UI conventions.
2) A really well done web interface that works in a variety of modern browsers, but also my iPad 1, which has a relatively limited browser in some regards.
3a) A mediocre web app.
3b) Java.

Well, 1 is out of the question. Almost no one manages it. Your best bet is to make nice iOS and Mac apps, and then do a weaker job on Windows and Android in hopes that their users are less picky (but they probably still won't be content). 2 is damn hard, but conceivable--especially if you relax some of the backwards compatibility demands.

3a & 3b are eminently doable, but WMS has said he's tired of fighting with Java. On various days, I can't decide which is worse. Probably Java, because it's a pain to install on new machines.

I think 2 is a sort of sweet spot: you can do well enough with a browser based app, and you can even get a number of benefits of native apps by creating platform specific apps that are just wrappers around the web interface.

[Bonobo]

In order of awesomeness:

1) A fully functional native app for every platform I use (that's three currently, but I might swap one of those three out for a new one before too long). Oh, and each of them should be consistent with that platform's UI conventions.
2) A really well done web interface that works in a variety of modern browsers, but also my iPad 1, which has a relatively limited browser in some regards.
3a) A mediocre web app.
3b) Java.

Thank you, this is exactly what I’d intended to express with my last post above, I’d even thought of making such a list but then forgot it.

[skydyr]

1) A fully functional native app for every platform I use (that's three currently, but I might swap one of those three out for a new one before too long). Oh, and each of them should be consistent with that platform's UI conventions.

...

Well, 1 is out of the question. Almost no one manages it. Your best bet is to make nice iOS and Mac apps, and then do a weaker job on Windows and Android in hopes that their users are less picky (but they probably still won't be content).

Why do you assume that time is best spent on iOS and Mac? They seems like they have a smaller userbase than Windows.

[Bantari]

1) A fully functional native app for every platform I use (that's three currently, but I might swap one of those three out for a new one before too long). Oh, and each of them should be consistent with that platform's UI conventions.

...

Well, 1 is out of the question. Almost no one manages it. Your best bet is to make nice iOS and Mac apps, and then do a weaker job on Windows and Android in hopes that their users are less picky (but they probably still won't be content).

Why do you assume that time is best spent on iOS and Mac? They seems like they have a smaller userbase than Windows.

#1. Because I assume he speaks for his own preference, as indicated by the "I" in the phrase "for every platform *I* use"

#2. Because Windows users are generally less picky by definition - or they would not be using Windows.

Hope this helps.

[oren]

Why do you assume that time is best spent on iOS and Mac? They seems like they have a smaller userbase than Windows.

Everybody wants the client on the system they use.

[skydyr]

Why do you assume that time is best spent on iOS and Mac? They seems like they have a smaller userbase than Windows.

Everybody wants the client on the system they use.

Sure, but as a developer, I'd want to target the majority of my resources to the platform that would get the most use.

[Boidhre]

But this is not the point in having a browser-based client. Its not about "I rather have in-browser" or "I rather have stand-alone". Its about access in portables, and then maintenance of one app versus many. Browser-based approach lets you access all devises with pretty much one codebase. Stand-alone solution requires a few (at least 2, I guess) applications. And for one-person show - its a BIG difference.

You know people who like playing via their portables, I assume?

One app, all devices, is pretty much why we see so much Java in go clients. The problem is, its Java and bring a lot of problems along with that cross-platform ability.