Variants patches

[GoogleCodeExporter]

In preparation for the new seek dialog I've been working on, and because
issue 393 requires a data structure in it, I have a patch I'd like reviewed
before I check it in.

The patch mainly does 4 things which are somewhat interdependent:

1) adds all of the FICS variants we currently support (pawnspushed,
pawnspassed, random, and asymmetric random) to the pychess New Game dialog.
(pychess/Variants/*)
2) has some miscellaneous variant changes in the pychess/ic/managers/*
3) removes castling from the "Shuffle" variant to align it with the general
consensus that "Shuffle Chess" aka wild/2, doesn't allow castling. This was
also discussed in revision 1082 . My basis for this reasoning is a) the
FICS Shuffle variant aka wild/2 doesn't allow castling (
http://www.freechess.org/Help/HelpFiles/wild.html ), b) ChessMaster's
Shuffle aka "Pieces Shuffle" doesn't allow castling (
http://www.oyunbunlar.com/Readme/Simulasion/CHESSMASTER_11_ReadMe.txt ), c)
ICC's Shuffle which is wild/2 doesn't allow castling (
http://www.chessclub.com/helpcenter/tips/wild.html ), d) xboard's Shuffle
aka nocastle doesn't allow castling (
http://tim-mann.org/xboard/engine-intf.html#8 ). So this seems to be the
general consensus except for the random guy on wikipedia who changed the
wikipedia Shuffle Chess rules entry to "castling only possible when king
and rook are on their traditional starting squares":
http://en.wikipedia.org/w/index.php?title=Chess960&diff=prev&oldid=89873705
. (pychess/Variants/shuffle.py)
4) fixes an issue in spy and hint engine initialization when a variant has
cecp_name="unknown" and disables the Hint and Spy engine Menu entries when
the tab is switched to a game where the user configured Hint and/or Spy
engines don't support the variant being played. (GameModel.py, ionest.py,
gamenanny.py, Main.py)

Original issue reported on code.google.com by mattgatto on 28 Mar 2009 at 11:00

Attachments:

• pychess-variants.patch

[GoogleCodeExporter]

Original comment by mattgatto on 28 Mar 2009 at 11:01

[GoogleCodeExporter]

Seems Ok for me, commit it please.

Original comment by gbtami on 29 Mar 2009 at 10:21

[GoogleCodeExporter]

Very good cleanups and changes.
As long as FICS is the only online service we support, it makes most sense to be
consistent.

Could:

gamenanny.setMenuItemsSensitive(gamemodel)

from Main.py be moved to the listener function directly in gamenanny?

Original comment by lobais on 29 Mar 2009 at 5:55

[GoogleCodeExporter]

you could do it this way too:
Index: lib/pychess/Main.py
===================================================================
--- lib/pychess/Main.py (revision 1441)
+++ lib/pychess/Main.py (working copy)
@@ -41,10 +41,6 @@
         # Bring playing window to the front
         gamewidget.getWidgets()["window1"].present()

-        # Make sure game dependent menu entries are sensitive
-        for widget in gamewidget.MENU_ITEMS:
-            gamewidget.getWidgets()[widget].set_property('sensitive', True)
-        
         # Make sure we can remove gamewidgets from gameDic later
         gmwidg.connect("closed", GladeHandlers.__dict__["on_gmwidg_closed"])

Index: lib/pychess/widgets/gamenanny.py
===================================================================
--- lib/pychess/widgets/gamenanny.py    (revision 1441)
+++ lib/pychess/widgets/gamenanny.py    (working copy)
@@ -52,6 +52,16 @@
     for item in ACTION_MENU_ITEMS:
         getWidgets()[item].props.sensitive = not auto

+    for widget in MENU_ITEMS:
+        if (widget not in ('hint_mode', 'spy_mode')) or \
+           (widget == 'hint_mode' and 
gmwidg.gamemodel.hintEngineSupportsVariant ==
True \
+            and conf.get("analyzer_check", True)) or \
+           (widget == 'spy_mode' and gmwidg.gamemodel.spyEngineSupportsVariant 
== True \
+            and conf.get("inv_analyzer_check", True)):
+            getWidgets()[widget].set_property('sensitive', True)
+        else:
+            getWidgets()[widget].set_property('sensitive', False)
+
 #===============================================================================
 # Gamemodel signals
 #===============================================================================
@@ -137,6 +147,8 @@
         glock.release()

 def on_game_started (gamemodel, gmwidg):
+    on_gmwidg_infront(gmwidg)  # setup menu items sensitivity
+
     # Rotate to human player
     boardview = gmwidg.board.view
     if gamemodel.players[1].__type__ == LOCAL:

Original comment by mattgatto on 29 Mar 2009 at 8:18

[GoogleCodeExporter]

Original comment by gbtami on 30 Mar 2009 at 7:32

• Added labels: Type-Enhancement

[GoogleCodeExporter]

Looks good.

Original comment by lobais on 30 Mar 2009 at 1:27

[GoogleCodeExporter]

Committed in revision 1443

Original comment by mattgatto on 30 Mar 2009 at 9:28

• Changed state: Fixed

[GoogleCodeExporter]

Is there any reason not to use "standard_rules = True" in shuffle, random and
asymmetric random variants? I can't remember why i used False in shuffle, sorry 
:)

Original comment by gbtami on 1 Apr 2009 at 8:59

[GoogleCodeExporter]

Its because  you can't castle. other than that its standard rules though.

Original comment by mattgatto on 1 Apr 2009 at 9:45

[GoogleCodeExporter]

Using "setboard" in CECP it's not a problem. UCI uses "position" for every 
move, so
it's ok too.

I'v tried glaurung, gnuchess, sjeng and crafty.

Only Crafty seems problematic. It says:
setboard bkqqqbnr/pppppppp/8/8/8/8/PPPPPPPP/QRBBQQNK w - - 0 1
illegal position, too many white queens
illegal position, too many black queens
bad string = "bkqqqbnr/pppppppp/8/8/8/8/PPPPPPPP/QRBBQQNK"
Illegal position, using normal initial chess position

Anyhow, we should enable to play these wild variants against PyChess at least.
What do you think?

Original comment by gbtami on 1 Apr 2009 at 10:21

[GoogleCodeExporter]

Won't the pychess engine have to be told during initialization that castling 
isn't
allowed? Sounds good to me, I just don't know how to do it :).

Original comment by mattgatto on 1 Apr 2009 at 11:30

[GoogleCodeExporter]

I think we should enable them generelly, and just have a good way of failing 
when
engines give this kind of error. Some engines don't even support setboard.
The most ideal place to put this kind of testing is engineNest.py. Then the xml 
file
would contain information on engine support for the extra variants, and the
newGameDialog would be able to filter out crafty.

mattagatto: The fen string also contains castling information, so it is not a 
problem.

Original comment by lobais on 2 Apr 2009 at 5:26

[GoogleCodeExporter]

I changed shuffle, random, and asymmetric random to standard_rules = True in 
revision
1448.

Original comment by mattgatto on 3 Apr 2009 at 9:55