Bug 381963 - Kigo: wrong lower bound for handicap value
Summary: Kigo: wrong lower bound for handicap value
Status: RESOLVED FIXED
Alias: None
Product: kigo
Classification: Applications
Component: general (show other bugs)
Version: 0.5.6
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Sascha Peilicke
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-07-03 17:58 UTC by Martino Pilia
Modified: 2017-07-24 15:02 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Proposed patch (678 bytes, patch)
2017-07-03 17:58 UTC, Martino Pilia
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martino Pilia 2017-07-03 17:58:19 UTC
Created attachment 106433 [details]
Proposed patch

When setting up a game with no handicap and then quitting the application, the handicap value does not go stored in the preferences as it should, since a value lower than 2 for handicap does not pass validation (while a value of 1 should be valid, since it represents no handicap). Proposed patch on attachment.

Steps to reproduce:

1) Start Kigo, set up a game with no handicap.
2) Quit Kigo. If Kigo was started from the command line, note the debug message `kigo(xxxxx) Preferences::setFixedHandicapValue: setFixedHandicapValue: value  1  is less than the minimum value of 2`
3) Start Kigo again.

Actual Results: when starting Kigo again at step 3, the handicap value in the game setup is 2 stones.

Expected Results: the value in the game setup should be no handicap.

Observed both in the Arch Linux package (kdegames-kigo 17.04.2-1) and compiling Kigo from sources (commit 8b65479c0efc2c4f603f4c14089a0a340f97581f).
Comment 1 Albert Astals Cid 2017-07-03 21:21:26 UTC
I'm not a go player so i've no idea if this makes sense or not, but related to this, why is there no "1 stone handicap" and it goes from 2 stones to no stones?

Should it also have 1 stone handicap?
Comment 2 Martino Pilia 2017-07-03 22:27:45 UTC
(In reply to Albert Astals Cid from comment #1)
> I'm not a go player so i've no idea if this makes sense or not, but related
> to this, why is there no "1 stone handicap" and it goes from 2 stones to no
> stones?
> 
> Should it also have 1 stone handicap?

Having one stone handicap should be to normally play as Black (with no komi). It's a bit confusing compared to other games, since Black's first move is just to place its handicap stones, so a `n' stone handicap actually means just `n-1' extra stones for Black compared to a non-handicap game.
Also, only with 2 or more handicap stones traditional fixed positions for handicap placement are used (at least, under Japanese rules), so it makes sense to have them preset, while a 1 handicap stone (i.e. a normal Black's first move) can be freely placed.
Comment 3 Albert Astals Cid 2017-07-24 15:02:37 UTC
Git commit 72987faf047e5369112f0ecd96184b5f150b7836 by Albert Astals Cid.
Committed on 24/07/2017 at 15:02.
Pushed by aacid into branch 'Applications/17.08'.

Fix wrong lower bound for handicap value

M  +1    -1    src/kigo.kcfg

https://commits.kde.org/kigo/72987faf047e5369112f0ecd96184b5f150b7836