scidvspc-devel Mailing List for Scid vs. PC

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi,

Have added a snap which contains the 960 patch. It is available at

https://snapcraft.io/scidvspc-960-hkvc

-- 
Keep ;-)
HanishKVC

Hi,

This updated patch now also takes care of

1. Sending IfModifiedSince request header based on LastModified (if
available in response header) else time of fetching. NOTE: However
currently lichess servers seem to ignore IfModifiedSince

2. If the specified Online PGN url leads to network error, then the
logic will stop trying to fetch after few retries.

3. the https fetch repeat logic has been made generic, so that
technically if required other logics can also use it (provided they
follow the mentioned conventions, onlinepgn helpers can be used to
understand the conventions).

-- 
Keep ;-)
HanishKVC

Hi,

This version is updated wrt the following

1. allow user to not only specify the online pgn url, but also allow
them to specify the interval between refetching of the same. However
this is still subject a minimum interval, which they cant go below.

2. alert user, if they have some database open already, when they are
about to use online pgn feature. Given that the online pgn will be
imported into current db.

3. handle user not specify any url or time interval gracefully.

4. add a simple generic multiple input/entries based dialog

On Wed, Feb 12, 2025 at 8:10 AM C Hanish Menon <han...@gm...> wrote:
>
> Hi,
>
> This patch allows one to watch live games which are available/served
> as pgn file online. Once started, it will keep refreshing from the
> specified url, once every minute (this is to ensure that we dont load
> the server unnecessarily).
>
> Currently it imports each updated fetch as a separate imported game,
> need to avoid this later. Also if one enters a invalid url, the logic
> will keep retrying, till one enters a new valid url or a empty url.
>
> --
> Keep ;-)
> HanishKVC

-- 
Keep ;-)
HanishKVC

Hi,

This patch allows one to watch live games which are available/served
as pgn file online. Once started, it will keep refreshing from the
specified url, once every minute (this is to ensure that we dont load
the server unnecessarily).

Currently it imports each updated fetch as a separate imported game,
need to avoid this later. Also if one enters a invalid url, the logic
will keep retrying, till one enters a new valid url or a empty url.

--
Keep ;-)
HanishKVC

Hi Steve,

In a day or two, I will sync up to the latest upstream revision wrt snap.

Also wanted to check if there is an option already to directly fetch a
pgn from a web url, I couldn't find one, but just wanted to check,
before I look at maybe implementing it, if I get time sometime this
week or next. Given that it would allow one to monitor progress with
live games from say lichess, given that fics does not broadcast most
of the championships/tours.

On Sat, Feb 8, 2025 at 3:11 PM Steve A <ste...@gm...> wrote:
>
> Hi Hanish,
> I've added your patches (with a readme) to patches/Hanish.tgz
> and i've linked to https://snapcraft.io/scidvspc-hkvc inside our doco and on the webpage.
> Cheers
>
> On Tue, Feb 4, 2025 at 7:12 PM C Hanish Menon <han...@gm...> wrote:
>>
>> Hi Steve,
>>
>> I have updated snap to use upstream svn revision 3563.
>>
>> I have also updated the patches I maintain outside the upstream to the
>> same. I am attaching those 4 patches at my end with this email. In
>> case you can bundle it along with the scidvspc source in the patches
>> directory or so.
>>
>> The patches are
>>
>> 1. use a contrasting text color (along with a helper proc to calculate
>> contrasting color for any given color) based shadow for board moves
>> visualisation
>>
>> 2. allow user to switch between the PVs in the analysis board wrt
>> board moves visualisation mode
>>
>> 3. allow users to probe deeper by allowing them to control how much of
>> the pv they want to visualise directly on the analysis board view.
>> This tries to ensure that the board doesnt get too cluttered by
>> showing move numbers only for the deepest moves shown and not all of
>> the shown moves, by using a sliding window anchored to the deepest
>> move shown.
>>
>> 4. the AE based Coach. this version also allows the user to set a
>> different lower moves depth wrt opponent blunder check, so that the
>> situation which you had mentioned to me earlier, will be handled in
>> most cases now. The previous patch had the same depth threshold for
>> own as well as opponent move related checks.
>>
>> Note that the existing coach mainly concentrates on ensuring that the
>> player does not make a move which puts their position worse than
>> before, however aecoach also additionally checks for opponent blunders
>> and then the resultant possibility of a much better move by the
>> player. Also the aecoach allows more of its working to be controlled
>> from play-uci dialog
>>
>>
>> --
>> Keep ;-)
>> HanishKVC

-- 
Keep ;-)
HanishKVC

Hi Steve,

I have updated snap to use upstream svn revision 3563.

I have also updated the patches I maintain outside the upstream to the
same. I am attaching those 4 patches at my end with this email. In
case you can bundle it along with the scidvspc source in the patches
directory or so.

The patches are

1. use a contrasting text color (along with a helper proc to calculate
contrasting color for any given color) based shadow for board moves
visualisation

2. allow user to switch between the PVs in the analysis board wrt
board moves visualisation mode

3. allow users to probe deeper by allowing them to control how much of
the pv they want to visualise directly on the analysis board view.
This tries to ensure that the board doesnt get too cluttered by
showing move numbers only for the deepest moves shown and not all of
the shown moves, by using a sliding window anchored to the deepest
move shown.

4. the AE based Coach. this version also allows the user to set a
different lower moves depth wrt opponent blunder check, so that the
situation which you had mentioned to me earlier, will be handled in
most cases now. The previous patch had the same depth threshold for
own as well as opponent move related checks.

Note that the existing coach mainly concentrates on ensuring that the
player does not make a move which puts their position worse than
before, however aecoach also additionally checks for opponent blunders
and then the resultant possibility of a much better move by the
player. Also the aecoach allows more of its working to be controlled
from play-uci dialog

-- 
Keep ;-)
HanishKVC

Hi Steve,

Attached is the patch which adds ticks wrt evalbar linlog.

It also fixes a corner case wrt linlog eval to bar position, if one
where to pass int values.

On Fri, Jan 24, 2025 at 5:58 PM C Hanish Menon <han...@gm...> wrote:
>
> Hi Steve,
>
> WIll have a look at adding ticks
>
> On Fri, Jan 24, 2025 at 2:56 PM Steve A <ste...@gm...> wrote:
> >
> > Hi Hanish.
> > I've just added options for Scorebar Scale, and Ticks.
> > Would you care to code the logarithmic ticks ? (which is now an option, with linear being the default).I'm not really sure about how best to do it. Probably not too hard though..... Perhaps the new Linear "Scale" option could be used as a log scale too??
> >
> > All Options are under Options->Scorebar
> >
> > I'm slowly getting around to making a 4.26 release in a few weeks i guess.
> > cheers, Steve
>
>
>
> --
> Keep ;-)
> HanishKVC

-- 
Keep ;-)
HanishKVC

Hi Steve,

WIll have a look at adding ticks

On Fri, Jan 24, 2025 at 2:56 PM Steve A <ste...@gm...> wrote:
>
> Hi Hanish.
> I've just added options for Scorebar Scale, and Ticks.
> Would you care to code the logarithmic ticks ? (which is now an option, with linear being the default).I'm not really sure about how best to do it. Probably not too hard though..... Perhaps the new Linear "Scale" option could be used as a log scale too??
>
> All Options are under Options->Scorebar
>
> I'm slowly getting around to making a 4.26 release in a few weeks i guess.
> cheers, Steve

-- 
Keep ;-)
HanishKVC

Hi Hanish.
I've just added options for Scorebar Scale, and Ticks.
Would you care to code the logarithmic ticks ? (which is now an option,
with linear being the default).I'm not really sure about how best to do it.
Probably not too hard though..... Perhaps the new Linear "Scale" option
could be used as a log scale too??

All Options are under Options->Scorebar

I'm slowly getting around to making a 4.26 release in a few weeks i guess.
cheers, Steve

Hi Steve,

I havent looked into the UCI handshake flow implementation in scidvspc
currently, but won't it already provide most of the needed plumbing,
for the flow which I have mentioned, which should even avoid the crash
issue which you have mentioned.

Again given the end goal, I suggested the most flexible path. But
otherwise I do agree that if the scidlet covers a depth of 6 to 8 in
200 msecs, which it should in today's PCs, it should give a good
enough eval. Maybe it is even faster, havent used it recently.

On Sun, Jan 12, 2025 at 12:53 PM Steve A <ste...@gm...> wrote:
>
> Haha - Getting an eval on some random board is only possible this way really. Your idea could be done, but involves a whole new big API / class way complicating an already huge project.
>
> Using scidlet is a compromise, but sufficient, and quite a powerful feature too. Main problem is if engine.cpp segfaults, the whole app comes down now :(
>
> I've added some polish today. Getting close to finished.
>
> On Sun, Jan 12, 2025 at 12:52 PM C Hanish Menon <han...@gm...> wrote:
>>
>> Hi Steve,
>>
>> Ideal thing would be for the engine to run in the background and
>> refine the eval with time (as it goes deeper, like what the analysis
>> engine flow does). However if multiple games are being observed, and
>> we try to have multiple instances of the engine running wrt each game
>> being observed, that could turn out to be too much load.
>>
>> So instead having a SINGLE local engine running in the background and
>> inturn sending it
>>
>> a) a new board position (resulting from latest move wrt a game; if
>> multiple games are being followed and their evalbar updated using this
>> mechanism)
>>
>> b) a latest move (if only one game is being followed, here even
>> periodic update of the bar should be easily possible if reqd)
>>
>> and inturn using the eval from the local engine at the end of the
>> configured short time window, could still give a ok enough rough eval
>> especially for human games where deep twists/traps that can change the
>> eval may not be that common.
>>
>> NOTE: Havent looked at uci and xboard protocols for ages now, however
>> my vague memory seems to indicate the possibility of both the above
>> flows in one or the other.
>>
>> Also rather because engines like stockfish etal will normally reach
>> much deeper compared to the internal engine (scidlet?) within a given
>> time window, so making the engine to use, as well as
>> short-time-window-to-use configurable by the end user could be a
>> useful thing, with the default config being the internal engine.
>>
>> On Sat, Jan 11, 2025 at 11:18 AM Steve A <ste...@gm...> wrote:
>> >
>> > I've realised we can use the scid's never-used inbuilt chess engine to add a quick score to fics observed games! :) It's currently given a 200 millisecond run before we update the observed board. (Is this optimal?)
>> >
>> > But I was of the opinion, ages ago we had a problem with "sc_pos analyze" segfaulting occasionally. I may have fixed it sometime... but am uncertain of it's status. (engine.cpp)
>> >
>> > Maybe the problem was only at near mate positions with low piece count.
>> > So, testing is in order i guess... Hmmm.
>> >
>> > Cheers.
>>
>>
>>
>> --
>> Keep ;-)
>> HanishKVC

-- 
Keep ;-)
HanishKVC

Haha - Getting an eval on some random board is *only* possible this way
really. Your idea could be done, but involves a whole new big API / class
way complicating an already huge project.

Using scidlet is a compromise, but sufficient, and quite a powerful feature
too. Main problem is if engine.cpp segfaults, the whole app comes down now
:(

I've added some polish today. Getting close to finished.

On Sun, Jan 12, 2025 at 12:52 PM C Hanish Menon <han...@gm...> wrote:

> Hi Steve,
>
> Ideal thing would be for the engine to run in the background and
> refine the eval with time (as it goes deeper, like what the analysis
> engine flow does). However if multiple games are being observed, and
> we try to have multiple instances of the engine running wrt each game
> being observed, that could turn out to be too much load.
>
> So instead having a SINGLE local engine running in the background and
> inturn sending it
>
> a) a new board position (resulting from latest move wrt a game; if
> multiple games are being followed and their evalbar updated using this
> mechanism)
>
> b) a latest move (if only one game is being followed, here even
> periodic update of the bar should be easily possible if reqd)
>
> and inturn using the eval from the local engine at the end of the
> configured short time window, could still give a ok enough rough eval
> especially for human games where deep twists/traps that can change the
> eval may not be that common.
>
> NOTE: Havent looked at uci and xboard protocols for ages now, however
> my vague memory seems to indicate the possibility of both the above
> flows in one or the other.
>
> Also rather because engines like stockfish etal will normally reach
> much deeper compared to the internal engine (scidlet?) within a given
> time window, so making the engine to use, as well as
> short-time-window-to-use configurable by the end user could be a
> useful thing, with the default config being the internal engine.
>
> On Sat, Jan 11, 2025 at 11:18 AM Steve A <ste...@gm...> wrote:
> >
> > I've realised we can use the scid's never-used inbuilt chess engine to
> add a quick score to fics observed games! :) It's currently given a 200
> millisecond run before we update the observed board. (Is this optimal?)
> >
> > But I was of the opinion, ages ago we had a problem with "sc_pos
> analyze" segfaulting occasionally. I may have fixed it sometime... but am
> uncertain of it's status. (engine.cpp)
> >
> > Maybe the problem was only at near mate positions with low piece count.
> > So, testing is in order i guess... Hmmm.
> >
> > Cheers.
>
>
>
> --
> Keep ;-)
> HanishKVC
>

Hi Steve,

Ideal thing would be for the engine to run in the background and
refine the eval with time (as it goes deeper, like what the analysis
engine flow does). However if multiple games are being observed, and
we try to have multiple instances of the engine running wrt each game
being observed, that could turn out to be too much load.

So instead having a SINGLE local engine running in the background and
inturn sending it

a) a new board position (resulting from latest move wrt a game; if
multiple games are being followed and their evalbar updated using this
mechanism)

b) a latest move (if only one game is being followed, here even
periodic update of the bar should be easily possible if reqd)

and inturn using the eval from the local engine at the end of the
configured short time window, could still give a ok enough rough eval
especially for human games where deep twists/traps that can change the
eval may not be that common.

NOTE: Havent looked at uci and xboard protocols for ages now, however
my vague memory seems to indicate the possibility of both the above
flows in one or the other.

Also rather because engines like stockfish etal will normally reach
much deeper compared to the internal engine (scidlet?) within a given
time window, so making the engine to use, as well as
short-time-window-to-use configurable by the end user could be a
useful thing, with the default config being the internal engine.

On Sat, Jan 11, 2025 at 11:18 AM Steve A <ste...@gm...> wrote:
>
> I've realised we can use the scid's never-used inbuilt chess engine to add a quick score to fics observed games! :) It's currently given a 200 millisecond run before we update the observed board. (Is this optimal?)
>
> But I was of the opinion, ages ago we had a problem with "sc_pos analyze" segfaulting occasionally. I may have fixed it sometime... but am uncertain of it's status. (engine.cpp)
>
> Maybe the problem was only at near mate positions with low piece count.
> So, testing is in order i guess... Hmmm.
>
> Cheers.

-- 
Keep ;-)
HanishKVC

https://talkchess.com/viewtopic.php?t=84715

On Sat, Jan 11, 2025 at 3:48 PM Steve A <ste...@gm...> wrote:

> I've realised we can use the scid's never-used inbuilt chess engine to add
> a quick score to fics observed games! :) It's currently given a 200
> millisecond run before we update the observed board. (Is this optimal?)
>
> But I was of the opinion, ages ago we had a problem with "sc_pos analyze"
> segfaulting occasionally. I may have fixed it sometime... but am uncertain
> of it's status. (engine.cpp)
>
> Maybe the problem was only at near mate positions with low piece count.
> So, testing is in order i guess... Hmmm.
>
> Cheers.
>

