Comments by HGMuller

True. But I have always had the feeling that XBetza notation should be the vehicle to specify that, not the promotion. What I am missing in XBetza is the possibility to specify a side effect that is mandatory when possible, but not blocking the move when impossible.

How about this: the modifier t is a leg separator like a, except that the actual piece move terminates at that point, and the remaining legs only describe the path of its 'influence'. If this is not a unique continuation, all possible realizations will be combined with the move. So where yacabQ would describe a Queen that (by virtue of the y) does a single King-like burn of an enemy, ytacQ would burn every enemy adjacent to the square it lands on, and can even land there if there is no adjacent enemy at all. An Ultima Pincher Pawn would be ytacfapR, where the captureMatrix would be used to forbid the piece (and its influence) to hop an enemy. Unlike actual moves, the last leg of the influence can be a 'hop-on' leg.

If you are prepared to use JavaScript there are many ways you could interfere with the standard operation of the Diagram. There is for instance a routine ScoreMove(move, predecessor), to prep the 'raw' moves coming out of the move generator by determining the piece types of the capture victims, storing those in the array describing the move, and calculating the effect these captures (and promotions) would have on the score. ('predecessor' is the move preceding it, only used to enforce anti-trading rules). Interfering there to add a few burn victims is not very difficult; you just replace the function by a wrapper for it, like:

var OriginalScoreMove = ScoreMove; // remember the standard routine
var burnX = [ 1, 1, 1, 0, -1, -1, -1, 0 ];
var burnY = [ 1, 0, -1, -1, -1, 0, 1, 1 ]; 
function ScoreMove(m, last) { // and redefine it
  var x = m[0], y = m[1];     // origin
  var piece = board[y][x];    // moving piece
  if(IsBurner(piece)) {
    var n = 4; // 0-3 are the coordinates of origin and destination
    for(var k=0; k<8; k++) {
      var xb = x + burnX[k], yb = y + burnY[k]; // coordinates of neighbor square
      if(IsEnemy(xb, yb)) { // this is assumed to return 0 when (x, y) is off board
        m[n++] = xb; m[n++] = yb; // add a locust victim
        m[-2]++; // this counts the number of squares in the move
      }
    }
  }
  return OriginalScoreMove(m, last); // call the standard routine on the modified move
}

Positions like this suggest that promotion to colorbound pieces is a poor design choice.

One could also argue that promoting to the weak, color-bound Ferz enriches Shatranj with an interesting strategic theme: one has to plan Pawn manoeuvres such that you won't promote all your Pawns on the same shade. And definitely do not leave the opponent a defender on the other shade when you are playing for a win. This is already true in orthodox Chess, where unlike Bishops can draw even against a majority of 2 Pawns, despite the fact that these would promote to Queen.

It is true that Shatranj is quite drawish, but I think this is more a consequence of the Ferz being such a weak piece than of its color-binding. I doubt that promoting to Wazir would be much of an improvement.

Kamikaze pieces are a form of promotion (namely promotion to an empty square). The Interactive Diagram does support mechanisms for indicating unusual promotions (like the captureMatrix), but unfortunately promotion to empty is not amongst those. The problem is that promotion code 0 (the code of an empty square) is used to indicate there is no promotion, and the piece remains itself.

It should be possible to use another code for indicating promotion to empty, though, and recognize that as a special case in the routine that performs the moves.

The ShowMoves problem appears to occur because this still uses the old highlighting routine. And now that I leave out the loop directive from the internal move descriptors this cuts non-final slider legs with m rights (which should continue after a succesful try) to their first step. I should make the highlighting in ShowMoves also be done with NewClick(); I guess I didn't do that because it never has to deal with a double locust capture, as hovering gives you at most a single potential victim.

A reasonably cheap method for tracking pieces (of all types!) would use an array location[] indexed by (colored) type, where the square numbers (calculated as 128*rank + file) where pieces of a given type sit would be stored in location[type] and location[type+512]. This can be updated in MakeMove() like

function TrackMakeMove(m) {
  var p = m[-6] & 1535; // moving piece (stripped of marker flags and virginity)
  if(location[p] == 128*m[1] + m[0]) location[p] = -1; // mark first entry as invalid when it was for the moved piece
  p = m[-1] & 1535; // promoted type (could be same as mover)
  if(location[p] < 0) location[p] = 128*m[3] + m[2]; // put destination in first entry when the latter was unused
  else location[p+512] = 128*m[3] + m[2]; // otherwise it must have been for the other piece of this type, so this piece uses second entry
  OriginalMakeMove(m);
}

and similar for UnMake(). It would not take account of capture of the pieces, (which would be cumbersome because of the possibility of locust capture), so when using the locations for a type it should always be tested whether a piece of that type is actually there; it could still indicate the square where a piece of that type was captured, but which now is occupied by something else.

Limitation is that it would only work if there are at most two pieces of the types of interest. Which for Suzumu Shogi would not be the case, as there could be four Tetrarchs. But somehow it doesn't seem wise to adapt a general feature to a very exceptional case; in virtually every variant there are only two pieces of each type. One could always artificially make the Diagram use two different Chariot Soldiers and Tetrarchs, each present as a pair. After all, we already artificially distinguish a Lion Hawk obtained through promotion from a primordial one, just to maintain a homogeneous mapping from piece to promoted form.

With the aid of this you would only have to look for enemy Tetrarchs in 4 locations, rather than 256. You would do that in BadZone() when you find 'nodes' increased, and for every Tetrarch you find this way you would set the square surrounding it to 'nodes' on an auxiliary board. Moves starting from a thus marked square would then be suppressed, as that piece would be frozen.

Greg Strong wrote on 2023-01-25 UTC

Is that right or are there any differences I missed?

In Janus Chess castling with the far Rook makes the King move 4 steps.

I am wondering whether I should make hop-restrictions a standard feature of the Interactive Diagram. This could for instance be done through the captureMatrix parameter. That already has a symbol for 'capture forbidden' (the !), that can be used to outlaw captures of one specific type by another. A symbol ^ in the location of AxB could mean that A is not allowed to hop over B, and a 0 that it can neither hop over nor capture B. A ban on hopping could also be applied to locust capture.

Of course the capture matrix for a game like Suzumu Shogi would be horrendously large. But most rows could be left empty, as most pieces neither hop nor locust-capture, and there are no bans on normal captures.

As to freezing: a much faster way to do implement that is to have NewMakeMove() and UnMake() keep track of the Tetrarch locations (which I understand are the only freezers). This could for instance be done by having arrays next[] and prev[] indexed by square numbers, that link all Tetrarchs of the same color in a doubly-linked list that is also accessible by square number. To remove a Tetrarch on square sqr from the list (because it moves away or is captured) you would just do

next[prev[sqr]] = next[sqr]; prev[next[sqr]] = prev[sqr];

To place a Tetrarch (because you moved it there or promoted to one) you would do

next[sqr] = next[-1]; prev[sqr] = -1; prev[next[-1]] = sqr; next[-1] = sqr;

Most moves would not move or capture a Tetrarch, so the overhead is limited to testing if they did. But it would allow you to quickly loop through the Tetrarch locations by following the next[] links starting at next[-1] (and the other color would use next[-2]). Most of the game the list would be empty anyway (i.e. next[-1] = -1). You could do that at the start of move generation, and when you find a Tetrarch, replace every adjacent enemy piece by a dummy without moves to freeze them. You would of course have to undo that immediately after move generation.

[Edit] I now implemented piece-type-selective exclusion of hopping through the capture matrix, using ^ (for outlawing hopping for that piece combination) and $ (outlawing both hopping and capture, like for the Cannon in Janggi). This can also be done independently for friendly and enemy pieces.

I fixed the Pawn move in the Diagram, and added Prince to the promoChoice. (Now indicated by the letter M to distinguish it from Pawn.)

I think promotion to Prince is an improvement, because 2M vs N or 2M vs M are general wins (when stalemate is a win), while any other combination of two pieces cannot beat a lone N or M. So the advantage of a single Pawn can now be enough to force a win. And a lone K is already enough to beat a lone desert piece. So this should remove most of the drawishness, if there ever was any.

The NewClick entry system is still experimental, and in general I try to avoid auto-completion. But there is one exception: I put in a heuristic that classifies a locust capture eaither as 'shooting' or 'trampling' (depending on whether the leg after it goes back to the square the previous leg came from), and swap the click order of the two legs in that case. So that you can first click the final destination, and only then what you shoot. This seemed more naturally, e.g. in the case of the Forest Ox of Odin's Rune Chess.

Perhaps this now interferes with what you are trying to do, and needs some refinement. Can you be more specific on what goes wrong?

With BadZone() you should be able to restrict the list of moves that is generated, suppressing the burns you don't want. If this will lead to a list from which the NewClick() algorithm cannot properly select the one you want, this should count as a defect in NewClick(). Not as a problem with using killX/Y in BadZone().

If the Princes are not royal, then why should these not be available as promotion choice? It would certainly be helpful in reducing the alleged drawishness of this variant. Kings are very efficient in chasing Ferzes and Wazirs to their doom; I don't think Knights can do that as easily. The desert pieces have a weakness in attacking pieces at the edge or in a corner.

That total extermination is a win condition that is often difficult to achieve is mainly caused by the participation of powerful pieces. The pieces in Desert Pub Chess are all quite weak; the Prince is probably the strongest in the end-game, and we know from Chess that a bare King is easy to checkmate (and then will get captured, if the game would not end at checkmate).

The article doesn't specify what the game result is in case of stalemate; I configured the Diagram to make that a win. After all, losing all your pieces is just one way of being stalemated. The Diagram limits the number of captures in one move to four.

If this is 'Post-Move' code, the Pawn has already landed on the to-square, so that it is no longer empty? Try

verify == captured @;

For my understanding: why is it necessary to copy the screen to a variable, before testing it. Is there a problem with writing

capture screen;

?

Considering the WA a weak version of the Q is a stretch of the imagination. The value difference alone makes it a completely different piece, in the way you have to use it. On 8x8 the opening value of the FA is hardly different from that of a Bishop. On larger board the Bishop gains value, but the FA stays similar in value to a Knight. As the WA would. Each of those is, after all, an 8-target leaper.

The AI of the Diagram now also understands the trick of reserving a square for your next move by playing the Duck there, as you can verify by setting up a position through h7-h6, g7-h4, h2-h3, Ke8-h5, Qd1-d3. If at that point you switch on the AI, and play a useless move for black (e.g. a7-a6, Duck to a7), the AI will reply with Qf5, Duck to g5, and announce mate. (Which in this case does not end the game yet, but should be interpreted as announcement of King-capture in 2. In general the Diagram will allow you to play on when you are checkmated; if you do a pseudo-legal move there it will capture your King an announce "I win".)

It is good that you also include extra light pieces. But why use the Elephant-Ferz? It is so similar to a Bishop that it adds very little to the game. So why not use the Elephant-Wazir (aka Phoenix) instead? That is a very interesting piece, but you hardly ever see it in western chess variants.

I now also succeeded in making the Interactive Diagram's AI play Blue Chip Chess. This was quite a bit harder than Refusal Chess, because of the obligation to move the Chip, and consequently the possibility to 'reserve' the target square of your best continuation move. This rule causes each FIDE position to have two scores: one for when you can place the Chip where it maximally hinders the opponent, the other for when you cannot do that, because the Chip is already there. So you cannot unconditionally ignore the best move in every position (like in Refusal Chess), and not even only ignore it when it is a non-capture (as captures cannot be hindered by the Chip). In any position you can be hindered by two Chip placements: when the Chip is blocking your own best FIDE move, or when the Chip is preventing your best Chip placement because the opponent already put it there. The search will have to figure out which of the two would be better, as well as which move is best. (Which can be a different move for each of the Chip placements.)

This all appears to work now. E.g. setting up a mate threat by Rh8-a6, Ng8-b6, Bc8-b5, h7-f6, d2-d6, f2-f6, Rh1-b3 (threatening 1. Rh3 ... 2. Rh8#), and playing a useless move 1... Ra5, Chip to a4, the AI (at 3.5 ply or more) indeed plays Rh3, and reserves Rh8# by placing the Chip on h8. (Of course black could have staved off the mate by playing the Chip to h3, keeping the Rook from the h-file. This would not work forever, though, because white can then play Rg4, Chip h4 to reserve his access to the h-file. So it would be better if black starts ply placing the Chip on h8 himself. This time not to reserve a FIDE move, but reserve the Chip placement he will need on his next turn. He can keep that up forever.)

You might have to append the URL with ?nocache=true to see the modified page rather than the version cached by CloudFlare. (Or click this link.)

@Fergus: Very nice that you can simplify your stalemate routine in the fairychess include file, but please don't do it in such a way that it breaks presets of others through changing the underlying behaviour of GAME code or Game Courier. If you do not maintain backward compatibility at all times, you are bound to break stuff.

So if you want an array that contains the legal moves as text rather than coordinates, and also contains special moves, just give it a new name, and use it by that name in the user code you want to simplify, so that existing presets that use the method you want to deprecate continue to function.

Ah, I see. That is 79%, which is way outside any statistical error bar.

Well, beware that I was not really playing Grand Cavalier, but was using Half-Maos instead of full Maos for the Cavaliers. It is not implausible that this made a lot of difference: no possibility for Cavalier back an forth movement.

Well, your images were still insanely large. I edited the article a bit to show them at a size that is more in line with what we have on other pages. For some that meant I had to shrink them by a factor four!

It is still not clear to me how turning of the Raven works. You say once in N moves. But are these moves of the Raven, or moves of the player to which the Raven belongs?

If they were moves of the Raven, I could implement it for the purpose of an Interactive Diagram as (hidden) promotions: there would be a number of different Ravens, one that can turn, another (Raven1) that cannot turn, but automatically promotes to Raven whenever it moves, a Raven2 that promotes to Raven1 on every move, etc. And then when the Raven turns, demote it to the Raven that still has to promote N times.

Indeed. So I used Half-Cavaliers instead of Cavaliers. These only have the four forward Mao moves. I already explained why. I don't expect that to affect the piece values much. (Except of course that it has a different value itself.)

And the Diagram here is really the same as that for Refusal Chess, except that it announces in advance what his second choice is.

Perhaps this gives away too much? Even though it is usually quite obvious what the best move is that you should not allow it to play, it might be better to randomly decide which move it will play automatically, and which it presents as an alternative.

Now that I am into refusal variants, it was of course easy to also make an Interactive Diagram for the simplest of those.

As for the interface: the AI just takes back the move you play when it wants to refuse it, printing a message above the board in red. The user can refuse the AI's move through a button.

Zillions-of-Games values the Cannon more than the Nightrider. The main advantage of the Cannon is that it can attack other pieces without being attacked back by them. The Nightrider can do that from a distance, but up close, many pieces it attacks could capture it.

I seriously doubt that not being able to attack from close distance (which is peculiar to this variant, where almost every piece has Knight moves) is a larger handicap than not being able to attack without a mount. The BN, RN and Equus Rex are worth more than a Nightrider anyway, so you could still attack those from close by when protected. And Nightriders have enormous forking power, from close by as well as from a distance, (and can also skewer pieces), so the Knight compounds (plus Queen) are very vulnerable targets for most of the middle game. A Cannon has very poor forking power, with only a single forward ride instead of four.

That an occasional mate position exists, which cannot be forced, has no impact on piece value at all. Even mating potential (i.e. the ability to force checkmate against a bare royal from almost any position) in general contributes very little to piece value. Because there usually remain enough promotable pieces around to provide such mating potential, and the main value-determining trait is how well the piece can support those on the way to promotion.

Without using zugzwang an Equus Rex cannot be driven to the edge so quickly, so I doubt that even Equus Rex + Cavalier can be beaten by Equus Rex + Cannon from most positions. The Cavalier would usually promote to Queen in time to launch a counter attack (and win easily). A Cannon alone would be powerless to stop such promotion. So statistically the advantage might even be with the player that has the Cavalier. With a piece stronger than Cavalier it would be very easy to prevent being 'cornered'; you would just aim the piece at the square where the attacking Equus Rex could take opposition. If it is not Cannon vs Cannon (which by symmetry should in general be a draw), the Cannon would probably be massacred very easily.

The file labels still seem to be positioned incorrectly.

There seems to be a conflict between the width derived from the FEN and whatever you import from the preset, which completely messes up the diagrams you posted.

I made a first attempt to make the Diagram play this. At the moment it still doesn't know the rule that you cannot leave the Duck where it is, although it effectively enforces that rule on the opponent, because its moving is triggered by moving the Duck.

This simplification makes it possible to treat it similar to Refusal Chess: the search just keeps track of the two best moves (in absence of the Duck), and only uses the score of the best if that is a contact capture (assuming the Duck would block it otherwise). In Refusal Chess you would always ignore the best move, assuming it will be refused. A refinement is that moves that have the same blocking square as the best move cannot become second-best (because then both could be blocked simultaneously). It only considers blocking on the first step of a slide, so it will overlook 'cross blocking' (where the Duck would block two moves going over the same square in different directions, and these happened to be best and second-best).

It will also overlook the possibility of 'reserving' your next move, as this cannot be done when moving the Duck is not mandatory. This will be hard to implement without making it very complex. Only moves with a single blocking square can be reserved, and it only makes sense to reserve a move that would refute the opponent's best reply to your current move. This would be an alternative method of 'disarming' his best move, which can be used when it is not possible to block that move. If it was blockable, so that both methods are available, it would make no difference which method you used, as both would make him fall back on his second best move. Unless the move you reserve refutes that move too. The chances that several moves are refuted by the same (reservable) move are a lot larger than those that you can block several independent moves (i.e moves that are not part of the same slide): you only need a hefty threat (like a check), and most of his moves are out. It must be possible to design a not-too-complex algorithm based on that idea.

Yep, good enough for me.

Adam DeWitt wrote on 2023-01-01 UTC

Do you want to update this page to remove the rule that the jumping Generals cannot jump-capture royalty?

Note: My presets for Tenjiku Shogi and Nutty Shogi follow the rules described in their respective Rules pages, so they will not be changed unless you update them.

Well, I don't want to have any discrepancy between what is in Wikipedia and on CVP, so I would then also have to change it in Wikipedia. To not run into an edit battle there, this would have to be done with care.

It is a consequence of the Betza parser not printing any error messages. In [W?fB] the f and B are conflicting input: f says you should keep moving in the same direction as the W step, while B says you must move diagonally. So it is an invalid specification, with undefined result.

What happens in practice is that the [...] notation is implemented by a pre-processing step that replaces it with the original XBetza notation using the a modifier. It thus uses the first step as the atom, tests whether a range-toggle is required for deciding it should be prefixed with a or ya, and takes the modifiers on the second leg. So [W-fB] becomes yafW, which is what [W-fR] would become too. The B or R are simply ignored (apart from detecting that they are sliding moves, so that the y will be prefixed). The preprocessor is not smart enough to understand directionality of the second-leg atom, nor that non-matching directionality would require addition or removal of an s to get the correct bend. It treats all second-leg atoms like they are K or Q, and you have to supply the s yourself.

Perhaps this can be improved one day.

Beside this, how do you do to embedd images of diagrams in your comments? Is there a trick?

Yes, there is a trick, and this is what the discussion is about. Just write a FEN of the position you want to show as part of your text, and surround it by 'tags' [ fen] and [/ fen] (without the internal space, which I just added here to prevent the word 'and' will be interpreted as a FEN of a 3x1 board).

E.g. [ fen]nqkrb/ppppp/5/PPPPP/NQKRB[ /fen] would give you:

Jean-Louis Cazaux wrote on 2023-01-01 UTC

To HG: Sorry to insist, I had no answer/reaction.

I think that it is not correct to change the name of the pieces of someone else's game, even for an editor.

Here Dog/Jolly Jumper/War Elephant have not been given by Betza.

If you don't want to remove those names in this page, you should at least insert a comment explaining for the readers who has named the pieces as such.

Well, this did not have a high priority, and I have been quite busy.

Although I admit that 'Jolly Jumper' was perhaps over-doing it, some of what you say here is not so obvious. Betza's contributions to the chessvariants community have been immense. But assigning names to pieces was not really his forte. And it is not uncommon at all for CVP editors to object to publication of new submissions because of improper naming of the pieces in their variant.

In the article at hand, Betza gives the move of the pieces, and refers to them by that. He does not give names, nor images. If, for the purpose of making a better diagram, I have to assign images, why not assign names as well. Especially in cases where the pieces with that move are well known, and do have established names. Like FD = Kirin, and NJL = NCZ = Bison.

Referring to the pieces like "FD (Kirin)" doesn't make much sense in the context of the Diagram, as the Betza notation for their move is already in another column of the piece table. I also do not list the Archbishop as "BN (Archbishop)".

So I will probably change the names to Kirin and Bison (is there a commonly used name for KA?), and perhaps add the remark that the diagram calls pieces by their usual names.

I would prefer that too.

OK, I moved the SVG sets that I created recently to /graphics.dir/svg/magnetic/, /graphics.dir/svg/motif/ and /graphics.dir/svg/utrecht/. The XBoard SVG pieces were in /graphics.dir/svg/xboard/ already. I made an index page with an overview of the Utrecht SVG set.

OK, I created a Duck Chess page. I think it is ready for publication, but even though I am an editor I consider it bad form to publish my own articles. So perhaps another editor could judge it.

Is there a technical limitation that tags should start with a letter? If not, why not just have tags 10x10, 10x8 etc.?

I thought about adding a Duck Chess article. I even uploaded a Duck image with the XBoard set. But the Interactive Diagram is not able to play it yet, so I deferred that plan to when I had an idea for how to adapt that.

BTW we have an article about a very similar variant, called Blue Chip Chess.

Almost all pieces from the 'small' set are now available as SVG, in /graphics.dir/utrechtSVG .

Perhaps we should take the opportunity to better organize the file system? I think it would be better if all SVG pieces resided in a directory /graphics.dir/svg/<setname>/ , rather than just slamming a suffix SVG on the setname. Once the images are in common use it would be too late to do that.

One thing I will note is that I no longer recommend editing the $pieces array. This is a bad practice, and I regret coming up with the idea. I now recommend the use of aliases as best practice.

IIRC the possibility of the $pieces array was created because users wanted to combine piece images from different 'sets' (perhaps even standard sets supplemented by images uploaded by themselves to the /membergraphics/ sub-tree). Aliases don't do that for you; they just allow you to rename the pieces in a given set.

It is indeed inconvenient that expanding a set is done by execution of Pre-Game code. But the alternative, asking an editor to create a new set including the desired extension graphics was even more inconvenient.

It would be good if there was a way to assign arbitrary images (i.e. anywhere in the public_html subtree) to to piece labels without invoking GAME code. Just like you can specify a FEN for a preset, and the corresponding position will already be displayed on the preset's page even before you start running the preset.

So any posting of new default color schemes is completely inappropriate without first establishing a DEFINITION OF PROBLEM to be solved and a PROCESS for how changes are to be submitted and results are to be measured.

Well, since it seems that I am the one who raised this issue, let me formulate a formal definition of the problem:

I think the yellow/green/blue board colors that are the defaults of the Diagram Designer, although excellently suited for the main diagram in an article, are are to 'loud' for embedded diagrams in a comment (for which my imagined use case would be mainly to illustrate issues in specific positions). With this I mean they would attract more visual attention than they deserve, and thus would become a distraction.

Since we are creating a new feature here for general use, it seemed wise to give its design some serious thought rather than just slamming something together that happened to work. Color schemes were one of the aspects I identified as possible target for optimization. Note that in the context of the 'instant diagram' people are much less likely to customize it than when they use the DD through the design interface in its article, so defaults become a more important issue.

I would prefer somewhat softer colors for the board.

BTW, I consider the khaki/smoke theme presented in Fergus' latest posting excellent.

As to the process: it seems to me this is well under way. Everything said so far has been only a proposal, and all editors that have an opinion on this matter can chime in. I can add that w.r.t. other proposals I have made for improvement of this website, there has been disappointingly little interest from other editors in those.

I will anticipate the response: these changes are forward-only changes and have no effect on the existing content.  Ok, while there is truth to that, the argument is insufficient.  The only reason this forum has any value, (the only reason people are reading it), is because of the established content.  And it only continues because a community drives it forwards.  Almost no one would be here if it wasn't for our foundation.  We stand on the shoulders of giants.

I am not sure what point you are trying to make. Why would creating new features diminish the value of this website? Why would the fact that designing it in a certain way would be the best way to do it be an 'insufficient argument'? I would say it is the only argument.

Betza's Nine-Board Chess:

Indeed, automatic scaling works! So it seems we now have a trouble-free 'instant diagrams' feature.

BTW, I could not find a 2-letter code for the Nightrider. (Which I only use here as a substitute for the Rose, which is a circular Nightrider, but for which we don't have an image yet.)

For the contrast between blue and green, I noticed that it depends very much on the viewing angle on my display: near the bottom the blue is lighter and the greed darker, and it looks pretty good. At the top, however, their brightness gets similar. If any changes are needed, perhaps the green should be made a little brighter (perserving hue, i.e. multiplying R, G and B by the same factor).

I started working on the 'small' set:

@Fergus - In case you missed the last edit of my previous comment:

Can you have a look at this ScriptAlias issue?

You can also include extra parameters after the fen code, just as you would in a query string, because it's just going to plug your FEN code into a query string.

A smart and convenient trick. This means we really don't need the 'cols' and 'set' shortcodes. The latter doesn't seem to be working anyway.

The purpose, however, is to make it as easy as possible for a noob user, who doesn't know the ins and outs of the Diagram Designer, and probably doesn't even know it exists. We cannot expect such users to know the 'cols' keyword, or query-string syntax, the 'set' keyword or the names of the available sets, etc. So it is important that we invoke the Diagram Designer with the most useful default values. To which we then append &code= plus the string between the fen tags. This would still allow 'power users' to overrule the defaults by adding parameters at the end of the FEN in query-string syntax, as in case of duplicat specification of a key, the one encountered latest will prevail.

set - I think auto-alfaeriePNG35 would be the best default here, (or an equivalent overly large set forced to display at reduced size) because:

• It has the largest number of pieces.
• It is small, allowing representation of large boards without problems.
• Orthodox pieces use their conventional icons, which each chess player will recognize.
• Pieces can be indicated by {name}. Apart from the orthodox pieces there are no universal single-letter abbreviations for chess pieces, and the alphabet is not large enough anyway, so non-obvious abbreviations would be more the rule than the exception. Users would know that they wanted a camel, giraffe or rhino, but even if these had letters assigned to them, these would not be C (cannon), G (griffon) or R (rook), and the users would be clueless as to what letter to use.
• For compactness the orthodox pieces and most-common fairies (Archbishop, Cannon, Elephant, Griffon, Marshall) can also be indicated with a single letter.

cols - This still should be automated. I propose to treat a setting cols=10000 (or some other large value that can never be used in practice) on the Diagram Designer as a special value, which would derive the true value from the length of the first row of the FEN in the code parameter. This would not interfere with the normal processing during the first row because it will be large enough to never make the board 'wrap' to the next rank automatically. And when the first slash is encountered, before padding the rank with 'holes', it can set $cols to the current length of the rank if it was 10000, and then proceed as normal. The fen shortcode can then invoke the DD with the parameter cols=10000.

colors - This is more a matter of taste, but I feel that the default colors are a bit 'loud' for embedded diagrams that only serve as illustration for what is explained in the surrounding text. I would prefer 'softer'colors (with a somewhat lower saturation), and a less prominant board margin, like

Other proposals are of course welcome.

There must be something in the Apache .conf file that blocks access to this directory. I have no experience with the Apache server (on winboard.nl I use lighttpd), but some googling suggests this file should be called apache2.conf. I could not find it using an ssh connection, so I guess it is in a part of the file system that is not accessible to 'chessvariants' (/etc/webmin/apache/ ?).

Not that it is particularly important to place fen2.cgi in that folder. It would be fine anywhere, as long as CGI files are executed by the server there. This probably also requires some changes in the Apache config file, as by default CGI (or PHP for that matter) is switched off.

[Edit] Could also be /etc/httpd/conf/httpd.conf .

[Edit2] I see you already tried that...

[Edit3] There is a line

    ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"

in the httpd.conf. Could this be the problem? Perhaps the /var/www should also be changed to /home/chessvariants/public_html here? Or perhaps safer: the /var/www/cgi-bin directory could be made writable for user 'chessvariants', so we can all put files like fen2.cgi there, without running the risk to enabe all kinds of stuff that we no longer know what it does.

Could be just a matter of rounding. To the eye the 'non-original' colors that are left look indistinguishable from the original square colors.

The convention is that X extends the longest dimension of the preceding atom. So NX makes (5,1) from (2,1), not (2,4).

And yes, I would call a word processor that gives me boldface when I ask for normal, or proportional spacing when I ask for fixed spacing sabotaged. Such tools should do as the user asks, not as their author pleases.

By rendering on grey you will replace the transparent part of a pixel that was only partly covered by the object gray. While for rendering on a light (say white) square it should have become white. So the pixel gets darker, creating the illusion that the blackness of the object covered a larger fraction of the pixel, and thus that its boundary moved outward. But it doesn't move outward where the boundary happend to coincide with a pixel boundary, and the adjacent pixel will just be pure gray, later converted to transparancy. This is what makes the percieved biundary ragged.

And white / black / grey even is a favorable example; when colors are involved you also get hue differences.

Does the showpiece.php say in the header that the Content-Type is image/svg, rather than image/png?

The Diagram Designer creates a single graphic image. It does not use tables or CSS to place image files on top of another image. So, there is no way to use height and width of IMG tags to adjust the size of SVG piece images in the diagram it produces.

Sure there is. You should just render the entire image twice (or 5 times) the size you want it, and use the width and height attributes on its image tags to scale it back to the size that was requested. Some comments down I posted a whole-board image generated with the Editor for scalable Diagrams that used that technique. Let me post it again:

But it should become easier to find cut moves when the evaluation is constant. If all leaves would be evaluated as 0, the first random sequence of moves will be the PV, and every move you randomly pick in a cut node would immediately be a cut move.

And if you make all board squares black, you would have the ultimate solid borders, which extend all the way to the square edge.

But if you want more solid outlines than a piece was designed to have, it would be better to make the stroke width an adjustable parameter of the Diagram Designer, just like the fill color. This is trivial to do, by doing a text replacement while the image is still SVG, before rendering it.

What is the problem with a high branching factor? You can search less deep in a given time, of course, but that also holds for any opponent.

With alpha-beta the EBF only grows as the square root of the typical number of moves. So even if the latter is 6 times higher, the EBF would only go up by a factor 2.5.

The images in Jean-Louis last comment do not show up for me on an Android tablet using the Samsung browser. But when I paste their URL directly in the address bar I can see them. It could have to do with the fact that they are on a http site, while CVP is https. Depending on browser security settings links to http on a https page might not be valid.

Anyway, what is seen on Safari is very strange indeed. The Knight part is totally blurred.

To me it looks OK. Some of the horizontal Rook lines are antialiased in a bit of an unfortunate way (so that a gray edge results), but if you squint so that you cannot resolve individual pixels this disappears (as it should).

Well, having board other than 8x8, or piece IDs A or C, is also not compatible with the FEN spec. One has to do some amount of generalization to make it useful for variants. The 'castling field' in fact already is a field that indicates virginity of pieces. But only of those for which it matters, because under orthodox rules only castling is affected by virginity. (One could argue about Pawns, but the double-push is usually explained as a location-depended move rather than an initial one, as evidenced by the rules of Crazyhouse/Bughouse.)

I think it would be bad to have two fields that basically serve the same purpose. In Shredder-FEN notation the letters in this field already identify the piece, so there is no need to make separate fields for Kings+Rooks, Knights, Bishops and Queens. It seems much better to have a unified virginity field.

Likewise, the the e.p. field indicates the last-moved piece, in positions where that matters. So it would be logical to use it for any other type of last-moved piece as well.

I agree that leaving in the right of a non-existing piece is perhaps a bit contrived. But how about the other option: indicating an undetermined right by X? Then you would not have to look at the board. An X in the field means both Bishops are virgin and can convert. One gets captured without moving: the X remains, to indicate all remaining Bishops still have choice. If one moves, the rights disappear altogether when it converts, and change to indicate the file of the Bishop that now must convert.

If you have both converting Camels and Bishops, just use X for the Bishops and Y for the Camels. (Or more generally, adopt the convention that X indicates the outer-most piece type, working your way inwards when stepping through the alphabet.)

... the fact that the rankings could refer to friendly pieces is a rather dubious piece of evidence for allowing jump-captures of royals.

The point is that it makes no sense at all to make a rule that forbids jumping over an enemy King, while allowing its capture. For this reason I always considered the fact that the King was mentioned in the general's ranking as evidence that it must be there for forbidding its capture. (Even though this caused a very nasty inconsistency in the rules, as capture of generals of equal or higher rank are allowed.) This reasoning was flawed, however: the rule could also have been added for preventing generals to jump over their own King. That it would at the same time forbid jumping over the enemy King would not be relevant, as no one in his right mind would want to do that anyway.

The evidence in favor of allowing capture is that the King appears in the ranking without further comment, suggesting it is treated as its rank would suggest, but not special otherwise. The evidence to the contrary now seems to have evaporated. The weakness you mention can in fact be trivially defended; no AI is necessary to to find that, and the 'quick attack' was standard theory from the very beginning. Its main line doesn't provide a very large advantage, though, as it doesn't win in just a few moves, and when sente runs out of steam, gote can mirror its play for a counter attack. This also has been known from the early days.

The smothered mate indeed is the main theme of all openings. It is the only way in which the jumping generals can combat a Fire Demon, and makes Demon sacrifices for 2 or 3 generals (including the GG) playable: in the end the side with the generals can force the opponent to give the Demon back. Otherwise the value of a Demon is close to infinity. It is really a very interesting game that way, and certainly doesn't fuel any reasoning of the kind "they cannot have intended this".

Unfortunately this is not so easy, because BadZone only gets the locust squares passed. Not the pieces jumped over. The non-destructive intermediate squares are not part of the internal move representation. But I suppose BadZone could be made such that it scans the board for high-rank blockers along the path from origin to destination itself.

BTW, I have played Tenjiku at high level according to 'modern' rules, where the King can be jump-captured. To my surprise this was very playable, and not too unbalanced. If you know the correct opening lines. Which my Tenjiku engine was able to determine.

In addition I came to realize that the King has highest rank does not necessarily have to refer to capture. Originally I thought that outlawing jumping over a King only would be pointless, as you would never be interested in doing that when you could also capture it. But it could also refer to your own King. So the evidence that historic rules did not allow King capture is starting to get flimsy.

Thankfully, this problem can easily be solved by writing the missing legs separately, yielding B(cpaf)2cBcafpafcBpafcafcB.

Ah, OK. This is what I vaguely remembered when I mentioned that combining destructive and non-destructive modes might cause problems. The Betza parser therefore separates those. But since this was written at the time only a single locust square could appear in the move encoding, it doesn't do a very elaborate job at it. The AI's move generator could perform this separation while generating; after every leg it calls itself recursively, for the remaining legs, and it could just call itself two times: once with and once without locust square. (It might not do that, though, because there was no need, as the parser already ensured that the combination would never occur.)

I will have a look at this; it must be possible to suppress the separation by the parser when NewClick is being used, and make the AI's move generator do it in that case. Up to then you indeed would have to do the separation yourself. Or at least part of it, keeping in mind that the parser only separates one of the legs. So you could write mpcafcafcBmpcafpafcB to specify all 4 combinations.

And no, paf should not be equivalent to mpaf in any case. paf must hop, mpaf is completely ignoring the square, 'seemlessly' gluing the legs into a longer leap. mpaf should not be used on slides: logically mpafB would mean mafBpafB, where the first term is the exploding version of B (a 'degenerate hook mover'), and pafB what Betza originally wrote as pB. So BpB would be the recommended notation.

@Fergus: Would it be a good idea to rewrite the SVG renderer (which now is a compiled C program) as a PHP script that invokes the Linux command rsvg to render the SVG piece at the requested size and possibly the requested color (all specified in the PHP arguments), and relay the output to the client? If rendering a FEN rather than a piece is requested it could return a HTML table with in each cell a URL to itself with the proper arguments to display the piece there.

@Greg: I believe you had a script for rendering the entire set of SVG pieces as PNG. Would it be an idea to run that at size, say, 250x250, to create a zoom-friendly piece set in an alfaeriePNG250 directory?

(Note that I added some pieces: mastodon, sabretooth, bat, scorpion, owl, plane, thief, general, 3 orientations of spearmen, sissa and diplomat.)