bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnubg] Tutor mode patches for gnubg


From: Joern Thyssen
Subject: Re: [Bug-gnubg] Tutor mode patches for gnubg
Date: Wed, 24 Jul 2002 16:23:54 +0000
User-agent: Mutt/1.2.5.1i

On Tue, Jul 23, 2002 at 09:29:50PM +0200, Jim Segrave wrote

> I originally included a gdk_beep as well, but removed it, because, as a
> matter of personal taste, I dislike noisy programs.

We can introduce a fBeepTutor (similar to fBeepIllegal).

> Evaluations are done using the same code as hint, so a user who has a
> significant difference between their analysis and evaluation settings
> may get warnings which don't show up in a post-mortem or not get
> warnings for play which is flagged in post-mortems.

I think it's vice-versa: tutor-mode uses AnalyseMove which uses
esAnalysisCube and esAnalysisChequer, whereas hint and eval uses esEval.

So tutor mode may flag a move as bad, but the hint dialog may say that
you're making the correct move (that actually happened to me).

I see no problem in that. Although it might be better to use the
evaluation settings instead of the analysis settings?

> 
> No attempt is made to save any evaluation results, so if AutoAnalyse
> is also set, I believe each move would be fully evaluated twice. 

Tutor-mode does exactly what I originally intended auto analysis to do,
so I think we should remove auto analysis. 

> Poosible bugs:
> 
> The code is, needless to say, only lightly tested, although my level
> of play gives it a fair workout. 
> 
> I've not done anything extra to deal with issues of events occurring
> while an analysis is running, I'm assuming that that's already dealt
> with (and if not, then the fix belongs at a lower level than this,
> since other things, like auto-analysis and gnubg choosing it's next
> move will be similarly vulnerable).

I think this is fixed now with Gary's fix from July 17.

> Another possibility, again less intrusive than a pop-up window, would
> be to add a region to the board itself for the response buttons (in
> the same way that the take/pass buttons only appear when the player is
> doubled). 

Personally, I think the pop-up is fine. Of course, I play
near-perfect, so it doesn't seem that intrusive *cough cough* :-)

> This might be better, but a) I did not fancy playing with
> the code in gtkboard.c and b) I admit that I'm still not clear how the
> board makes the buttons appear and disappear (gtk_widget_hide () of
> the button box is not it, the board would be re-sizing if you do
> that).

It uses some GtkHButtons: takedrop, rolldouble, agreedecline, and
play. Check board_size_allocate, I think it does the magic. 

I think you could add a new GtkHButtons tutormodechequer, tutormodecube
etc, and just copy the magic in board_size_allocate and update_buttons.

> Perhaps it should allow the user to select the level at which it
> issues warnings (so that it wouldn't interrupt play for a 'doubtful
> move', only a 'bad' or 'very bad' play.

I agree.

> It might be desireable to allow separate selection of which types of
> play get watched - chequer or cube, possibly chequer, doubling and
> responses to doubling.

I agree.

I've only a played a few games with tutor mode, and I must admit I
really like it.  Thank you very much for the patch! I'll take the
liberty to commit the code to the CVS repository (and remove the auto
analysis).

Jørn

-- 
Joern Thyssen, PhD
Vendsysselgade 3, 3., DK-9000 Aalborg, Denmark
+45 9813 2791 (private) / +45 2077 2689 (mobile) / +45 9633 7036 (work)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]