Comments by HGMuller

Such a setup breaks the possibility to change any of the articles and their associated uploaded files, as these are not PHP scripts. It makes you entirely dependent on manual intervention, because any update will with certainty be screened from all remote clients. If you want that, notification of the site admin or an editor that such intervention is needed should be automatic; having to post requests through the comments channel clutters the comments with garbage, as is now happening to this article.

Can the submission / upload script not automatically notify an empowered person that action is required, through e-mail or some specific requesting mechanism? It would of course be even better if these scripts would invoke a program that would purge the cached version in Cloudfare automatically.

I discussed this once with an official of the Japanese Chu Shogi Association, who wanted to revive the interest in Maka Dai Dai Shogi, and had written a manuscript defining the 'modern' rules. He insisted that it would be the last piece captured. And for a Lion Dog he insisted that jumping two squares out to capture something, and then retract one square to capture what you jumped over, was not a legal Lion-Dog move, but that you would always have to capture what is on the adjacent square in the outgoing leg if you wanted to finish there.

It didn't make much sense to me. I would also be happy if you were allowed to choose. Of course this is all highly theoretical; no one would allow both his most-valuable pieces to be in Lion or Lion-Dog range.

As far as I am concerned, something is broken when doesn't fully work as it should. But this doesn't seem worth quibbling about, as long as we agree there is an issue.

It is unfortunate enough that the list of comments to the Betza Notation article gets cluttered with messages like this not directly related to the topic, and losing all relevance in a short time.

@Ben:

How do you know it is the browser? It doesn't look like it is the browser to me. In FireFox, when I press Shift during reload, it will always bypass the cache for the files the main document links to (like images or JavaScript code). And the main page will never be cached. But that does not happen here: I access chessvariants.com/membergraphics/MSinteractive-diagrams/betza.js directly (so that the browser should never have cached it), and it still shows the old content. When I load the directory it is in, it gives the file with today's download date, so the correct file must be on the server.

When I append the requested betza.js link with a dummy CGI argument "t=19", to be sure no one can cache, I do see the altered content. But if I then omit it again, it reverts to the old content.

This happens on two browsers (FireFox and Chrome). After I use the Chrome menu to delete all cached files, I still get the old contents. I don't think it are the browsers.

I guess adding a dummy CGI argument that contains a dynamically requested time to the link in the page that refers to betza.js should fix it. But it is crazy that such a work-around would be needed.

[Edit] I added the dummy "?t=19" suffix to the link to betza.js in the Betza Sandbox comment, so that this at least uses the updated version. But it is not really a feasible solution to do that in every page that refers to the file. And when I update again the "?t=19" would be the cached version, and all the suffixes would have to be updated to a value never used before...

OK, I can get it too now. It only appears to add the spurious Rook moves in two directions, and only when the mount is on an F square. In fact the piece behaves like a bifurcator, going to the second leg not at the mount, but one step in front of it. It is apparently the yafscpF contribution that does this.

And it seems to be caused by the 'original' use of 'p' in the final leg. When I use 'p' in the new meaning of ending on an occupied square for a non-final leg, as in yafscpafF, everything works fine. Which is surprising, as the Betza parser should convert p to paf on any final leg, on reading the description, so that they really should be the same thing. This is apparently what goes wrong.

This is definitely a bug in the Interactive Diagram code. I will look into it. Thank you for reporting it!

[Edit] OK, I have fixed it. The problem was that the Betza parser turned the old-style 'p' on final legs to a multi leg move, by making it into a non-final leg with 'p' mode, and adding an extra leg for the part of the trajectory after the mount. In the internal representation each leg lists how many legs still follow, so that they can be skipped whenever an earlier leg cannot be completed. The existing parser did not increase this skip count on legs before the leg with the old-style 'p', so that when they were blocked the newly added leg for after the mount was not skipped, but was considered another independent move. So when the first F step in yafscpF could not be made because of a blocker, it would transplant the path that should have come after the mount in the second leg to the piece itself.

I also fixed another problem: finite-range hoppers were not working properly. E.g. pR5 would not be an R5 that had to pass over exactly one obstacle, but would be a pR that could only land on the first 5 squares behind the mount. I think in original Betza notation the range should apply to total range, and changed the code accordingly. Downside is that it is not easily possible now to describe hoppers with a fixed finite range after the hop. (Unless that range is 1, in which case the range-toggling 'g' modifier can be used.) I suppose an 'Extended Grasshopper' that could land (precisely) 2 squares behind its mount can still be described as gafafQ (where gafQ would be an alternative notation for gQ, the normal Grasshopper).

Note that caching on this website is broken, so that you might not be able to benefit from the fixed diagram code I uploaded until the site maintainer takes manual action to make the changes visible!

It seems pretty obvious that this piece should be far stronger than an ordinary Bishop. Even the "chiral half" of it (which only has the moves that start with a turn in the same relative direction) has on average more moves than an ordinary Bishop; on non-edge squares it in fact has the same number of moves as a Rook. With both the left-handed and the right-handed moves it doesn't really have double the number of moves, as half of the moves overlap. But even then being able to go there along two paths must be worth something extra beyond having just a single way to get there. (There is no compensation for the fact that the left-handed and right-handed moves overlap on the F-squares, though, as these moves were unblockable anyway.)

@Kevin: Human play is far from perfect, even for GMs. Misconceptions about piece values is just one of the contributions to imperfection. So, yes, GMs can have opinions, and the can afford these opinions to be wrong and still be at the top, because their competitors have their flaws too.

If the value of pieces depended on the general level of play, they would be meaningless concepts. We don't teach beginning chessplayers other piece values as those that GMs are using. Only if a player has a misconception applying to a specific piece, such as that knights are best moved to the board corners and should stay there, it can affect the value this piece has for them.

I though about castling for a while but it does not seem a good thing. It would have involved one step diagonally back which is also uncomfortable. Any thoughts are appreciated.

For this reason I did start the King in Elven Chess on the back rank, and put one of the unorthodox pieces (the Lion) in its place next to the Queen.

Is it better than Nebiyu?

This is a trial for using the Interactive Diagram for Alice Chess. Custom-supplied functions BadZone and WeirdPromotion take care of refusal of moves to squares of which the mirror square is occupied, and take care of shuttling the moved piece to the other board, respectively. The boards are separated by strip of 'hole' squares, which has to be two files wide to prevent Knights from crossing it.

I implemented e.p. capture as a move by the Pawn on the board where the doubly pushed Pawn started. This seemed the least illogical way to do it, as the e.p. square on that board will always be empty (or the double push would not have been allowed). And it is the square the double push really passed over, and thus where it could have been blocked. The move could still be illegal because the corresponding square on the other board is occupied, but that is normal for any move to an empty square in Alice Chess that would be legal on its own board. There has to be no extra rule to prevent double capture this way. This method of e.p. capture corresponds to one where the doubly pushed Pawn must first make a single retrograde step before being captured, rather than replacing its double step by a single step. That this is not the same is the fault of an Alice double push not really being two consecutive single pushes.

