[ggo-discussion] Re: A few bugs

On Fri, Dec 06, 2002 at 06:54:30PM +0200, Jarkko Lindblad wrote:
> 
> 
> > I disabled the false-eye-detector for IGS games again. The problem is, IGS
> 
> Great.

It's in pre7 now. Tried scoring some odd positions in IGS games, old way
again. False eyes are territory, both displayed in gGo and in the IGS score.

However, I must admit I thought IGS would score false eyes not as territory
(like KGS does), so I thought gGo was actually showing false scores before.
That was wrong.


> The reason why I like to see the score counted during scoring and not only
> afterwards is that it is easier and faster to notice when all the dead
> stones have been removed. This is why I would also like to see a dame count
> shown -  one would never accidently press 'done' if the dame count is
> something like 42 :)  - when I play with the Ambassador (well, nowdays I
> don't really bother to boot the emulator that often so I rarely use it even
> though it still is the best thing since sliced bread :)), I always check the
> number of dame on the board visually and then compare it to the dame count
> Ambassador tells me. This has often helped me to notice a single prisoner
> not removed.

Agreed, showing the score is nice and I personally like it in own games,
too.

Btw, the false-eye code has the sideeffect, it counts dame points. I didnt
have this before. So I might as well display them now.

However, there is never the guarantee that gGo and IGS scores are equal. The
gGo scorer could always do a mistake. Tho, it seems to work pretty well.


> The problem with the false-eye-detector is that it does not work properly at
> the moment - it (sometimes) treats valid poits as dame, so you need to do
> some fixing there.

Well, the code is new, I cant exclude it has mistakes. I tried on a couple
of selfmade positions and some real games, which seemed to work. But as we
dont use it for real games scoring anymore, the whole false-eye stuff is
merely a cosmetical addition for the editor. However, still a nice feature
IMHO.


> Basicly I meant lag - as I use (usually) a gprs-modem, the latency I
> experience is quite high. But this can't really be the reason for the
> problem as the 'refresh board' menu item shows the black's first move, but
> doesn't allow me to make a move as the client doesn't realize that black has
> moved even though the move is there (w/o the last move indicator). (That
> menu item only refreshes the board locally and doesn't send aything to IGS,
> right?)

The menu item does: 'refresh 123' and 'status 123'. Refresh to get the last
move including time info, status to read the complete board position again.
So the menu item is more powerful than a simple refresh in the terminal
input, as it will force the complete board to be read in again. As far as I
could see, it managed to restore every messed game so far. Tho I hardly got
messed games lately anymore.
The black-move-doesnt-show-up has completely vanished from my box since the
0.3 release.

If you only want to redraw the board, best thing is to resize the window a
few pixels, this will force Java to redraw the window. Btw, this was the
best "workaround" for me to get the first black stone if it had not shown up
somewhen in release 0.1.whatever.

I agree, lag is most probably not the reason for this. At some point the
moves *does* come in, and the board will just idle until it gets it. I
suspect the problem rather occurs if the move comes in while the board
opens. However, the IGS thread waits until the board is pained, and then
sends its moves, so the board should not swallow the moves.
The IGS thread also wont swallow moves, as the input stream also runs in an
own thread, so all incoming lines are cached.
I suspect something goes wrong in the semaphore mechanism, however - and I
repeat myself here - this is horrible to find as I dont get this error
myself at all anymore with the latest release, and in earlier versions I got
it very rare - and only on Windows.

 Peter

Other related posts: