Bug 12394 - Miniature should set autoflag 1 automatically
: Miniature should set autoflag 1 automatically
Status: VERIFIED FIXED
Product: Miniature
General
: master
: All All
: High major (vote)
: 0.5
Assigned To: unassigned
: general
:
:
:
: 12435
  Show dependency tree
 
Reported: 2011-09-11 08:20 UTC by Quim Gil
Modified: 2011-10-18 08:47 UTC (History)
1 user (show)

See Also:


Attachments
Screenshot (68.82 KB, image/png)
2011-10-11 00:41 UTC, Quim Gil
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Quim Gil (reporter) 2011-09-11 08:20:03 UTC
SOFTWARE VERSION: 
master

EXACT STEPS LEADING TO PROBLEM: 
1. Join as guest (since your registered user might have the autoflag enabled
already)
2. Join from your PC, also as guest. Launch a new "seek 1 0 m"
3. Accept the game and do the first 1-2 moves on each side.
4. Wait until the PC player goes below 0 time.

EXPECTED OUTCOME: 
Miniature player wins.

ACTUAL OUTCOME: 
The counter continues -1, -2... also in the FICS server. Miniature can't issue
a flag so who knows how long that might go. Eventually the Miniature player can
run out of time as well. If the PC player calls flag manually or automatically
the game will be resolved as 

"{Game 169 (GuestBZJB vs. GuestYYMR) Game drawn because both players ran out of
time} 1/2-1/2"

REPRODUCIBILITY: 
always

0.4? The implementation seem simple, just tell the FICS server "set autoflag 1"
after logging in.
Comment 1 Quim Gil (reporter) 2011-09-18 08:11:16 UTC
Proposing for 0.5 - needs to be confirmed.
Comment 2 Quim Gil (reporter) 2011-09-21 00:37:22 UTC
I'm finding myself in this situations quite often. There is no way of finishing
the game unless the opponent decides to move or go away. Increasing severity.
Comment 3 Quim Gil (reporter) 2011-10-11 00:41:56 UTC
Created an attachment (id=3430) [details]
Screenshot

I sweat a lot to recover a piece and even snatch another one, then opponent
runs out of time... The only option for Miniature player is to close app or
resign.
Comment 4 Michael Hasselmann 2011-10-17 04:23:44 UTC
Nice position!
Comment 5 Michael Hasselmann 2011-10-17 04:25:57 UTC
Fixed with commit c18efee12930ac463b85f47a8d0e986b482a6abd.
Comment 6 Quim Gil (reporter) 2011-10-18 08:47:40 UTC
Yep, it works. Great!

(In reply to comment #4)
> Nice position!

Thanks!  ;)