The Chess Variant Pages
Custom Search




[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Latest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments by H. G. Muller

Later Reverse Order EarlierEarliest
The new editcomment.php script[Subject Thread] [Add Response]
H. G. Muller wrote on 2020-07-14 UTC

Authors might still be interested in discussions between other people in the comment section. Wouldn't it be better to send a notification to both the page author and the poster of the comment that is replied to?


NEW! This item is a game information page
It belongs to categories: Orthodox chess, 
It was last modified on: 2020-07-07
 By Daphne  Snowmoon. Melee Chess (Veritas). There are only pieces that move only 1 or 2 squares.[All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-07-13 UTC

You can click on the 'move' header of the piece table to switch that column between displaying the Betza notation for the move, and the piece value. But you should not take the values too seriously. For one, they are estimates for the value the piece would have in a game without piece drops. When pieces can be dropped this tends to push the values closer together, as even the pieces with very low mobility can easily be transported to remote locations where they deliver threats immediately by dropping them. Also, with piece drops the promoted value has more impact, because pieces tend to be dropped in the zone, and then promote very easily.

Even in games without drops some of the well-known piece values are wrong. (E.g. the Archbishop.) Amazingly enough the ratio of the values of the orthodox pieces seems very reasonable. But the algorithm is based on (smartly weighted) average mobility only, and it does not recognize handicaps such as color binding, or worse forms of area binding. So it would likely over-estimate the value of, say, an Alibaba. That the value of a FIDE Pawn it gets is reasonable is probably just a coincidence, because it ignores the latent value due to the promotability, but also does not realize the Pawn is bound to a single file. These errors seem to largely cancel each other.

The Diagram's AI is not intended to be an analysis tool for piece-value determination; its purpose is to act as a not-too-stupid sparring partner for somewhat experienced chess players who just learned the rules of a new variant. Very accurat piece values are not needed for that purpose. That it can show the values at all was mainly for debugging purposes.


The new editcomment.php script[Subject Thread] [Add Response]
H. G. Muller wrote on 2020-07-13 UTC

The 'Edit' links seem to have disappeared from all my comments. Is there another way to modify a comment now?

[Edit] Forget about this; I see the link now. Not sure what was wrong before, it said I was logged on.


NEW! This item is a game information page
It belongs to categories: Orthodox chess, 
It was last modified on: 2020-07-07
 By Daphne  Snowmoon. Melee Chess (Veritas). There are only pieces that move only 1 or 2 squares.[All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-07-13 UTC

It says that when it has no royal piece. It doesn't automatically assume that a piece called 'King' or is depicted by the conventional king symbol is royal. Perhaps this is a mistake, and I should make it do that by default. But as it is now, it assumes the last piece of the table is the royal piece. In your case that it a promoted type, not present initially, hence the complaint. (It doesn't actually test whether the opponent does have a royal iafter it discovers it has none, as this situation usually occurs only when his own royal was just captured.)

When the royal piece is not the last piece in the table (or you have multiple royal piece types), you must explicitly specify the royal type by adding a royal=N parameter. In your case, you would have to specify both royal=8 and royal=16 amongst the Diagram parameters, as you want both King and Lion to be royal.


This item is a reference work
It belongs to categories: Orthodox chess, 
It was last modified on: 2015-11-06
 By H. G.  Muller. Interactive diagrams. Diagrams that interactively show piece moves.[All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-07-12 UTC

Well, Chu Shogi seems to be the only case where this exception exists, and it makes no sense to tailor a diagram that is intended for general use too much to one specific variant. The diagram already has a 'hook' for customizng promotion rules to a variant: the page can provide a function WeirdPromotion() for sanctioning a default promotion, or altering it. I guess it would have been better if the Chu Shogi exception for last-rank Pawn promotion would have been implemented through that. Now the Diagram does it by default, it also happens in Dai Shogi, where the rule makes no sense (and thus probably would not have applied) because it is always better to promote a Pawn to Gold when entering the zone.


UPDATED! This item is a game information page
It belongs to categories: Orthodox chess, 
It was last modified on: 2020-07-12
 By David  Paulowich. Shatranj Kamil (64). (Updated!) Modern Shatranj based variant on 8 by 8 board with new pieces. (8x8, Cells: 64) [All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-07-12 UTC
files=8 ranks=8 promoZone=1 promoChoice=S graphicsDir=/graphics.dir/alfaerie/ squareSize=52 graphicsType=gif stalemate=win baring=0 pawn:P:fmWfcF:pawn:a2,b2,g2,h2,c3,d3,e3,f3,,c6,d6,e6,f6,a7,b7,g7,h7 knight:N:N:knight:b1,g1,,b8,g8 rook:R:R:rook:a1,h1,,a8,h8 general:G:F:ferz:d2,,d7 elephant:E:AmD:elephant:d1,e2,,e7,d8 silver:S:FfW:silvergeneral:c1,f1,,c8,f8 king:K:K:king:e1,,e8

This item is a miscellaneous item
It belongs to categories: Orthodox chess, 
It was last modified on: 2015-12-11
 Author: Fergus  Duniho. Home page of The Chess Variant Pages. Missing description[All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-07-12 UTC

I share that opinion.

I also don't see a link in the footer to return to the general comments listing. Only to the comments for the particulat page.


This item is a reference work
It belongs to categories: Orthodox chess, 
It was last modified on: 2015-11-06
 By H. G.  Muller. Interactive diagrams. Diagrams that interactively show piece moves.[All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-07-12 UTC

Oops, I inadvertantly unbalanced parentheses when fixing the problem that in the checkmating applets it insisted the first piece should promote when the piece table was open (despite promoZone=0). Fixed now.


The new editcomment.php script[Subject Thread] [Add Response]
H. G. Muller wrote on 2020-07-10 UTC

On my desktop monitor: 1680 pixels.


H. G. Muller wrote on 2020-07-10 UTC

I think the CKEditor was a lot more user-friendly then markdown. It made it very easy to enter simple text messages with common typographic refinements. You just had to be careful to never switch off 'source-code' mode once you had messed with the HTML.

The new script doesn't seem to have an exit: when you click 'post' after having seen the preview, it goes back to edit mode.


This item is a miscellaneous item
It belongs to categories: Orthodox chess, 
It was last modified on: 2015-12-11
 Author: Fergus  Duniho. Home page of The Chess Variant Pages. Missing description[All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-07-08 UTC

The strange thing is that the images Adam uses in the piece section are the same images as that are used in the Diagram. So if after a few days the images in the piece section get flushed at Cloudfare, I would have expected the same to be true for those in the Diagram. I understand that when you would add ?nocache=true (or apparently any dummy CGI arguments), you would bypass Cloudfare, and always get the up-to-date CVP info. But none of Adam's links had that when I looked, neither in the piece section, nor in the Diagram.

As the Diagram constructs the name of the image files by concatenating graphicsDir + colorPrefix + rootName + '.' + graphicsType, the user can force bypassing of Cloudfare by suffixing the graphicsType with ?nocache=true . The images would still be cached in his own browser (as repeated access always uses the same CGI arguments), like any images in the page, but he can flush those himself.

I thought of having the Diagram add the ?nocache=true suffix automatically, but I decided against it. For one, it would be a rare situation that piece images get updated. Normally, when creating a Diagram, one would use existing piece sets on the site, or freshly uploaded membergraphics. Even if an update would take place, it would become effective for everyone in just a few days. And if the usuer is in a hurry, he can add the suffix to the graphicsType himself.

For other images in the original HTML the user must also add the ?nochace=true suffix by hand, if he wants to see updates instantly. E.g. when I publish new Diagrams here, which I usually do for the purpose of testing new features of the betza.js script, I add the ?nocache=true to the link to that script, to make sure I use the just updated version. That older Diagrams elsewhere still keep using older versions of the script doesn't matter, as they did not need the new features, so the older version should be perfectly OK for them. There would be no attempt to load the updated script anyway unless the user explicitly ordered his browser to flush the cash; like image files, separate JavaScript files are also cached by the browser.

Another reason is that I sometimes abuse the Diagram's graphicsDir parameter for specifying a complete URL including CGI arguments, so that the colorPrefix + rootName will be appended as (value of) CGI arguments, for driving a server-side script to generate the piece graphics. An extra ?nocache=true would then violate URL syntax.


H. G. Muller wrote on 2020-07-07 UTC

Sure, but I what the PHP script sends you should show up at the client side when you look at the page source. I was puzzled by that Adam reports a different behavior between the images in the piece section, which are in the retrieved HTML part, and those in the Interactive Diagram, which are client-side JavaScript generated. Because neither of those has a nocache=true suffix. The image tags in the original page source look exactly like those that the JavaScript would generate.


H. G. Muller wrote on 2020-07-07 UTC

What happens when, in the diagram, you specify graphicsType=png?nocache=true ? I am not sure this would help, though, as the other images in your article also don't seem to have a ?nochache=true suffix (as seen from the page source). I understood from what Fergus said that all URLs in the src field of a HTML tag when retrieved from the database would automatically get this suffix. But I apparently misunderstood that, because the betza.js in the <script> tag in an article or comment also don't get that, so that they do not use the updated version unless I add it by hand. I have now adapted the Interactive Diagram Design Wizard to always add that suffix, so it would bypass the server caching. But it could be needed for the image names generated by the script as well.


This item is a game information page
It belongs to categories: Orthodox chess, 
It was last modified on: 2006-09-27
 By M  Winther. Venator ChessThis item is a game information page
It belongs to categories: Orthodox chess, 
It was last modified on: 2006-09-27
 By M  Winther.. Introducing the Venator, a bifurcation cannon related to the Korean cannon, on a Gustavian board (zrf available).[All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-07-06 UTC
files=10 ranks=8 promoZone=1 promoChoice=QNBRV graphicsDir=/graphics.dir/alfaerie/ squareSize=52 graphicsType=gif hole::::a2-a7,j2-j7 pawn:P:ifmnDfmWfceF:pawn:b2-i2,,b7-i7 knight:N:N:knight:c1,h1,,c8,h8 bishop:B:B:bishop:d1,g1,,d8,g8 rook:R:R:rook:b1,i1,,b8,i8 queen:Q:Q:queen:e1,,e8 venator:V:gafyafsR:champion:a1,j1,,a8,j8 king:K:KisjO2:king:f1,,f8

This article has no graphics and a very minimal description, so let me post this diagram to liven it up a bit. Also a good opportunity to draw some attention to the class of pieces known as Bifurcators. The Venator is not nearly appreciated as much by the Diagram as it is by its inventor: only about 2/3 of a Knight. This is not to say the Diagram is right, of course. For one, it only tries to estimate intrinsic tactical ability. A piece like the Venator has great forking power in dense positions, so it will be almost impossible to prevent the players can trade it for another minor in an early stage.


UPDATED! This item is a desktop publishing resource
It belongs to categories: Orthodox chess, 
It was last modified on: 2020-06-17
 By H. G.  Muller. Betza notation (extended). (Updated!) The powerful XBetza extension to Betza's funny notation.[All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-07-05 UTC

Right, I did not account for multiple move borrowers. I do exclude borrowing from the same piece type, as Odin's Rune Chess has a pair of move-borrowing Kings that start next to each other. So I learned about the problem you experienced the hard way too.

Passing a flag that suppresses recursive borrowing, as you suggest, would indeed be a more robust solution. A more complex solution would be to make a list of piece types from which you already borrowed. Or even better, moves that you already borrowed, and don't borrow moves you already have borrowed from another piece (or had to begin with). That would avoid duplication of moves when you have more than one piece of the same type next to you, or pieces with overlapping moves suchas Q and R. Which would greatly increase the efficiency of the AI as long as it has no transposition table.

I think I will go for the simple flag, though, and hope one day I will get to equip the AI with a TT. In fact the infra-structure is already in place: the routine now passes a mask that suppresses some of the modes by clearing their flags, for the purpose of imitation. There I use it for clearing m or c flags. But the x flag is also in there.

[Edit] It should be fixed now. (Untested!)


H. G. Muller wrote on 2020-07-05 UTC

Argh! You are right. It used to do that, but I broke it when implementing the Imitator. Both the Imitator and the move borrowing call the old move generator used for highlighting recursively. But for the imitator I added an extra argument, to restrict the moves of the target piece to the mode that you imitate (e.g. if you have a cI it should only imitate the captures). I had forgotten to pass this argument in the call for borrowing moves, and the missing argument then was interpreted as 0, so that you would never borrow anything.

Thanks for spotting this; I now fixed it.

The selective imitation does not really work satisfactorily anyway on multi-leg moves. Because it is not clear what are captures and what not. E.g. a Checker would have a capture in its first leg, and then a non-capture where it lands, and the selective imitation would now always reject one of the legs. While intuitively we think of the move as a capture (I think). So perhaps multi-leg moves should be considered captures when any of their legs makes a capture, no matter what the other legs do, for the purpose of selective imitation.

Not sure if there exist any CVs with selective imitation anyway, so this didn't have a very high priority...


H. G. Muller wrote on 2020-07-04 UTC

Well, xK borrows moves from neighbors, and the move diagram shows pieces on empty boards. So there isn't really anything to show. On the board it would just behave as the compound of all its neighbors, without specially indicating which those neighbors are.

It does seem mildly useful to highlight the squares where it could borrow from, like it does now. I am not sure why it does that in red, which is the color for capture-only. I guess I should define an entirely new color for it.


This item is a game information page
It belongs to categories: Orthodox chess, 
It was last modified on: 2012-02-09
 Author: Hans L. Bodlaender and Fergus  Duniho. Shogi. Missing description (9x9, Cells: 81) (Recognized!)[All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-07-04 UTC

I still have some doubts with regard to the application of this rule. In particular, when a (checking) position occurs from which it is possible to deliver perpetual checking, but instead of continuing the checking you play something else. And then later, that position occurs a second time. Now you do continue the checking, and the opponent has no way to escape it, so you get a 3rd and 4th repetition of the position.

Does this now count as perpetual checking? Not all moves since the first occurrence of the position were checks. But all moves since the 2nd and 3rd occurrence are. In my engines I would only consider the moves since the previous occurrence. (Especially because it already terminates the line at the 2nd occurrence; if it cannot break from the loop the first time it goes through it, nothing will change by trying it the second time, except that you have less search depth left, which will degrade the accuracy of the evaluation.)

I would think that only considering the moves since the previous occurrence would be more in line with the spirit of the rule; you try to force a repetition by perpetual checking, and this should not be allowed. It is just that you started the checking a bit late, but now that you are at it, and can keep it up perpetually, why should that matter? When I asked it to a Japanese in connection with mini-Shogi, however, he told me this would not be considered perpetual checking, and thus produce a sente loss. (Which is a special mini-Shogi rule; in regular Shogi that would be a draw.)


UPDATED! This item is a game information page
It belongs to categories: Orthodox chess, 
It was last modified on: 2020-07-02
 By Greg  Strong. Brouhaha. (Updated!) Like Chess, but it really brings the ruckus! (8x8, Cells: 72) [All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-07-02 UTC

Right, although one could argue that in Brouhaha not all the squares between the Scouts and the Clerics are 'brouhaha squares'. But in Aurelian's game, which has 5 adjacent brouhaha squares, A rook should not be allowed to capture from one to the other once the intermediate pieces have left their launch square.

The Interactive Diagram I also does not allow sliders to move over the blacked-out squares; they are considered 'off board'. This because their original purpose was for implementing irregularly shaped boards, like Omega Chess. Leapers can jump over them, though. Actually I am not sure what hoppers would do, or even what they should do. One interpretation of inaccessible squares is that they are occupied by uncapturable unmovable pieces, and in that case hoppers might want to use them as mounts!

I guess it would be easy to distinguish several different types of 'terrain' for use as 'background' to which an evacuated square reverts. It would all be inaccessible, but one flavor could be blocking to anything, while another flavor could allow sliders to fly over it, and another could allow hoppers to use it as mount, and these could even be combined as independent properties.


H. G. Muller wrote on 2020-07-02 UTC

But you could also have said: "that square disappears when it gets empty".

From the description of Cheshire Cat Chess:

Every time a square is vacated, because a piece moves away from it, the square disappears.

They don't bother to mention that you can capture pieces while they are still on the square. They do mention pieces can move over such disappeared squares, though. (Which is indeed worth mentioning, as I would not expect that. And I don't think that would apply to brouhaha squares, e.g. by a bent slider.)


H. G. Muller wrote on 2020-07-02 UTC

I guess it depends on how one formulates the rules. I saw the special rule that defines these squares as "turns into inaccessible when abandoned, rather than empty". And I also implemented it that way, by replacing board[fromSquare] = 0; in the MakeMove() routine by board[fromSquare] = background[fromSquare], where the background array then could be initialized with empty and inaccessible squares as desired. (Inaccessible squares were already implemented, for the purpose of simulating non-rectangular boards.)

So the rule that you can capture the piece on the brouhaha square was not really an extra rule, as it is normal that you can always capture any piece. It would have required quite some extra code in various places to forbid pieces to enter it (or hop over it) even when a piece was occupying it; every move would have to test the background under the piece as well as the board itself. And it would become even more complex when you had to make exceptions for what the piece on the brouhaha square is forbidden to do compared to its normal capabilities. Especially if this included blocking check.


H. G. Muller wrote on 2020-07-02 UTC

What do you think? Would it work?

Usually, the fewer rules the better, and the simpler the rules the better. Pretty much anything can be made to work, when you take away all the reasons why they would not work by additional rules. Most choices in CVs are arbitrary. Which is why there are so many. As I see it the 'brouhaha squares' are just one such arbitrary choice that work through very simple rules. To implement them in the Diagram's AI was also trivial.

I think that (in Brouhaha, at least) capture on a brouhaha square is mostly hypothetical; in practice players would develop their pieces long before these squares could come under attack, being sheltered by two fully occupied ranks. This would be different when you added brouhaha squares at the side edges near the middle; then this would become a real issue. But the simplest remedy to that is not do it. Why would you? Plenty of room near the back rank.


UPDATED! This item is a game information page
It belongs to categories: Orthodox chess, 
It was last modified on: 2020-04-21
 By Daniel  Zacharias. Expanded Chess. (Updated!) An attempt at a logical expansion of Chess to a 10x10 board.[All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-07-01 UTC
files=10 ranks=10 promoZone=3 promoChoice=!PQ1G2R2OZBN graphicsDir=/graphics.dir/alfaerie/ squareSize=52 graphicsType=gif pawn:P:ifmnDfmWfceF:pawn:a3,b3,c3,d3,e3,f3,g3,h3,i3,j3,,a8,b8,c8,d8,e8,f8,g8,h8,i8,j8 zebra:Z:Z:zebra:d1,g1,,d10,g10 knight:N:N:knight:c2,h2,,c9,h9 bishop:B:B:bishop:d2,g2,,d9,g9 osprey:O:DmpafyafsW:bird:e1,f1,,e10,f10 rook:R:R:rook:b2,i2,,b9,i9 gryphon:G:FyafsF:gryphon:b1,i1,,b10,i10 queen:Q:Q:queen:e2,,e9 king:K:KisO3:king:f2,,f9


This item is a game information page
It belongs to categories: Orthodox chess, 
It was last modified on: 2018-01-23
 By Zied  Haddad. Musketeer Chess. Adding 2 newly designed extra pieces. (8x8, Cells: 64) [All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-06-30 UTC

Well, the author of that page is one of our new editors...


NEW! This item is a reference work
It belongs to categories: Orthodox chess, 
It was last modified on: 2020-06-16
 By H. G.  Muller. Play-test applet for chess variants. Applet you can play your own variant against.[All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2020-06-29 UTC

I now put a somewhat more refined search in the AI of the Interactive Diagram, in the hope that this would make it more human-like w.r.t. the things it will overlook. It now focuses its attention more on moves that are logical continuations of what happened before. In particular moves that 'touch' squares that were mutated one or two ply earlier. That would include recaptures, plunder raids, discovered threats, pin punishment. But also hopper activation; it doesn't matter whether the mutation was evacuation or placement; if a move goes over or to it, it gives it more attention than other moves.

As this search is much less fixed-depth than the previous one, the meaning of the ply setting has become a bit vague. If we count PV moves as one ply, most non-captures elsewhere in the tree would count double. I made the '2 ply' setting such that it will still search every reply to the move it intends to play (validated by an exchange evaluation), which means that the PV will actually be 3 ply long. Recaptures are now only not counted in the depth when a lower-valued piece captures a higher or an unprotected one; recapturing a lower protected piece doesn't get more attention than any other capture (or PV move).

It is still true that at 2 ply it wouldn't see a (new) mate-in-1 threat against it, and at 3 ply it will. It would see it when it can checkmate you in one at 2 ply.

As this is a bit more bug-prone than the very simple original search, please let me know if it shows erratic behavior. I am aware that its play with Pawns currently sucks. I could easily put in some evaluation that would solve this for FIDE/Shatranj Pawns, but that would break the generic nature of the AI. It does seem to be the kind of Pawn for which this is most important, though; there don't seem to be many subtleties with Asian or Berolina Pawns. (And of course the overwhelming majority of CVs have FIDE Pawns.)

I am open for suggestions for what additional features (other than pieces with nearly arbitrary moves) could be supported by the AI to make it more useful.


25 comments displayed

Later Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.