I've realised we can use the scid's never-used inbuilt chess engine to add
a quick score to fics observed games! :) It's currently given a 200
millisecond run before we update the observed board. (Is this optimal?)

But I was of the opinion, ages ago we had a problem with "sc_pos analyze"
segfaulting occasionally. I may have fixed it sometime... but am uncertain
of it's status. (engine.cpp)

Maybe the problem was only at near mate positions with low piece count.
So, testing is in order i guess... Hmmm.

Cheers.

Hi Steve,

Maybe we are looking at things from different perspectives, that is
the reason why something which seems critical/needed-polish from one
angle appears as an unrelated new feature from another angle.

An experienced chess player will not miss out the obvious that often,
so checking for major blunders is good enough and that is what the
existing coach logic will provide.

However for a new chess player who will miss out the obvious most of
the time, and or who will want a low powered opponent, while still
wanting a proper (more powerful) coach to verify wrt obvious issues
the existing coach won't do and the AECoach logic will provide the
needed safety net with out anything other than enabling the aecoach
feature in the dialog. With the additional flexibility of giving the
option to see why the engine may be alerting by looking at the ae
board move visualisation and or using MultiPVTL color bar as an alert
to be careful with a move and so on.

NOTE: The specific situation which you had sent separately, is
slightly different (ie not only about not moving into a worse
position, but also not missing better opportunities). As noted in that
response, if one takes time wrt their moves, then the aecoach logic
patch will implicitly handle the case of checking wrt best possible
move also, otherwise it only checks for not going into worse position.
And if needed to always validate wrt best move, then aecoach needs to
validate position 100% of the time, instead of the current 50% of the
time.

On Fri, Jan 10, 2025 at 1:43 PM Steve A <ste...@gm...> wrote:
>
> Yeah, sorry for not accepting your code. I always try to add polish to the app, but this would be a step back imho.
> Polish first, features second :)
>
> Thanks for reminding me that people use this feature. I've committed some code to storetime settings as a tag, and  (optionally) movetimes as comments.
> Probably there are lots of ways to break the movetimes.... but in a straight forward game, they should mostly work.
>
> Cheers.
>
> On Fri, Jan 10, 2025 at 3:16 AM C Hanish Menon <han...@gm...> wrote:
>>
>> Hi Steve,
>>
>> Attaching updated patch which Also brings in existing
>> coach-is-watchings opponent-eval based equivalent functionality also
>> into the AECoach as an optional feature. So that if one is mainly only
>> interested in being alerted wrt serious blunders and otherwise doesnt
>> want to set aside time for AECoach to take time to evaluate each
>> player move, it can still be achieved.
>>
>> This version also auto starts the user selected analysis engine, if
>> needed (ie if the selected ae is not already started). The AECoach is
>> started in normal mode and not silent mode, bcas the idea is also that
>> user can utilise the features of analysis engine and its board to
>> cross check as to why a move may be weak and what the alternatives
>> are, if they want to, without me having to bring in the features like
>> MultiPV TrafficLight Color bar or BoardMovesVisualisation into Alert
>> dialog.
>>
>> I have also included the patch to remove the existing
>> coach-is-watching, if needed.
>>
>>
>>
>> On Thu, Jan 9, 2025 at 5:22 AM Steve A <ste...@gm...> wrote:
>> >
>> > Ok, I applied some of this patch.
>> >
>> > Re your sergame changes.... hmmmm.  Sorry, but I doubt i'm going to be making any new feature changes to UCI game.
>> > I'm too busy, changes aren't too meaningful, I don't use the coach and it's too complicated as-is.
>> > If you resubmit with your coach totally replacing the old coach feature, and the engine autostarting without a hassle, maybe i'll look at it.
>> >
>> > Cheers.
>> >
>> > On Wed, Jan 8, 2025 at 7:32 PM C Hanish Menon <han...@gm...> wrote:
>> >>
>> >> Hi,
>> >>
>> >> This patch makes the boardVisualiseMoves sequence visualisation more
>> >> flexible and bit more legible with these changes
>> >>
>> >> 1. have added variables which get saved into options.dat wrt the
>> >> boardVisualiseMoves' white and black sides' line colors. These are
>> >> inturn set by default to white and grey40. This gives flexibility for
>> >> users to use the board moves sequence visualisation mode irrespective
>> >> of the specific board and its square colors. While still by default
>> >> using white and grey.
>> >>
>> >> 2. the calculation used for deciding the font size has been adjusted a
>> >> bit to make it independent of any fixed constant adjusting (which wont
>> >> work across different board sizes, as intended), and also makes the
>> >> font size a tiny bit smaller so that it doesnt cover the piece too
>> >> much.
>> >>
>> >> 3. have added a simple contrast color helper (replacing the more rigid
>> >> gradient color helper wrt boardVisualiseMoves) to help wrt the shadow
>> >> text and in turn use the same. In gradient color logic the rgb
>> >> channels are moved to a predefined/hardcoded side by a predefined
>> >> extent irrespective of the color. However the simple contrast color
>> >> helper divides the individual r/g/b channel data space into two halves
>> >> and inturn moves the corresponding channel value to the other extreme
>> >> compared to whichever half the current color's corresponding channel
>> >> value falls into.
>> >>
>> >> NOTE: I had sent a similar patch sometime back, this is a more refined
>> >> version of the same.
>> >>
>> >> --
>> >> Keep ;-)
>> >> HanishKVC
>>
>>
>>
>> --
>> Keep ;-)
>> HanishKVC

-- 
Keep ;-)
HanishKVC

Yeah, sorry for not accepting your code. I always try to add polish to the
app, but this would be a step back imho.
Polish first, features second :)

Thanks for reminding me that people use this feature. I've committed some
code to storetime settings as a tag, and  (optionally) movetimes as
comments.
Probably there are lots of ways to break the movetimes.... but in a
straight forward game, they should mostly work.

Cheers.

On Fri, Jan 10, 2025 at 3:16 AM C Hanish Menon <han...@gm...> wrote:

> Hi Steve,
>
> Attaching updated patch which Also brings in existing
> coach-is-watchings opponent-eval based equivalent functionality also
> into the AECoach as an optional feature. So that if one is mainly only
> interested in being alerted wrt serious blunders and otherwise doesnt
> want to set aside time for AECoach to take time to evaluate each
> player move, it can still be achieved.
>
> This version also auto starts the user selected analysis engine, if
> needed (ie if the selected ae is not already started). The AECoach is
> started in normal mode and not silent mode, bcas the idea is also that
> user can utilise the features of analysis engine and its board to
> cross check as to why a move may be weak and what the alternatives
> are, if they want to, without me having to bring in the features like
> MultiPV TrafficLight Color bar or BoardMovesVisualisation into Alert
> dialog.
>
> I have also included the patch to remove the existing
> coach-is-watching, if needed.
>
>
>
> On Thu, Jan 9, 2025 at 5:22 AM Steve A <ste...@gm...> wrote:
> >
> > Ok, I applied some of this patch.
> >
> > Re your sergame changes.... hmmmm.  Sorry, but I doubt i'm going to be
> making any new feature changes to UCI game.
> > I'm too busy, changes aren't too meaningful, I don't use the coach and
> it's too complicated as-is.
> > If you resubmit with your coach totally replacing the old coach feature,
> and the engine autostarting without a hassle, maybe i'll look at it.
> >
> > Cheers.
> >
> > On Wed, Jan 8, 2025 at 7:32 PM C Hanish Menon <han...@gm...>
> wrote:
> >>
> >> Hi,
> >>
> >> This patch makes the boardVisualiseMoves sequence visualisation more
> >> flexible and bit more legible with these changes
> >>
> >> 1. have added variables which get saved into options.dat wrt the
> >> boardVisualiseMoves' white and black sides' line colors. These are
> >> inturn set by default to white and grey40. This gives flexibility for
> >> users to use the board moves sequence visualisation mode irrespective
> >> of the specific board and its square colors. While still by default
> >> using white and grey.
> >>
> >> 2. the calculation used for deciding the font size has been adjusted a
> >> bit to make it independent of any fixed constant adjusting (which wont
> >> work across different board sizes, as intended), and also makes the
> >> font size a tiny bit smaller so that it doesnt cover the piece too
> >> much.
> >>
> >> 3. have added a simple contrast color helper (replacing the more rigid
> >> gradient color helper wrt boardVisualiseMoves) to help wrt the shadow
> >> text and in turn use the same. In gradient color logic the rgb
> >> channels are moved to a predefined/hardcoded side by a predefined
> >> extent irrespective of the color. However the simple contrast color
> >> helper divides the individual r/g/b channel data space into two halves
> >> and inturn moves the corresponding channel value to the other extreme
> >> compared to whichever half the current color's corresponding channel
> >> value falls into.
> >>
> >> NOTE: I had sent a similar patch sometime back, this is a more refined
> >> version of the same.
> >>
> >> --
> >> Keep ;-)
> >> HanishKVC
>
>
>
> --
> Keep ;-)
> HanishKVC
>

Hi Steve,

Attaching updated patch which Also brings in existing
coach-is-watchings opponent-eval based equivalent functionality also
into the AECoach as an optional feature. So that if one is mainly only
interested in being alerted wrt serious blunders and otherwise doesnt
want to set aside time for AECoach to take time to evaluate each
player move, it can still be achieved.

This version also auto starts the user selected analysis engine, if
needed (ie if the selected ae is not already started). The AECoach is
started in normal mode and not silent mode, bcas the idea is also that
user can utilise the features of analysis engine and its board to
cross check as to why a move may be weak and what the alternatives
are, if they want to, without me having to bring in the features like
MultiPV TrafficLight Color bar or BoardMovesVisualisation into Alert
dialog.

I have also included the patch to remove the existing
coach-is-watching, if needed.

On Thu, Jan 9, 2025 at 5:22 AM Steve A <ste...@gm...> wrote:
>
> Ok, I applied some of this patch.
>
> Re your sergame changes.... hmmmm.  Sorry, but I doubt i'm going to be making any new feature changes to UCI game.
> I'm too busy, changes aren't too meaningful, I don't use the coach and it's too complicated as-is.
> If you resubmit with your coach totally replacing the old coach feature, and the engine autostarting without a hassle, maybe i'll look at it.
>
> Cheers.
>
> On Wed, Jan 8, 2025 at 7:32 PM C Hanish Menon <han...@gm...> wrote:
>>
>> Hi,
>>
>> This patch makes the boardVisualiseMoves sequence visualisation more
>> flexible and bit more legible with these changes
>>
>> 1. have added variables which get saved into options.dat wrt the
>> boardVisualiseMoves' white and black sides' line colors. These are
>> inturn set by default to white and grey40. This gives flexibility for
>> users to use the board moves sequence visualisation mode irrespective
>> of the specific board and its square colors. While still by default
>> using white and grey.
>>
>> 2. the calculation used for deciding the font size has been adjusted a
>> bit to make it independent of any fixed constant adjusting (which wont
>> work across different board sizes, as intended), and also makes the
>> font size a tiny bit smaller so that it doesnt cover the piece too
>> much.
>>
>> 3. have added a simple contrast color helper (replacing the more rigid
>> gradient color helper wrt boardVisualiseMoves) to help wrt the shadow
>> text and in turn use the same. In gradient color logic the rgb
>> channels are moved to a predefined/hardcoded side by a predefined
>> extent irrespective of the color. However the simple contrast color
>> helper divides the individual r/g/b channel data space into two halves
>> and inturn moves the corresponding channel value to the other extreme
>> compared to whichever half the current color's corresponding channel
>> value falls into.
>>
>> NOTE: I had sent a similar patch sometime back, this is a more refined
>> version of the same.
>>
>> --
>> Keep ;-)
>> HanishKVC

-- 
Keep ;-)
HanishKVC

Hi,

** Existing Coach logic

The current coach-is-watching feature wrt UCI engines, uses the
opponent engine instance itself as the coach. This is ok if the uci
engine is being driven without any tight depth or time limit in the
play->uci-engine, but otherwise it will tend to give wrong coaching
feedback, bcas its view of the position is limited by the depth/time
limit used to weaken the opponent, if any, inturn weakening the
coaching feedback also.

Also it uses the informant's poor move value itself as the threshold,
thus overloading its use. While many times one may want to set a more
tighter threshold wrt coaching feedback.

** AECoach logic

This avoids the above issues and provides more flexibility

Here in the play->uci dialog a new row is added to allow the user to
select a uci engine of their choice as the coach, as well as configure
it wrt coach-alert-threshold, depth to search and time limit.

Inturn if the player starts the corresponding analysis engine, the
AECoach logic will monitor the game progress and inturn whenever the
player makes a move which worsens the evaluation compared to their
previous move, beyond the specified threshold it will alert the player
to review their move.

Additionally if the player takes time while making their move, such
that AE has reached the specified depth, then the best move identified
at that time and the eval wrt same is used so that if the player makes
the best move it is executed immediately without waiting for the ae to
evaluate the new position. However If the player makes a different
move, then not only is it validated wrt the player's prev move score,
but also against the score for the bestmove identified by engine.

So this logic in general tries to ensure that the player doesnt make a
worse move, while parallely trying to push them towards the best move,
provided the player took sufficient time when deciding their move.

NOTE: My patch doesnt start the user selected AECoach automatically,
the user is required to start the AE.

-- 
Keep ;-)
HanishKVC

Hi,

This patch makes the boardVisualiseMoves sequence visualisation more
flexible and bit more legible with these changes

1. have added variables which get saved into options.dat wrt the
boardVisualiseMoves' white and black sides' line colors. These are
inturn set by default to white and grey40. This gives flexibility for
users to use the board moves sequence visualisation mode irrespective
of the specific board and its square colors. While still by default
using white and grey.

2. the calculation used for deciding the font size has been adjusted a
bit to make it independent of any fixed constant adjusting (which wont
work across different board sizes, as intended), and also makes the
font size a tiny bit smaller so that it doesnt cover the piece too
much.

3. have added a simple contrast color helper (replacing the more rigid
gradient color helper wrt boardVisualiseMoves) to help wrt the shadow
text and in turn use the same. In gradient color logic the rgb
channels are moved to a predefined/hardcoded side by a predefined
extent irrespective of the color. However the simple contrast color
helper divides the individual r/g/b channel data space into two halves
and inturn moves the corresponding channel value to the other extreme
compared to whichever half the current color's corresponding channel
value falls into.

NOTE: I had sent a similar patch sometime back, this is a more refined
version of the same.

--
Keep ;-)
HanishKVC

Hi Steve,

As suggested, I have recreated the patch, on top of the latest svn.

I have also added a options.dat entry ::board::enableMPVTls, which is
off by default. This decides at the global level whether
MultiPVTrafficlights bar feature is enabled and shown or not.

Inturn if the user enables this in options.dat, for the analysis
board, it will show the bar. However the main board is not touched.

A toggle helper is also added, however it is not called currently.

-- 
Keep ;-)
HanishKVC

Hi,

There seems to be an issue with ::board::new's Materials canvas flow.

Materials canvas is created only if show material is enabled. So if
one does not have materials already enabled, and inturn tries to
toggle it on, bcas the canvas is not created, so toggle proc will
raise an error dialog, when trying to adjust the grid settings wrt
materials canvas.

However if one has Materials already toggled on (in options.dat
gameInfo(showMaterial)) before the program is started, then everything
will be fine.

This patch fixes this issue, by having the board::new always create
the materials canvas. Which is what is needed. Inturn toggle will
adjust the grid settings as needed and ensuring that materials is
either shown or hidden.

-- 
Keep ;-)
HanishKVC

Hi Steve,

Sorry, in the last patch, I had forgotten to update the comment in the
source code to match the new curve, I have fixed it in this patch,
please use this patch.

On Tue, Dec 31, 2024 at 11:28 PM C Hanish Menon <han...@gm...> wrote:
>
> Hi Steve,
>
> The lin+log evalbar I coded specifically so that one can clearly
> distinguish between the different loss/gain levels like
> pawn/piece/queen/beyond or equivalent wrt the evals on the graph
> clearly.
>
> Prev Curve
> ============
>
> So it maps such that the 1st square is linear, remaining are a single
> logarithmic uniform scale, which automatically maps to 3, 10 and
> beyond implicitly to 2nd and 3rd square and so on.
>
> * beyond 1st square away from the mid point, corresponds to gain or
> loss of a pawn ie eval of > 1
> * beyond 2nd square away from the mid point, corresponds to gain or
> loss of a minor piece or equivalent ie eval of > ~3.16
> * beyond 3rd square away from the mid point, corresponds to gain or
> loss of a queen + or equivalent ie eval of > ~9 (rather 10)
> * In this a eval of around 5 will map to ~ 2.5 squares away from the center
>
> New Curve
> =============
>
> But I do hear you, people may want the bar to be placed a bit higher
> for 5, to convey the seriousness of the situation?!. I have tweaked
> the curve such that till 2 it is linear and then beyond it a tweaked
> log such that eval of 5 maps to end of 3rd square and in this 3.16
> will be roughly around 2.5 squares beyond mid point, so still
> distinguishable in a way. ie
>
> * 0.0 to 1.0 => 1st Sq
> * 1.0 to 2.0 => 2nd sq
> * 2.0 to 5.0 => 3rd sq
> * 5.0 to 12.x => 4th sq
>
> I am attaching the curves image (blue was the original curve in what
> is already upstreamed, orange curve is the new one corresponding to
> the patch attached here) as well as patch wrt the new curve.
>
> On Mon, Dec 30, 2024 at 4:06 PM Steve A <ste...@gm...> wrote:
> >
> > Hmm - i would have thought a score of +5 is totally winning and score bar should show 90% or more.
> > What's the logic behind your evalbar_linlog .. It's just silly isn't it ?
> > cheers.
> >
> >
> > On Mon, Dec 30, 2024 at 7:14 PM Steve A <ste...@gm...> wrote:
> >>
> >> > STM even thou redundant wrt analysis board in normal
> >> mode, BUT when using locking wrt analysis board and inturn trail mode
> >> wrt main board, stm wrt analysis board will be useful.
> >>
> >> Hmmmm...
> >>
> >> I've updated svn again to show scores (if present as a comment) even if no engine running, and tweaked the menu,
> >> I think it's looking pretty solid afaics.
> >> cheers
> >>
> >> On Mon, Dec 30, 2024 at 7:46 AM C Hanish Menon <han...@gm...> wrote:
> >>>
> >>> Hi Steve,
> >>>
> >>> Just to confirm, STM even thou redundant wrt analysis board in normal
> >>> mode, BUT when using locking wrt analysis board and inturn trail mode
> >>> wrt main board, stm wrt analysis board will be useful.
> >>>
> >>> I will send you the patch wrt traffic lights based on the latest svn
> >>> revision tomorrow.
> >>>
> >>> On Sun, Dec 29, 2024 at 12:36 PM Steve A <ste...@gm...> wrote:
> >>> >
> >>> > I've made a commit and got the main board eval bar working. Right click on the main board tab and select "Toggle Eval".
> >>> > Maybe there's some bugs still there. I have things to do still too.
> >>> >
> >>> > > Regarding the board in different places like main or analysis or fics
> >>> > or so and in turn wrt analysis board, bcas it is currently always
> >>> > linked to the main board, having the stm on analysis board normally is
> >>> > redundant.
> >>> >
> >>> > Ok.
> >>> >
> >>> > > Regarding the Traffic Lights, if you dont mind I would request you to
> >>> > apply in the upstream with maybe either a options.dat entry or
> >>> > additionally menu entry or so
> >>> >
> >>> > Ok, i'll inline your traffic lights and ifdef {0} the code or something.
> >>> > Could you please send me a new patch.
> >>> >
> >>> > Cheers.
> >>>
> >>>
> >>>
> >>> --
> >>> Keep ;-)
> >>> HanishKVC
>
>
>
> --
> Keep ;-)
> HanishKVC

-- 
Keep ;-)
HanishKVC

Hi Steve,

The lin+log evalbar I coded specifically so that one can clearly
distinguish between the different loss/gain levels like
pawn/piece/queen/beyond or equivalent wrt the evals on the graph
clearly.

Prev Curve
============

So it maps such that the 1st square is linear, remaining are a single
logarithmic uniform scale, which automatically maps to 3, 10 and
beyond implicitly to 2nd and 3rd square and so on.

* beyond 1st square away from the mid point, corresponds to gain or
loss of a pawn ie eval of > 1
* beyond 2nd square away from the mid point, corresponds to gain or
loss of a minor piece or equivalent ie eval of > ~3.16
* beyond 3rd square away from the mid point, corresponds to gain or
loss of a queen + or equivalent ie eval of > ~9 (rather 10)
* In this a eval of around 5 will map to ~ 2.5 squares away from the center

New Curve
=============

But I do hear you, people may want the bar to be placed a bit higher
for 5, to convey the seriousness of the situation?!. I have tweaked
the curve such that till 2 it is linear and then beyond it a tweaked
log such that eval of 5 maps to end of 3rd square and in this 3.16
will be roughly around 2.5 squares beyond mid point, so still
distinguishable in a way. ie

* 0.0 to 1.0 => 1st Sq
* 1.0 to 2.0 => 2nd sq
* 2.0 to 5.0 => 3rd sq
* 5.0 to 12.x => 4th sq

I am attaching the curves image (blue was the original curve in what
is already upstreamed, orange curve is the new one corresponding to
the patch attached here) as well as patch wrt the new curve.

On Mon, Dec 30, 2024 at 4:06 PM Steve A <ste...@gm...> wrote:
>
> Hmm - i would have thought a score of +5 is totally winning and score bar should show 90% or more.
> What's the logic behind your evalbar_linlog .. It's just silly isn't it ?
> cheers.
>
>
> On Mon, Dec 30, 2024 at 7:14 PM Steve A <ste...@gm...> wrote:
>>
>> > STM even thou redundant wrt analysis board in normal
>> mode, BUT when using locking wrt analysis board and inturn trail mode
>> wrt main board, stm wrt analysis board will be useful.
>>
>> Hmmmm...
>>
>> I've updated svn again to show scores (if present as a comment) even if no engine running, and tweaked the menu,
>> I think it's looking pretty solid afaics.
>> cheers
>>
>> On Mon, Dec 30, 2024 at 7:46 AM C Hanish Menon <han...@gm...> wrote:
>>>
>>> Hi Steve,
>>>
>>> Just to confirm, STM even thou redundant wrt analysis board in normal
>>> mode, BUT when using locking wrt analysis board and inturn trail mode
>>> wrt main board, stm wrt analysis board will be useful.
>>>
>>> I will send you the patch wrt traffic lights based on the latest svn
>>> revision tomorrow.
>>>
>>> On Sun, Dec 29, 2024 at 12:36 PM Steve A <ste...@gm...> wrote:
>>> >
>>> > I've made a commit and got the main board eval bar working. Right click on the main board tab and select "Toggle Eval".
>>> > Maybe there's some bugs still there. I have things to do still too.
>>> >
>>> > > Regarding the board in different places like main or analysis or fics
>>> > or so and in turn wrt analysis board, bcas it is currently always
>>> > linked to the main board, having the stm on analysis board normally is
>>> > redundant.
>>> >
>>> > Ok.
>>> >
>>> > > Regarding the Traffic Lights, if you dont mind I would request you to
>>> > apply in the upstream with maybe either a options.dat entry or
>>> > additionally menu entry or so
>>> >
>>> > Ok, i'll inline your traffic lights and ifdef {0} the code or something.
>>> > Could you please send me a new patch.
>>> >
>>> > Cheers.
>>>
>>>
>>>
>>> --
>>> Keep ;-)
>>> HanishKVC

-- 
Keep ;-)
HanishKVC

Hi Steve,

Just to confirm, STM even thou redundant wrt analysis board in normal
mode, BUT when using locking wrt analysis board and inturn trail mode
wrt main board, stm wrt analysis board will be useful.

I will send you the patch wrt traffic lights based on the latest svn
revision tomorrow.

On Sun, Dec 29, 2024 at 12:36 PM Steve A <ste...@gm...> wrote:
>
> I've made a commit and got the main board eval bar working. Right click on the main board tab and select "Toggle Eval".
> Maybe there's some bugs still there. I have things to do still too.
>
> > Regarding the board in different places like main or analysis or fics
> or so and in turn wrt analysis board, bcas it is currently always
> linked to the main board, having the stm on analysis board normally is
> redundant.
>
> Ok.
>
> > Regarding the Traffic Lights, if you dont mind I would request you to
> apply in the upstream with maybe either a options.dat entry or
> additionally menu entry or so
>
> Ok, i'll inline your traffic lights and ifdef {0} the code or something.
> Could you please send me a new patch.
>
> Cheers.

-- 
Keep ;-)
HanishKVC

I've made a commit and got the main board eval bar working. Right click on
the main board tab and select "Toggle Eval".
Maybe there's some bugs still there. I have things to do still too.

> Regarding the board in different places like main or analysis or fics
or so and in turn wrt analysis board, bcas it is currently always
linked to the main board, having the stm on analysis board normally is
redundant.

Ok.

> Regarding the Traffic Lights, if you dont mind I would request you to
apply in the upstream with maybe either a options.dat entry or
additionally menu entry or so

Ok, i'll inline your traffic lights and ifdef {0} the code or something.
Could you please send me a new patch.

Cheers.

2024	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (18)
2025	Jan (15)	Feb (6)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

scidvspc-devel Mailing List for Scid vs. PC

Chess Database and Toolkit program

scidvspc-devel — Dev mailing list