I still have a comment to make about the legality of moves (an aspect that the diagram doesn't address). The ambiguity here seems to be caused by not making proper distinction between legal and pseudo-legal moves, but heaping them all under the term 'legal'. A more precise description would have said that a move in Alice Chess is pseudo-legal if (before transfer) it would have been pseudo-legal in orthodox Chess on the board where it is made, and the target square on the other board is empty. And then an Alice move is legal (as usual) when it does not expose the King to pseudo-legal Alice capture. This prevents solving distant checks by interposing a piece that was on the board where the checked King resides (but then disappearing to the other board, so that the King can be captured) from being considered legal. Despite the fact that they would have been perfectly legal orthodox Chess moves on the board with the King.

That is because Nebiyu is an engine, and engines are not supposed to be used directly, but only through mediation of a Graphical User Interface like WinBoard. It is then WinBoard which will take care of launching the engine's .exe file, and send it the proper (text) commands to do something useful.

So the proper procedure is to start WinBoard (either as game viewer without any engine, or for playing against some other engine), then open the Engine -> Load first Engine menu dialog, use the 'browse button' behind the 'Engine' text entry to locate NebiyuAlien.exe, and then 'OK' the dialog. This will make WinBoard start Nebiyu in the background, (possibly terminating the engine that was in use before), and consult it through the appropriate communication whenever it needs it to make or suggest a move. You can then select one of the supported variants from the File -> New Variant dialog.

This procedure will also add NebiyuAlien to WinBoard's 'Engine List', which will be displayed in a listbox on the left in the Load Engine dialogs, so that you can just click on it when you want to use it again in a later session, without having to browse for it first. This Engine List will also be displayed in the comboboxes of WinBoard's Startup Dialog, so that a next time when you start WinBoard you can select Nebiyu immediately, as first or as second engine. (A second engine is only needed when you want to play two engines against each other, through the Mode -> Two Machines menu item.)

@Fergus: I definitely agree that for having sufficient generality it is necessary to be able to resort to some Turing-complete programming language. But a quite large fraction of CVs would not do anything that is not standard (in the sense that hundreds of other CVs would not do exactly the same). If exposing those who want to create presets to the code for such standard tasks discourages them, it would be better not to do that. And it would not be that difficult to achieve that.

One solution could be to reserve the code edits in the preset Edit form only for enforcing / implementing non-standard rules (and perhaps show them only on request, after ticking a checkbox that you want them). And have the code for the very common tasks, such as forbidding capture of own pieces, testing for check / stalemate / checkmate, 50-move draw, repetition draw be added automatically when the user requests this through ticking a checkbox, (e.g. "can expose royal to capture") selecting from a drop-down menu (e.g. "stalemating the opponent wins / draws / loses / is ignored") or typing a number in an otherwise empty text entry (e.g. declare draw when the same position is repeated .... times"). Untouched squares can be remembered for the entire board as a standard action of the basic system; this never hurts, and castling or special rules that require virginity could use them or ignore them as they want.

Most of the time the user would simply select the rules he wants from the combo-boxes, and never have to see the code this results in. The initial settings of these controls on creation of an entirely new preset could be those of normal Chess, so that in most cases the user would not even have to change them, but can just click 'OK' after having selected board and pieces. Only when a rule is not covered by a standard option (e.g. the counting rules for Makruk instead of the usual 50-move rule) the user would have to provide his own code for it, after deselecting the standard rule.

A simpler way to implement this would be to defer all handling of the standard rules such as mate testing to the basic system, but make its execution there conditional, subject to flags or numeric variables. The rule selection of the user would then only have to result in setting of those variables to the selected value at the start of the game.

Note that when I talk about 'default' code I don't mean code that would always be present or run unconditionally, but code that would be added / enabled unless the user decides he wants to provide something different. Where he should always have the option of having that something be nothing. Just allow exposing to check, capture of your own pieces, ignore mates, never declare draw etc. A non-rule-enforcing preset is the same as a rule-enforcing preset for a game without rules...

Well, perhaps I would be less alarmist when I knew how many of these 1300 presets are actually rule-enforcing. (Or more, as the case may be...) And if the result of a discussion could be that this number could easily be raised to 1300 I would consider that 'productive'. One should never set one's aim too low, nor give up too easily.

That we are volunteers with limited time is all the more reason not to scare people away that could improve something.

And the Bishop conversion rule is not so exotic. It is just an example of a special kind of 'initial move', which does not work per individual piece, but per piece type. Perhaps such a thing deserves to be a standard option offered by a wizard, whenever one defines an initial move on a piece type. Like "can be made by all / can be made only once / can be not made only once".

Regarding WinBoard 4.8.0, I don't know how to drop the Hawk and the Elephant playing Seirawan Chess against the Fairy-Chess engine.  After moving a piece, no menu appears asking you to choose which piece you want to drop. Could you, please, help me?

To gate in a piece you first select that piece in the holdings (by clicking it, so that the border highlight around it goes on), and then move the piece from the location on the back rank where you want to gate it in the normal way (click-click or drag-drop).

Last year at the ICGA Computer Games Conference 'Computer Curling' was actually one of the big things. The attraction was that it was a game with a continuous rather than a discrete game state, which makes exhaustive listing of all possible moves impossible. I suppose that to make it difficult there must be some randomness added to the move that you specify, as with infinite precision there would be no difference between an easy and a difficult turn.