[ggo-discussion] Re: Bugs etc.

On Wed, Mar 05, 2003 at 06:40:53PM +0200, Jarkko Lindblad wrote:

> Nope - the stones were rendered way off - they were almost in the center of
> the squares :)
>     Resizing or whatever does not work - if I remember correctly, one needed
> to shut down the client and restart it in order for everything to be back ok
> again. Anyhow this problem has happened to me two or three times, and only
> with the last version (or two or so) of the software.

Hmm, havn't seen that myself yet. Difficult to comment right now for me.


(siblings/children)
> Having both options available would make quite a few sgf-files more
> readable - I really like that one can change the mode in Primiview.

Allright, an option should do it properly. Will be some work, as the
variation code is spread through all kind of classes where a good OO
designer would probably never put it. Then a checkbox in the first tab of
the preferences dialog and a checkbox menuitem in the View menu for
quickaccess to switch.
I was basically just too lazy to implement this feature because I personally
dislike it. Thats no valid argument, but just a motivation killer. :)


> This never happens over a quick IGS session - one needs to fool around for a
> while. This is also something I've not seen until the most recent releases.
> I'd guess you've forgotten a ";" from some line or something :)
>    Basicly the whole window is grey, with a clock showing, but not really
> much else. Also movement of windows (gGo windows) gets jerky. Only shutdown
> of gGo helps.

Same as above, Ive not seen that myself yet. However, I remember similar
reports from two other users both running Win98, one sent me a screenshot.
I've been under the impression that parts of the Java 2D code has big
problems on Win98. I don't have Win98 installed and won't installed the
piece of junk on my box just to test this. Im using gGo on Windows 2000
quite frequently, and there things seem to be fine.


> Btw, doing this is not simple - a suggestion: allow editing when the game is
> over - I very often want to go back my own games to see what went wrong or
> if an interesting variation would have worked or whatever, and it is kind of
> a joke to have a client integrated with a sgf-editor and having to do a
> save&load in order to go through a game :) It is a bit like having an office
> suite without the possibility to directly import/export data between the
> applications. So please, after the game is over, enable editing.

Allright, I will put the "Edit game" menuitem back in the "Edit" menu, when
the game is over. It's one click more than the button in the sidebar, but I
guess that's no big deal. Having suddenly a new button appear in the sidebar
should look a bit odd. Or I change one of the existing buttons which should
be useless then (Undo, Resign...) to "Edit game".


> Oh, this reminded me of a question: does gGo support playing multiple games
> concurrenty? I think Ambassador does support it in principle, but I seem to
> remember that IGS itself might not offer proper support for all the game
> related commands. I just wanted to ask this as I was matched yesterday a
> couple of times while I was playing already.

I've tested it a bit, multiple games basically work, but not very well. Some
commands like resign, adjourn etc. require the gameID to be sent as well,
but gGo would currently only sent "resign", which IGS would not accept. You
can workaround that using the telnet console. I need to clean up some things
there. So, it basically works, but not well enough to call it a working
feature.


> Related issue: how about a match filter? If one defines a match filter of
> 1-5 to 5-10 and 1d* to 3d*, then the client could automatically decline all
> the matches outside of these parameters (if filter is enabled - one must be
> able to disable it as well).

Very good idea!

Right now gGo only does the brute force killing. If you put someone on the
ignore list, the client blocks all incoming tells and match requests. This
is a bit rough and lacks flexibility. However, match filter would have
nothing to do with killing a certain player. I still lack a good concept for
the PID, and I must admit Ive never understood exactly what Ambassador is
doing with all the information Im giving it ("Friend", "Administrator") etc.
The help texts partly suggest "Ambassador might use this information.", but
doesnt tell too much about it.

And I do use Ambassador occasionally, I actually consider it one of the top
notch clients featurewise. It looks ugly to todays standards, but that
doesnt make it bad. The other high level client is Xgospel, which is also
ugly but beats gGo concerning features to the ground.


> Another related issue: please add some kind of artwork (like black/white
> stone in the background) to the match-requester window - for me it very hard
> to see who played with what color now. I don't like to play weaker players
> with black, and sometimes this happens now. Some kind of colorcode would
> make a big difference.

I'm a horrible artwork designer. I will ask tweet if he has an idea, he
basically did all the nifty artwork. I'm very bad at that, so I just don't
start doing that stuff as it won't have a good result (know your limits).


> Other ideas:
> 
> Variation markers: in my opinion, both ways of marking variations are
> confusing - I propose a third way: small and semitransparent stones - this
> way the board would look less messy with tons of variations.

Hmm, might try to make the currently second display ("Small stones")
transparent and see how it looks. I find the current Small stones display
quite nifty for Kogo.


> Oh, about kill filtering: there must be a quick and fast and easy way of
> "killing" from a match requester. Also when I "kill" someone, I'd like to be
> able to add a comment to myself why someone got killed. Also having
> different levels of "kills" would be cool (decline matches, decline
> communications and matches,...).

See above. Ok, if you want to kill someone from the match dialog, you
require two clicks, one to open the playerinfo dialog, and then kill him
there. But Im reluctant to clutter or enlarge the match requester dialog, as
that thing constantly pops up in occasionally huge numbers, so the info
displayed should be somewhat limited to the essential things.

I currently lack a good concept for a PID I like and I partly dont yet
understand what exactly Ambassador is doing, so if you want to fiddle a bit
with that, that would come handy.


> Regarding the PID, I could try to do some class planning/coding regarding
> this for you at some point? I've never done any Java, but isn't it basicly
> more or less C++?

Java is like C++, but easier. Most of the nasty things like multiinherit and
virtual functions, manual memory allocation and deallocation is removed. The
Java syntax is quite similar to C++. I learned C++ first and later went to
Java. I found Java very easy to learn knowing about C++ already. As usual
with programming languagues, the difficulty is to know the available
libraries. And the libraries bundled in the standard edition are already
huge. But the documentation is pretty good, much better than what I saw for
some C++ libs.


 Peter

Other related posts: