First a new small bug: have hachu played a full Chu game, probably after having selecting a white piece, and noticed that the dot stayed there till end of the game: http://imagebin.org/293529
On Fri, Feb 14, 2014 at 11:48:16AM +0100, h.g.mul...@hccnet.nl wrote: > > * games defaulting to hachu (@chu and @sho) look OK > > * games defaulting to gnu(mini)shogi require xboard support, I'll > > upload a gnushogi master snapshot into experimental as well; they work well > > with the correct binaries in $PATH > > * @mini should I think default to japanese theme > Mini-Shogi is not an officially-defined variant of XBoard, and thus needs > some user configuration to be played. In cases like that, it seemed best > to separate the theme config file from the rules config file. (I guess the > same in principle holds for Sho Shogi, but I probably figured that there > would be no interest outside the traditional Shogi community for that > anyway. While for mini-Shogi I see a good future, provided that people get > the opportunity to play it in a 'kanji-free version'.) > > The need for user rule configuration would disappear completely if GNU > miniShogi would use the engine-defined-variants feature of XBoard-exp, > however, and I think this is the way to go. I should simply announce > > feature variants="mini,5x5+5_shogi" > > and respond to the "variant mini" command with > > setup (P.BR.S...G.+.++.+Kp.br.s...g.+.++.+k) 5x5+5_shogi > rbsgk/4p/5/P4/KGSBR w 0 1 > > Then it could be played by simply selecting "mini" from the New Variant > menu, and no rule configuration would be needed anymore. The 5x5+5_shogi > would only be mentioned in the variants feature for compatibility with > older interfaces and older engines. (E.g. if you want to play engine vs > engine, and the opponent engine would not support 'variant mini'.) Then > only theme configuration would remain, and you could use @shogi for that: > > xboard @shogi -fcp gnuminishogi > > would overrule gnushogi as default engine specified in @shogi. I see. However, the problem of giving easy access to all those GUI-only users not willing to dive into manpages to discover that, will still be there. > > * @xq board drawing is messed with large window sizes here, > > although OK with smaller window sizes (see http://imagebin.org/292981), > > otherwise seems OK > > That is a matter of the size of the bitmap provided for the Xiangqi board. > XBoard cuts tiles the size of a square from this bitmap. For a square grid > of NxN squares that would in principle allow cutting 2Nx2N squares out of > it before you start to see the next grid line, but with the diagonal lines > in the Palace you already see artifacts when the square size gets >N. > These are not very annoying, however. My attitude was pertty much that if > people would think the board is too messy, they should simply switch to > smaller square size. In older XBoard (before it used Cairo) the only sizes > for which there were built-in westernized Xiangqi piece bitmaps were 33, > 49 and 72 anyway, and the bitmap of teh Xiangqi board was made with 49x49 > grid. Hm, with today's large screen sizes, it's not very friendly to require keeping a small window. What about using SVG there instead ? > > * I feel .desktop files for shipped confs would be > > needed to make them more visible to users > > Indeed, the confs are only useful from the command line. OTOH, confs can > be combined on the command line, which is useful when they configure > different aspects (game rules, board theme, engine). It would be hard to > provide desktops for every possible combination of those. But if there are > a few obvious combinations of theme + rules + engine (e.g. because GNU > also features an engine, such as with GNU Shogi), we could make desktop > files for those. Or maybe provide a launcher to select theme/rules/engine and run xboard with proper options, at least until those are made selectable from within xboard itself ? There are tools to help for this (remember seeing new packages in Debian for this months if not years ago), but I can't find the right keywords to find them again. > > * Trying to switch to Dai or Tenjiku is refuse with "Engine did not send > > setup for non-standard variant" * Maybe a @hachu conf would be useful for > > easy access to those games ? Maybe better shipped by hachu itself ? > > The current XBoard does not support Dai or Tenjiku, and could not be made > to support them even through user configuring. The number of piece types > needed for thos games exceeds XBoard's current maximum (44 piece types, > which was already doubled compared to 4.7.x in order to support Chu > Shogi). Only the WinBoard 'Alien Edition' fork currently supports those > variants (as well as Dai Dai, Maka Dai Dai and Tai), but the piece images > are constructed from scratch in the WinBoard front-end in the 'mnemonic' > theme, so this does not work for XBoard. > > In addition, Tenjiku is not fully implemented in HaChu yet. The move > generator still doesn't do 'area moves'. My original plan was to first > finish the move generator for all variants (which would also require me to > do hook movers fot Dai Dai and larger), before starting to worry about > search and evaluation, but then people started to push me for quickly > getting a working Chu, and I never got back to finishing the Tenjiku. > > This exposes a weakness of the engine-defined variants protocol: an engine > can claim to support variants xxx and yyy, but as XBoard has no idea what > these entail, it cannot realize that it is not able to support them. It > only gets that info from the engine after the user selects the variant, in > the 'setup' command. Only at that point XBoard can discover it is not able > to support the variant, for a number of reasons (too-large board size, too > many piece types, parent variant unknown, and of course errors in the > setup command). This might seem strange to a user that doesn't know in > detail how things work. But to prevent it XBoard would have to probe the > engine for every variant, which currently can only be done by switch it to > that variant, and waiting for the 'setup' response, to judge from there > for of the variants it wants to display buttons in the New Variant dialog. > Perhaps I should do that, although I really hate to mess with an engine > that way. Right. Maybe a more user-friendly message would be enough, and you could keep the detailed reason for -debug ? > > * I guess xboard shipping chu and sho confs make those in hachu.git > > redundant ? > > > > Yes, it would. I think the future will be to distribute those confs with > the piece and board graphics as separate packages, apart from XBoard or > the engines. Makes sense. We'll have to find a correct set of relationships to declare between them. I guess it makes sense to have them depend on xboard and recommend the default engine. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org