KGS Bugs / Fixed
This is obsolete content from KGS Bugs.
- Create a private room. Allow another player. Other player joins room. Creator leaves, room survives with other player. Creator is unable to re-join the room. The workaround of adding oneself to the allowed list (before leaving) is specifically denied.
- wms: This has been fixed. It was reporting during 2.5.6 beta testing, so it didn't get into status, but it is fixed in the newer 2.5.6 betas.
- pwaldron? The KGS rating system allow 8d and 9d ranks now. Unfortunately, the CGoban game editor considers such ranks to be invalid. It is therefore not possible to edit the game information of SGF files from games with KGS 8d and 9d players.
- wms: My tests show that cgoban 2 accepts these ranks just fine. Can you send me the SGF file that breaks?
- phenomene: I second pwaldron's observation : one can open games with 8d or 9d players with the editor without problem, but if one wants to edit the game info, there is an error message when pressing the "ok" button saying 8d or 9d is not a valid rank.
- wms: Ah, that's the problem. See, I was just looking at the files, saying "yup, shows 9d like it should." I didn't know that the problem was when you worked with the game info window. Fixed now. Thanks.
- Vlad: I had this problem lately, with the 2.5.6 client. My connection is sometimes shaky, and it happens that I play and it might take up to 30 seconds for the move to be registered. When in byo-yomi, this makes easy to lose on time. Now, why doesn't the client sent the current timestamp, so that the server will know when I actually played, and not go after the moment it receives the message?
- Fwiffo: That would rely on trusting the client, which is unsafe to do in an internet context. If time were implemented this way, it would be possible (if technically challenging) to create a hacked version of the client that lets you cheat on time. I don't know if there is a good way to implement a time system that accounts for lag without opening the potential for cheaters. We all know the sad story of gGo and IGS.
- Vlad: Mmm, true... I can think of a couple of ways to increase the safety, but none is perfect. On the other hand, I am sure you can understand my frustration for losing by time otherwise won games just because of this problem :-)
- Jared: I just lost a game on time due to a related issue. I lost my connection while on my move. I hit close as soon as I noticed the lack of response. Nothing happened. Waited about 10 seconds, then quit CGoban. 5 minutes later, when I managed to get back online, and resume the game, I had lost on time. Why the hell does the server count down my time WHEN I'M NOT EVEN CONNECTED? Naturally, VERY frustrating.
- wms: Jared, you must have an old client. This was fixed some time ago. The server will not let you lose on time until it is able to send a message to your client and get a response, so if you are not connected, you will not lose on time. Please get the latest client.
- Jared: Thanks for the quick response. I was using the latest client (2.5.7) for mac os X. When I signed back on, my time was 0, but it didn't say "lost on time" immediately. It waited until I tried to play my move, then it brought up the dialog box. So no, the server didn't let me lose on time, until it was able to send a message to the client, and THEN I lost.
- LordOfPi: This is not a bug but intentional behaviour Jared. So that you can ask for addtime because of disconnection before you play your next move. You will only lose when you play a move and your opponent didn't give you addtime. Or when your opponent clicks the 'Claim win' menuitem.
- Jared: I see. Thanks for the info, I'll be sure to do that next time.
- blubb: Under which circumstances does kgs currently assume a player to have been disconnected? Canīt kgs check the connection more often in order to avoid disconnected players losing even three or five minutes of playing time?
- kicker: The webstart client does not work on my machine. Mozilla 1.5 shows XML source code and an error message:
- "This XML file does not appear to have any style information associated with it. The document tree is shown below."
- My system: RedHat 9.0, Java version "1.4.2_03"
- Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02)
- Dang, thanks for pointing this out. When I moved the server yesterday I forgot to add the MIME types to file the web server uses. Should be fixed now.
- Mac osx still bad (tested in 2.5.8 beta even). In the screenshot http://en.wikipedia.org/upload/c/cb/Macosissue.jpg, the program on top of screen is 2.5.8 web-start. and below is the "native" mac os. Im in 10.3 with java 1.4.1. As you can see, the web-start even draws the stones better than the mac os, however there is a square surrounding each stone (even viewable in below the players names). Whereas the macosx version doesnt even draw the players names. I would really rather the problem be fixed in the web-start as it draws stones (and everything) much nicer.
- glue: this is an Apple's Java problem. Not a Cgoban's one. You are using Java 1.4 for the web start version and Java 1.3 for the OS X version. Java 1.3 has bugs that makes it crash when it displays names, so the option has been disabled. And Java 1.4 has some squares around stones display bug so wms has forced clients to use 1.3 even when 1.4 is available. I think latest 1.4.2 Apple's Java update (which is not free) fixes the square thing but introduces a new font issue.
- AdLib? As a Mac OS 10.2 user you cannot update to Java 1.4.2. So to solve the "square surrounded stones problem" you can fall back to Java 1.3.1, which is also installed. In order to let the OS know, you want to start CGoban2 with Java 1.3.1 you have to edit the file "Info.plist" which is located inside the application. (Applications on Mac OS X are folders, you just can't see that with the Finder. So you have to use the Terminal to edit the file.) In the file there is a line "<string>1.3+</string>". Just change that line to "<string>1.3.1</string>". That's it.
- When trying to save teaching games to disk from game list directly, I get an error message. Often these games are not finished and this may cause the problem. I can solve it by opening game into a room and saving it.
- wms: Yes this is a known bug. I think it may be in KGS Plans somewhere. The reason I haven't fixed it yet is that there is a workaround (as you found), and the fix is difficult. You see, when you save a game to disk without opening it first, it gets the game from the web server; private games are not accessible by the web server, so you get the error. There is no way right now for the server to send your client SGF data other than through opening a game in a room, so I'd have to add a new channel of SGF data to make this happen, or implement some kind of temporary cookie system for putting games that need downloading somewhere that you can get it safely via HTTP.
- Icepick: Often when I first connect and join the English room, I'll get 2-10 lines of text conversation from several people concatenated onto one long wrapped line. It's rather odd. I could send you a screenshot of it next time it occurs if you're not aware of it.
- Joshual000: Along the same lines, occasionally the initial chat will be part of the room header text (bolded, etc.) Perhaps chat is recieved before the room is entirely initialized.
- phenomene: I think it is a Java bug, I have got it too. It happens when people speak in the room before you look at it after connecting to the server (the tab becoming blue). A practical way to get the text back to a normal form is to unstack the room (and then to put it in back in a tab again if you like). (I apologize if my bad English makes this unclear.)
- wms: This is a java bug. I can't make it happen reliably though, so I can't report it to Sun. If anybody finds a way to make it happen every time, please let me know!
- blubb: Not sure, if it's a bug: Didn't you mean to force very fast games to be "free"? Right now, I see an offer with 0.00 minutes main time, 1* 0.10 min byoyomi, rated.
- wms: Right, very fast games are unrated, but 10 secs per move is not very fast. :-) 0.00 minutes main time, 1 * 10 sec byo-yomi, is plenty fast enough to play rated. It is only the ultra blitz games that are unrated, and 10 seconds per move is not ultra blitz; ultra blitz is around 4 seconds per move.
- Blake: I think 10 seconds per move is too fast for rated, honestly. Maybe if it's Canadian overtime 1/6 (or 10/60), it wouldn't be too fast, because you could spend 1 sec on some moves and more on others, but 10 seconds in byo-yomi certainly seems like it's fast enough to change the dynamic of the game significantly enough to require a new rating system. But maybe that's just me :)
- wms: It's not too fast. I wanted to be very sure that what is/is not too fast isn't based on "I think...", but on evidence, so I spent some time analizing the rank system's data. I had a graph up a while back on the status page (graph is gone now), it showed very clearly that the results of games down to 7+1/2 mins per player matched between faster games and slower games. The results of games below 7+1/2 mins per player were not predictable using the outcome of slower games. If the outcomes match, they use the same skill set, and thus belong in the same ranking system, so 10 secs per move (which is about 9:30 for the game by the heuristic that KGS uses), is slow enough to still be ranked.
- Blake: Well, what I'm thinking of isn't the total time for the game. Instead, it's the problem of one set time (10 seconds) per move. Consider a difficult reading problem: chances are that it is something you'd like to spend more than 10 seconds on. Consider the response to a peep (even a moron connects against a peep). That's a move you spend half a second on. You can't just add up "10s*Moves_In_Game = Time_For_Game," I don't think. There are more factors in the feeling of "time pressure" than that. Thus, 10:00 for 60 moves might be comfortably playable; but I don't think 0:10/1 is. I have no evidence, of course, but it would be interesting to see how your analysis deals with this :)
- hello If you set the time limits in a byo-yomi game to be 1 period of x seconds, its equivalent to a Canadian time set-up with 1 stone per x second 'byo-yomi time' (right?). Now for time limits close to the edge of rated/not-rated, equivalent time limits can be rated in one time system, but forced not-rated in another.
Should the paragraph above be moved to any wishlist or just be deleted? As we can see, it's no bug, and this page aims to be a buglist rather than a discussion page. - blubb
Maybe 'bug' is too strong: 'inconsistent behaviour' would be a better decription. If you think it should go on the wishlist then i must have explained it badly. - hello