Comments by HGMuller

Is mp something different than the moving and hopping modifiers combined? Does mpafsK mean the same as N? If so, how does it work?

I now elaborated on that, and hope this will make it clear.

I don't follow what the x modifer does. An example would be helpful.

I think we have to discuss presentation strategy here. The list of modifiers below the diagram also serves the purpose of a quick reference guide, which can always be kept in view by people who are using the sandbox diagram. Elaborating on each of them, explaining examples, would easily quadruple its size, so that it becomes difficult to use for that purpose. I do in fact give an example for x, (mNxaN) but I don't say what it is. (It is in fact the Knight of Knight-Relay Chess, which moves (without capturing) like a Knight (mN) and induces Knight moves at a distance of a Knight move (xaN)).

Would it be an idea to add an extra section where each of the examples mentioned in the 'quick reference' are discussed in depth?

It's not clear how FyafsF is supposed to describe the Griffon. Should the second F be an R?

Did you read the 'more about a' link in the 'quick reference'? It opens a box that should make this clear. I presented it this way, because most people wanting to use XBetza (e.g. for making an Interactive Diagram for their variant) would not need the complexity of multi-leg moves, and be completely satisfied by combining Knights with Bishops, or perhaps make a HFD. Even the need for directional modifiers is quite rare (outside Shogi). Not many people use bent riders, bent lame leapes, locusts, bifurcators, pieces that induce moves in other pieces, or displace those...

I don't want to burden the 95% of people with stuff they don't need, and deter them by it. The a is a highly advanced feature of XBetza, almost never needed.

But it would of course be bad if I hid it so well that people will miss it alltogether. The more-about-a box was actually a remnant of the old sandbox diagram I posted as a comment to the Betza article (since then pushed far in the background noise). In a real article I have more space, and perhaps I should move most of what is now in the box to the preceding section about XBetza above the sandbox, or a new section about multi-leg moves. (With an initial warning that people who just want to do basic things can skip that section.)

To answer your question: The yafsF part of FyafsF means the move starts as F to an empty square, to fork there (y is "move and continue as slider"), and then continue in the (relative) fs direction, i.e. as a Rook. That is a Griffon, except for the F moves. (Because a Rook makes at least one step; it cannot null-move.) So the latter are slammed on separately.

I'm not familiar with Bifurcators, and other readers might not be too. An illustration to how the piece works or a link to a page on this type of piece would be helpful before describing what gabyabsR  is doing.

Bifurcators are an invention of Mats Winther. But when I looked for them, I could not find any mention of them in the Piececlopedia. (Do we have a search function here?) I know Mats describes many variants on his own website, mostly based on very innovative piece designs ('Catapults' are another invention of him).

Note, however, that the sandbox diagram is available as an interpretation aid: to know what it means you only have to copy-paste it in the Betza move-entry, assign it to a piece, (e.g. 'betza2'), and then click on the name of that piece to summon up the move diagram. As this is some kind of hopper, even the move diagram will be interactive for pointing out the hopper's mount by hovering the mouse pointer over a square in its path (or touching that square on a touch-screen device). That would make it obvious what the piece does; as they say, a picture is worth a thousand words.

One reason for giving the examples was to provide people with something to try out the sandbox diagram with something non-obvious.

[Edit] I now added a section at the end, which discusses the examples of the more complex pieces in detail.

Problem is that it still assigns zero value to the Joker, because it determines piece values at the start of the game, when the Joker has no moves yet. Not sure how to put a value on it; it seems to depend a lot on what the opponent has. So some sort of average of the opponent piece values. But it should be a weighted average, as stronger pieces tend to move more frequently than weaker pieces. And of course it should be weighted by the number of each type the opponent has as well. So something like SUM(over pieces) value*value/SUM(over pieces)value.

OK, I just uploaded an updated script that fixes that.

I did post an Interactive Diagram for Gross Chess. You can simply look up that comment, click 'View' to see it in isolation, and then ask your browser for the 'page source' to see the HTML. Then you will see the diagram definition between the <div> tags and the supporting JavaScript for handling the special promotion rule between <script> tags. You can just copy that JavaScript. You might have to adapt the numbers a bit to bring it in accordance with what promotions you want to allow where, but that should be easy, as it is a very straightforward routine. Programming in JavaScript is a hundred times easier than writing 'game code'...

As to the shuffling: you would have to tell me by which rules you want to shuffle.

Well, it estimates about 450 for both Kirin and Lance! (to compare: 480 for Bishop.) It differs a bit each time, as the estimation process involves random sampling.

Just for my understanding: This 'display_comment' is applied to anything that is displayed from the database, or just to comments in the comment section?

I guess that, strictly speaking, I should have the betza.js script add tags to the URL of the piece images it uses in the diagrams it generates, if it is to use ther most recent version of thos images always? It generates these image names itself, by concatenating graphicsDirectory, white/blackPrefix, image root name and graphicsType extension, and I could have it append another "?a=0" on that. (The standard image sets like Alfaerie of course will hardly ever be updated, but if people would use their own uploaded piece images, it could be a problem.)

The Diagram does have a shuffle option now. But to make that work you should first place the pieces in some 'reference position', and then indicate in a shuffle option which piece types you want to permute. (It can then see the set of squares that should be involved in the shuffle.) Depending on whether the King has a castling move defined on it, the shuffle will respect its placement between the corner pieces during the shuffle, or not. In your case you have no castling, and there would be no restriction to the King placement.

In Chess960 the reference position would be FIDE; from this it would then know that the castling partners are Rooks, and that the King must remain between the Rooks. BTW, the Diagram does not implement Fischer castling; no way has been devised yet to indicate that in XBetza; the On notation would mean something else. Perhaps OX ? But as far as the shuffling is concerned, you could say shuffle=N!BRQK, where the exclamation point before the B indicates Bishops should be equally distributed over shades. When you ask it to do impossible things the results will be undefined.

I don't know whether this shuffle option satisfies your needs. A straightforward enhancement of it could be to allow multiple 'shuffle groups' (say comma separated in the shuffle option), where it would then apply the same shuffling as it does now to each group independently. (They had better be non-overlapping groups then, or the results would get statistical bias.)

And yes, your King move seems correct. But you should be able to see that in the XBetza sandbox, when you ask for the move diagram.

To see diagram source in a comment I usually click the 'View' link at the bottom of the comment to see it in isolation (so that I don't have to look for it on a page that contains lots of other stuff), and ask my browser to show the page source. There will still be a lot of stuff before it for the menu bar, and all the adds, but you can always use the browser search function to look for 'idiagram'.

1. I still have not figured out how to make the squares, brouhaha

Just define a first piece with name 'hole' (the ID, move and image fields will be ignored), and a list of 'starting squares' where you want the holes to be. Then you also specify a piece to start at one of those squares. All holes act as brouhaha squares, also during the game: you can place pieces on them, and when you then move them away they revert to black.

2. It may be a nice feature to display the brouhaha squares in a different colour

I will think about it. Perhaps dark grey.

3.I don't think the shuffling works in this particular case (please read the article) but probably a javascript code is possible to do. Unfortuneatly I don't know Java script so if you can help me here I'd really apreciate it.

Well, this sounds more like placement chess with some restrictions than like shuffling. The logcal solution would be to put all the pieces in hand (except those that have fixed location, like Kings and Rooks). For easy placement just display the piece table permanently next to the board. You can do that by defining in the diagram parameters satellite=apothecary , and then somewhere on your page put a HTML element <table id="apothecaryTable"></table> . The Diagram script will then put the piece table there, rather than collapsible under the diagram, and people can directly drag the pieces to the Diagram.

OK, I see that my trick did not work for swapping b and d, as these are same shade, so that the B must get automatically to opposit halves, and the : adds nothing extra. I changed the meaning of : now to explicitly mean "mirror-image location", and adapted the Diagram script for that. This should make your diagram work as you have it, with the updated script.

I think caching again is broken on this website. I uploaded a new Diagram script, but when I read it back from the website, it shows the old text. Only when I suffix the URL with some random suffix, like ?t=1234, I get to see the newly uploaded text.

So this is what you can do as a work-around too: suffix the URL to betza.js in your comment to make it betza.js?nocache=true , to make sure it will use the new script. You still would have to flush your browser cache. When I tried the current script locally on your diagram, the shuffling works as it should.

BTW, note that when you specify symmetry=mirror (as you must, to preserve vertical symmetry during shuffling), there is no need to mention the location of the black pieces, as the Diagram would automatically add those. So you could leave out the double comma and everything behind it, even for the holes.

Well, I would like to request then that what I have written in the "What's new" field to be made into a short description for all the pages I authored that now say "Missing description".

The Diagram's AI implements rules of not passing through or out of check as a generalized en-passant capture, where in the case of a royal any piece would be allowed to make the capture through its normal capture moves. So whether moving through check is allowed can be indicated in the move of the royal by having it create e.p. rights. For castling this is implied already by the O atom, also that the starting square itself becomes an e.p. square, so that castling out of check is also illegal.

XBetza uses the n on a stepper atom (W, F, where non-jumping has no meaning) to indicate it creates rights. On sliders that repeat such steps I now create them only at the end-point of each step. So that nQ on a royal means you cannot move through check, but you can move out of check. Which is in general what you want. That you also create rights where the piece ends up doesn't matter, as the piece could be captured there anyway. If it would automatically also create rights on the starting square of a slider leg, it would be rather cumbersome to describe the case where you want to allow moving out of check; you would have to make it a 2-leg move, first making a single step without creating rights, and then continue as a slider (through a range toggle), a sort of 'rectified' Griffon, yafnK. So I opted for creation of rights at the target square of a step, also for single steps.

But for Apothecary Chess you want to have this on larger leaps, where the n cannot be used for this purpose, and you want it on the initial square. The solution is very cumbersome: you would have to break up the N and C moves into King steps seamlessly glued through mp modes, and furthermore make an extra back-and-forth step to the starting square to make the step that arrives there create the e.p. rights, as a step that leaves it can not.

Perhaps I should just adopt the convention that initial moves on royal pieces automatically create the rights at the starting square, so that they can never be made out of check. This is usually the rule. The problem is that you can then never indicate that you do want to allow it out of check. Another possibility would be to double the i modifier for this purpose, as an indication you have to be 'extra virgin' to make the move, i.e. not even checked.

[Edit] For now I have disabled all i moves on a royal piece that is in check, in the AI. (It doesn't make a distiction based on the number of i.) I also changed the handling of e.p. capture by the AI somewhat: at any square along its path the piece checks whether it hits a square for which e.p. rights exist. If they do, and the move can capture e.p. has e mode, or c mode when the last moved piece was a royal, it allows the e.p. capture irrespective of the square occupant. For e.p. on non-royals you better make sure they never generate rights on a square occupied by an enemy. For royals, the captures are never really made, but as soon as it is detected they are possible the line terminates with a winning score, as it would mean the royal gets captured. This allows for instance forbidding hopping over enemy pieces that are protected, as is needed in Metamachy.

Sissa is a compound of rook and bishop but its move is not disjunctive, it is conjunctive.

Conjunctive = A and B

Disjunctive = A or B

Am I right?

I have never seen the word 'compound' used in sequential meaning; I would say the Sissa is an (isosceles) hook mover. And I would not say the Tai Shogi Hook Mover is a (conjunctive) compound of two Rooks. The word 'or' usually implies 'and', and if you consider this operations on the move sets, the 'conjunctive compound' of R and B would have no moves (as B and R have no moves in common), and the conjunctive compound of K and R would be the Wazir, etc. There doesn't seem a case where this cumbersome way of describing more elementary move sets is useful, as they tend to all have simple names of their own. Note that the Sissa can neither move as a Rook, nor as a Bishop.

It seems to me the addition of 'disjunctive' serves no other purpose here then sow confusion in a case that otherwise would be correctly understood with 100% certainty.

Some sections are very poorly formatted; even the images are just part the lines. And division into paragraphs is sorely missing in a very long text.

Yeah, I know. I have to be very careful never to switch off 'Source code', once I have started to do advanced things. Or they would all simply disappear. Embedded JavaScript disappears completely, Diagram definitions become line-filling text, the 'id' names of HTML elements are all forgotten...

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.

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.)

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.

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...

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!)

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.

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.

On my desktop monitor: 1680 pixels.

I did read the tutorial How to Enforce Rules in Game Courier (2016), but some things where not entirely clear to me:

• When it discusses the code for promotion in the Post-Move code, it mentions how to reject a move R a1-f1; Q-a1;. I don't understand the Q-a1. Must pieces be promoted on their starting square? Why not on f1? Are the moves also evaluated right to left?
• Apparently the input format is such that promotion is written as a separate, extra move. How is such a sequence of moves handled by the basic input system before the Post-Move code is invoked? Their seems to be no provision for multiple moves, just origin, dest, moved and old. Yet you can test the board (spaces) to check whether promotion took place. Are all moves of the sequence performed, and do the variables only convey the parameters of the last move that was processed? Do promotion 'moves' alter any of these variables?
• What happens when you promote an empty square? Is that equivalent to dropping a piece on that square? (That would be useful e.g. for pieces that swap location with other pieces.)
• Can you 'promote' something to an empty square?
• In several places it is mentioned that the Post-Game code is executed only after all moves have been performed. What does this 'all moves' refer to? Normally (ie. for non-promotion) there would only be a single move to perform, right? Namely the one the user entered.
• What is the convention for entering non-implied locust captures, like for the Chu-Shogi Lion? Is it capture followed by a move to the destination, or a direct move to the destination followed by promoting the locust victim(s) to empty squares?
• Should automatic locust captures, such as for the Ultima Long Leaper, be explicitly specified, or should they be automatic side effects of the move to the destination?

No, you can add a new piece to an empty square, but that would not be called promotion.

I meant: would it be possible to clear a piece from an occupied square by 'free-dropping' an empty square on top of it (e.g. by entering @-f1). And come to think of it: the code that checked the promotion just looks whether the piece at 'dest' after the move is still 'moved'. But what if someone would have really entered the typo R a1-f1; Q-a1; ? Presumably that would leave a Rook at f1, so you would not catch that. Would it have free-dropped a Queen at a1 after the Rook moved ('fertile Rook')? Or is there some intrinsic test on the input that enforces that promotion moves can only free-drop on dest? (Probably not, because that would make the mention of any square redundant.) Because the promotion move doesn't set any variable similar to dest, it isn't clear to me how you could test whether free-drops go to an allowed square.

BTW, some variants allow only promotion of a piece that was lost before, and in those it can make sense to collect the captured pieces in a separate area (without color flip), and move them from there to effect promotion.

I have never programmed Chu Shogi, and I'm not sure what a locust move is.

'Locust capture' in general is capturing a piece on a square you are not moving to. Like capture in Checkers, or e.p. capture in orthodox Chess. But in these two cases the capture is an implicit side effect of the move. So the Pawn subroutine can recognize e.p. capture, and automatically remove the victim, without the user having to enter any additional moves. (I guess promotion in Shatranj or Makruk could also be handled that way.) The problem arises when the capture would be optional. E.g. in Odin's Rune Chess a Forest Ox moves and captures like a Knight, but can in addition remove one other enemy piece adjacent to its destination. So there you would somehow have to indicate whether you want to do that, and if so, which of the (possibly eight) adjacent pieces. F c3-e4; @-d5; could be a suitable notation for that, if such a thing were allowed.

OK, so I could allow moves and captures for the first move, and promotions, suicides and freedrops for the second (and perhaps third) move, depending on whether the game needs those. (Freedrops would only be needed when there participates a piece that uses an 'unload' modifier in its Betza notation, and suicides only when there are multi-leg moves that can capture on a non-final leg.)

The question is how the presence of suicides or freedrops in the input move is relayed to the post-move code so that it can check for their legality. For promotions it could just check 'space dest', because the basic input system already enforced that these could only alter the piece that just moved. But the freedrops and suicides could strike anywhere. Is there a variable similar to 'dest' that tells which location they altered, or must I make a copy of the board before the move to compare to afterwards, to see if anything was changed, and what?

Is the post-move code run after each move in the sequence, and then the post-game code at the end? But then I don't understand how the code in the tutorial can work, because promotion happens only in the second move, so that the first move should be flagged as illegal when you run the post-move code after it, because it still has the Pawn on last rank.

OK, that is interesting, because at the moment the Diagram also has a limitation that it cannot handle more than a single locust victim or unloaded pieces. That is a limitation I was hoping to remove in the future, though. (The Lion Dog of the large Shogi variants can make up to two locust captures, in addition to a normal one.)

Just an idea: wouldn't it be possible to have a move generator generating the move strings for all pseudo-legal moves in the Pre-Move code, and have it do a string compare for each of those with thismove, to see if one matches? If there is one, it can just allow the entire move sequence to be performed without ever having to look at the origin or dest of any of the individual moves. The Post-Move code then would only have to test whether this left the King in check. For this it would basically run the same move generator for the opponent, except that it did not generate strings to compare, but tests whether any of the moves captures the King.

Pairs of coordinates are usually sufficient to describe a move. It would be very useful if there could be an arbitrary number of coordinates, though. It could then also describe moves that need more than two mouse clicks to be entered. The JavaScript could run through the list after every click, to get the sub-set of moves that start with the clicks that have already been made. (With only simple moves, after clicking a piece, this would leave you with the moves of that piece.) It could then highlight the 'next in line' click of each of those, so that the user knows which squares he can click next. If all clicks in a move would have been made, and no other moves start with the same sequence of clicks, the move can be considered entered. If there are still multiple options we can adopt the convention that one has to click the last-clicked square again to terminate the move without waiting for more clicks. E.g. for optional locust captures the second click could be on the locust victim, and the third click could be on the final destination.

Is the issue that to retrieve a position, each time all moves of the entire game have to be replayed? Even if this is the case, it would surprise me if it would take any measurable time at all. Chess engines typically search on the order of a million positions per second, generating all moves in each of these positions. Even if a scripting language would be 100 times slower, and a game on average has 100 moves, it would still only take 10 ms of CPU time to retrieve the game.

But for moves that are already part of the game, there isn't any reason to check their legality at all. This should have been done while they were first entered, and added to the game. Only newly submitted moves would have to be vetted. Older moves can simply be executed as stored. The only problem would be automatic side effects. But typically only very few moves have those. But locust captures or unloads generated from the Betza descriptions would never be automatic; they would always require full specification of the side effect in the input move. So the automatic side effects would remain limited to e.p. captures and castlings, which can be handled in the conventional way.

Well, I will definitely start with something simple. But I don't want to paint myself into a corner from the start, so some advance planning of the strategy that will eventually be adopted seems useful.

The problem with using $prev is that it doesn't seem to offer any hope of expanding the capabilities to more than 1 move + 1 explicit side effect, something I would still like to do in the future. It would be possible to specify the side effects before the move, but that mostly subverts the effectivity of the allow command, as to allow both simple moves and combinations suicide + move one would have to allow moves + captures both as first and second move, and then it would not weed out cases where the user typed two normal moves. I could use the explode trick on every move on the off-chance that the user might have entered a move with a side effect, but the store and restore this requires to not mess up the game state must also be an order of magnitude more expensive than just testing pseudo-legality of a given move.

When I would specify allow moves 1 captures 1 promotions 2 freedrops 2 suicides 2 suicides 3 , I could test whether the input line did specify side effects by something like if != dest null and origin: . For simple moves moved and origin are reliable, and I could run the move generator only for the moved piece. Whether the move is compared in coordinate form or as text string really should not matter much. For composit moves I would either have to recover the moving piece through the explode trick, (because I don't know how many suicides followed it, so I cannot rely on prevorigin either), or generate moves for all pieces to see which one matches the thismove string.

It would have been very helpful, efficiency wise, if it could be tested whether the Pre/Post-Move code is run for a new input move, or just for a move that was already accepted as part of a game, and is now played to set up the current position. Is there a variable that holds the current game length? I suppose it would be possible to update a global counter in the Pre-Move section (initialized to 0 in the Pre-Game section) to keep track of the move number. If the move is not the last move in the game, the Pre/Post-Move code could be made to suppress any unnecessary (pseudo-)legality testing. In particular, composit moves would not have to be tested, as they would be guaranteed to not have any implied side effects (the very reason for them being composite being that they explicitly specify all their side effects).

[Edit] is this a matter of comparing movenum with mln ?

I'm thinking of providing more information, but it requires an array, and I'm still looking into how I might handle that.

It would already be very helpful if the 'origin' and 'moved' info was always available for the first move of the sequence. Without that, the following code seems to do what is required. (I did not want to use the Do Not Include checkbox, as the store / restore is only needed on the latest move of the game, while on all other moves it would come in handy if it is automatically performed.)

The underlying assumption is that implied e.p. captures and moves that generate e.p. rights ('double pushes') will never have other (explicitly specified) side effects, and will thus be entered as simple moves. (For castlings XBetza already guarantees that, but it is in theory possible to specify rights-generating moves that would also make a locust capture. It is hard to imagine any Chess variant would ever have that, though.)

Pre-Move:

if != mln $maxmln:
  store;
endif;

Post-Move:

if == mln $maxmln:
  // last move must be tested for legality
  store resultpos;
  restore;
  if == dest null or not origin:        // move is composit
    set mvs explode chr 59 thismove;    // split it
    eval join "MOVE: " trim elem 0 mvs; // get origin and moved of first part
    restore;
  endif;
  set legal false;
  set task 0;                  // specifies what subroutine genmoves should do with the generated moves
  gosub genmoves moved origin; // compare all moves of the piece to thismove
  if not legal:
    die "Illegal move";
  endif;
  restore resultpos;
  if unload:
      drop unload dropsqr;   // relocates another piece (also used for castling)
  endif;
  if locustsqr:
    capture locustsqr;       // removes another piece (also used for castling and e.p.)
  endif;
elseif != dest null and origin:
  // setting up game: guaranteed to be legal, apply implied side effects only
  if match dest epsqrs and ep:
    if or checkaleap origin dest 1 1  // code specifically generated to recognize
          checkaleap origin dest -1 1 // e.p.-capable leaps to empty squares
       and == moved P
       and not capture:
      capture #ep                     // and remove the victim
    endif;
  elseif match dest wcastle:
    if == moved K:  // code specifically generated to
      ...           // identify castling partner and move it
    endif;
  endif;
  set ep false;
  set epsqrs;   // empty array (?)
  if checkaleap origin dest 0 2   // code specifically generated to recognize
     and == moved P:              // e.p.-rights-creating leaps
    set ep dest;
    push epsqrs where origin 0 1; // add all e.p. squares
  endif;
  setflag dest;
endif;

The routine 'genmoves' would generate all moves of a given piece in a given location, in the context of the pre-move board position. In the process it would also build a list of side effects: squares that have to be cleared, or where the captured piece has to be dropped. For 'task 0', used here, it would build a string through

join moved chr 32 origin chr 45 dest chr 59

plus the required suicides and freedrops describing the side effects (e.g. ... chr 32 chr 64 chr 45 sideeffect), for comparison with thismove. On a match it would set legal true, and actually perform the suicide.

If the info on the first move on the sequence was always available, e.g. as firstmoves, firstorigin etc., and we would use the checkbox to suppress autoexecution of the move, it might be acceptably efficient to do the legality checking on all moves. That would certainly simplify the code a lot:

Post-Move:

set legal false;
set task 0; // specifies what subroutine genmoves should do with the generated moves
gosub genmoves firstmoved firstorigin; // compare all moves of the piece to thismove
if not legal:
  die "Illegal move";
endif;
eval join "MOVE: " thismove; // make the move and its specified side effects
if unload:
  drop unload dropsqr;       // dropsquare and unload set by genmove for castlings
endif;
if locustsqr:
  capture locustsqr;         // locustsqr set by genmoves for castlings and e.p. captures
endif;
setflag firstdest;           // moved piece is flagged as non-virgin

The need to store / restore has disappeared. The subroutine genmoves compares the moves of the moved piece in the pre-move position stringwise with thismove, and detects the cases where we are dealing with castling and regular e.p. capture. The implied side effects of these are then flagged by setting unload, dropsqr and locustsqr (which otherwise remain at false). Non-implied side effects are explicitly specified by the move, and thus already executed when we make thismove. So only these implied side effects have to be made afterwards (if the move proved pseudo-legal).

The subroutine genmoves would handle testing and setting of the e.p. info by itself; global variables ep and epsqrs would be involved in that.

Because the code is color-independent, it would probably be best to put it in a subroutine, and have both Post-Move sections just call that subroutine. Since it is also not dependent on the specifics of the variant, it could even be put in an include file. If the routine genmoves would be 'table-driven', it would also be variant-independent, and could also go into that include file. The data to drive it could then be supplied by variant-specific functions for each piece that would return an array describing the moves they could make. It would be the definitions of these funcions that would be generated by the Play-Test Applet, and would have to be copy-pasted to the corresponding preset. (To the Pre-Game section?)

I suppose the info about the first move of the sequence could be extracted 'by hand', by repeated explode, fist on a semicolon, then on a space to separate piece ID from move (already providing moved), and finally the move part on hyphen to get origin and dest.

Would it be an idea to tick the checkbox and take charge of the parsing of the move ourselves? E.g. with code like:

  set mvs explode chr 59 thismove;
  set parts explode ws trim elem 0 mvs;
  set i count mvs;
  if > i 2:
    die "move must be piece ID plus board step";
  endif;
  set sqrs explode chr 45 trim elem dec var i parts;
  if != 2 count sqrs:
    die "board step does not mention two squares";
  endif;
  set myorigin elem 0 sqrs;
  set mydest elem 1 sqrs
  if not onboard myorigin or not onboard mydest:
    die "the board isn't that large";
  endif;
  set mymoved space myorigin;
  if != mymoved elem 0 parts and == 1 i:
    die join "there is no " elem 0 parts " at " myorigin;
  endif;

This seems more efficient than storing and restoring the game state all the time to undo what the system does automatically. And it could also be extended to understand more elaborate move formats, like origin-ep-dest or even origin-ep1-ep2-dest for moves that make a locust captures on ep / ep1 / ep2. Of course we would have to make the move ourselves, at some point, (after the legality testing) by something like

  empty myorigin;
  capture mydest;
  add mymoved mydest;

A general question: do the logical operators and and or also accept numbers as operands, and do they consider 0 false and any other value true, like in C? Or do I explicitly have to convert them to logical values by comparing the numbers with 0?

And am I correct in assuming there is a distinction between using inc (or empty) as an operator in an expression or as an independent command, where only in the latter case it alters its argument? (I.e. is let a inc var a; the same as inc a; ?)

OK, thanks. I never used PHP, so it takes a bit of getting used to. The 'let' must have been a sub-conscious confusion with BASIC. What also confuses me is that the # / var do not seem to be needed on origin, dest and such. Is that because these are really subroutines rather than variables?

The need to handle the implied side effects is a bit of a pain. XBetza could potentially define e.p. capture through Gryphon or Sissa moves. Also, to test the pseudo-legality of the latest move of the game, the preceding move would have to correctly set the e.p. rights. The best strategy seems to include a 'stripped' move generator in the GAME code, which generates only moves with implied side effects (i.e. e.p. capture, moves that create e.p. rights, and castlings). This would then be run for every simple move (the mentioned moves are never composit). This would be rather cheap, as most pieces don't have any such moves at all, so it would not generate anything when these move. In most CVs it would only generate something when a Pawn or a King moves, and it would then only generate the double-push if it was a 2nd-rank Pawn,  the e.p. capture if an e.p. square was created on the previous move, and in range, and sometimes one or two castlings. The few moves it generates could then be compared to origin and dest, and if one of them matches, all the side effects of it indicated by the move generator (i.e. e.p.-victim removal, Rook movement, or setting of the e.p. rights) would then be applied to the board.

For the latest move a complete move generator would generate all moves of the moved piece, and compare those to the input move. This is not optimally efficient, but it is easy and requires very little code that wasn't needed already for other purposes. And it is still very much cheaper than generating all legal moves in the final position for the purpose of setlegal: it has to be done only for a single piece, and the full legality has to be tested only for the move that matches the input. While setlegal requires the pseudo-legal moves of all pieces, and has to test each and everyone of those for legality. So there really wouldn't be any significant gain in optimizing it further, just a far larger code complexity.

Just to be sure: lines in subroutines are only 'pre-processed' when they are executed, but functions when they are defined? So in subroutines var and # would be equivalent?

I slowly start to converge on a design. The idea is that the Post-Move code would always only contain only the line gosub HandleMove false; (for white) or gosub HandleMove true; (for black). Similarly, the Post-Game code would only contain gosub GameEnd true/false; . The routines would be universally applicable code, which could go into the Pre-Game section, or into a file that would be included from there.

The rules would then be described in the Pre-Game section by a large initialized array 'legdefs' of integer numbers, encoding all the moves, functions for each piece type returning where the move data for that piece type starts in legdefs. Plus statements to set a number of parameters, like what the royal type for each player is, whether stalemate is a win or draw, what King destinations imply castling, where the castling partners are located, how large the promotion zone is, what you can promote to on various ranks, which pieces van promote and stuff like that. Defaults for those parameters could be set in the included file, but the CV-specific code could overrule those settings after the include. It is this Pre-Game code that would be generated by the Play-Test Applet.

A rough draft of the code for such a design is this:

// the following arrays and functions are variant-specific, and would be defined in Pre-Game:

set legdefs (....); // a (very large) array of numbers, describing the moves of all pieces
                    // each move is a sequence of 'legs' (leaps or slides in one direction)
                    // each leg is described by 4 numbers in legdef:
                    // range, sideway step, forward step and 'mode'.
                    // the mode packs bit flags describing what must be at the end of the leg
                    // a move with 0 legs is used to indicates the list for that piece ends

def P cond #0 223 45;  // functions map piece types on their move definition in legdefs
def p cond #0 235 70;  // each piece has two move definitions: e.p.&castling-only, or all their moves
def K ...

set many wroyal K broyal k;
...

// the following code is generic, and can be handled as a Pre-Game include

sub GotMove orisqr destsqr:
  // process the move specified by the params and the globals like locustsqr
  if == 0 #task:      // apply side effects of a matching move
    verify == #orisqr origin and == #destsqr dest:
    if #locustsqr:
      empty locustsqr;
    endif;
    if #dropsqr:
      add #unload #dropsqr;
    set hit true;    // abort further generation

  elseif == 1 #task: // test input move for pseudo-legality
    verify == #orisqr origin and == #destsqr dest:
    if not #implied: // explicitly specified side effects must also match
      verify == #locustsqr #suicide;
      verify == #dropsqr #freedrop;
      verify == #unload #dropped or not #dropsqr;
    else:            // no side effects must be specified when they are implied
      verify not #suicide and not #freedrop;
    endif;
    set hit true;    // we found a matching pseudo-legal move

  elseif == 2 #task: // accumulate all pseudo-legal moves
    setlegal #orisqr #destsqr;

  elseif == 3 #task: // test whether move captures king (for check test)
    if == #royal space #destsqr:
      set hit true;
    elseif #locustsqr:
      set hit == #royal space #locustsqr;
    endif;

  elseif == 4 #task: // find one legal move (for mate test)
    my victim locustvictim;
    set victim space #destsqr; // save old values
    // make the move
    if #locustsqr:
      set locustvictim space locustsqr;
    endif;
    if #dropsqr:
      add #unload #dropsqr;
    endif;
    move #orisqr #destsqr;
    // test whether in check
    gosub InCheck #side;
    // unmake the move
    move #destsqr #orisqr;
    if #dropsqr:
      empty dropsqr;
    endif;
    if #locustsqr:
      add #locustvictim #locustsqr;
    endif;
    set hit not #hit; // continue when in check, stop when not

  endif;
endsub;

sub NextLeg togo legindex startsqr cursqr iso:
  // this routine is the heart of the move generator
  // it generates the destinations of one leg,
  // and then calls itsef recursively for the remaining legs
  // 'togo' tells how much legs still have to be done; when 0 we have a complete move
  // 'legindex' tells where the leg descriptions start in the 'legdefs' array
  // 'startsqr' is where the piece that must make the move starts
  // 'cursqr' is where any previous legs brought us
  // 'iso' is the number of leaps taken in an earlier riding leg
  if #togo: // move not complete yet; attempt next leg
    my range dx dy mode to;
    // retrieve leg description (next 4 elements in 'legdefs')
    set range elem #legindex #legdefs;
    set dx elem + 1 #legindex #legdefs;
    set dy elem + 2 #legindex #legdefs;
    set mode elem + 3 #legindex #legdefs;
    if & #mode i_FLAG:                    // initial move only
      verify not ?startsqr;               // suppres it for non-virgin piece
    endif;
    // simple example, handling only (divergent) leaps
    if == 1 #range:                       // leg is leap
      set to where #cursqr #dx #dy;       // calculate destination
      set victim space #to;               // look what is there
      verify != void #victim:             // abort if off board
      if == @ #victim:                    // empty target
        if match #to #epsqrs and
           & mode e_FLAG:                 // move is valid e.p. capture
          set locustsqr #ep;              // flag that it will capture last mover
          set implied true;               // this is an implied side effect
        else:
          verify & #mode m_FLAG;          // m_FLAG etc. are in fact hard-coded constants like 1, 2, 4, 8...
        endif;
      elseif != #side islower #victim:    // foe
        verify & #mode c_FLAG;
      else:                               // must be friend
        verify & #mode d_FLAG;
        set unload #victim;               // remember what we 'captured'.
      endif;
      gosub NextLeg dec #togo + 4 #legindex #startsqr #to #iso; // do nex leg
    else:                                 // leg is slide
      ...
    endif;
  else: // move finished successfully; process it
    GotMove #startsqr #cursqr;
  endif;
endsub;

sub GenMoves piece sqr all:           // generates moves for 'piece' on 'sqr' in current position
                                      // 'all' specifies whether we get only moves with side effects
  my index legcount;
  set side islower #piece;            // remember which side we are generating for
  set index fn #piece #all;           // function returns start of piece description in legdefs table
  do:
    set legcount elem #index legdefs; // the first element specifies the number of legs
    verify #legcount;                 // a 0 sentinel ends the list of moves
    inc #index;                       // 'reads away' the leg count
    set many locustsqr 0 dropsqr 0;   // default is no locust capture or unload
    set implied 0;                    // generated e.p. or castlings set this
    gosub NextLeg #legcount #index #sqr #sqr 0;
    set index + #index * 4 #legcount; // skip to the next set of legs (= move)
  loop until hit;
endsub;

sub GenAll black:
  if #black:
    def friends onlylower;
  else:
    def friends onlyupper;
  endif;
  for (from piece) fn friends;
    gosub GenMoves #piece #from 1;
  next;
endsub;
 
sub HandleMove player:
  gosub ParseMove thismove; // this extracts origin, dest, moved, suicide, freedrop, dropped
  set hit false;
  if == mln $maxmln:
    set task 1; // request legality test
    gosub GenMoves moved origin 1; // match all moves
    if not #hit:
      die "a " moved " cannot move that way!";
    endif;
  endif;
  set task 0; // request execution of implied side effects
  gosub GenMoves moved origin 0;   // only tries e.p. and castling
  eval join "MOVE: " thismove;     // make the move
  setflag dest;
endsub;

sub InCheck player
  set task 3; // request king-capture test
  set hit false;
  set royal cond #player #broyal #wroyal;
  gosub GenAll not #player;
endsub;

sub GameEnd player:
  gosub InCheck player;
  if #hit:
    die "that move would put you in check!"
  endif;
  set task 4;  // request one legal move
  gosub GenAll not player;
  if not #hit: // could not find one
    gosub InCheck not player;
    if #hit:   // checkmate!
      won;
    elseif #staledraw: // stalemate
      draw;
    else:
      won;
    endif;
  endif;
  ... // draw stuff
endsub;

Below is how the GAME code generated for the Pre-Game would have to look for orthodox Chess. This assumes 'smart' generation, which realizes that most pieces are symmetric, so that white and black can use the same table entries for those, and that the Bishop is just the final part of the Queen. Most likely it would be too dumb to see the latter, and then a separate Bishop section would be added. If the pieces were asymmetric, or it was not smart enough to realize they are symmetric, all pieces sections would have to appear in duplicat: one for white, one for black.

include betza.txt
set legdefs
 1  1  0  1  3 // King (0)
 1  1  0 -1  3 // 3 = m_FLAG + c_FLAG
 1  1  1  0  3
 1  1 -1  0  3
 1  1  1  1  3
 1  1  1 -1  3
 1  1 -1  1  3
 1  1 -1 -1  3
 2  9  1  0  8 // castling (40)
    1  2  0  3
 2  9 -1  0  8
    1 -2  0  3
 0
 1  9  0  1  3 // Queen (59)
 1  9  0 -1  3
 1  9  1  0  3
 1  9 -1  0  3
 1  9  1  1  3 // Bishop (79)
 1  9  1 -1  3
 1  9 -1  1  3
 1  9 -1 -1  3
 0
 1  9  0  1  3 // Rook (100)
 1  9  0 -1  3
 1  9  1  0  3
 1  9 -1  0  3
 0
 1  1  2  1  3 // Knight (121)
 1  1  2 -1  3
 1  1  1  2  3
 1  1 -1  2  3
 1  1 -2  1  3
 1  1 -2 -1  3
 1  1  1 -2  3
 1  1 -1 -2  3
 0
 1  1  0  1  1 // white Pawn (162), 1 = m_FLAG
 1  1  1  1  2 // 2 = c_FLAG
 1  1 -1  1  2
 1  1  1  1  4 // e.p. capture (177), 4 = e_FLAG
 1  1 -1  1  4
 2  1  0  1 577 // double push, 577 = m_FLAG + i_FLAG + rights creation
    1  0  1  1
 0
 1  1  0 -1  1 // black Pawn (197)
 1  1  1 -1  2
 1  1 -1 -1  2
 1  1  1 -1  4 // e.p. capture (212)
 1  1 -1 -1  4
 2  1  0 -1 577
    1  0 -1  1
 0;

def K cond #0   0 40;
def k cond #0   0 40;
def Q cond #0  59 58; // 58 = empty move set
def q cond #0  59 58;
def R cond #0 100 58;
def r cond #0 100 58;
def B cond #0  79 58;
def b cond #0  79 58;
def N cond #0 121 58;
def n cond #0 121 58;
def P cond #0 162 177;
def p cond #0 197 212;

set pzs 1;             // promo zone depth
set rooks a1 a8 h1 h8; // castling partners
set wchoice (Q R B N);
set bchoice (q r b n);
set stalemate 1;
set wroyal K;
set broyal k;

Well, this is definitely a powerful method, and allows handling of boards of any topology. But I don't see how it would simplify things in this case. The Interactive Diagram can only handle grid boards consisting of squares. Perhaps with some straightforward wrapping rules (periodic boundary conditions, such as cylinder or torus). Betza notation would be meaningless in boards with irregular topologies.

The code example doesn't alllow for wrapping yet. I guess that when the where operator produces an off-board result, it should really test mode to see whether the move is supposed to wrap (o_FLAG). If it does I guess I would be in for some cumbersome arithmetic on separate file and rank of the startsqr. That would also mean that I cannot use ray for the riding legs, but would somehow have to extend the ray after wrapping.

It is true that XBetza uses directions and relative directions a lot. But the Diagram script already translates that to absolute grid vectors in a compilation step. The legdefs array is almost exactly what the Diagram uses as internal representation (except that dx, dy, range and mode there each have their own array, but that is a minor detail). So the only thing it has to do when someone would hit the would-be button 'Show GAME code' would be to dump those tables for the pieces that were chosen to participate in the desired format, and remember where the data for each piece started. It can be easily checked during the Betza-to-table compilation whether a piece is totally symmetric. (Not done yet; the Diagram only makes tables for white pieces during the compilation, and when it later generates moves for black pieces, it just flips the sign of all step vectors it retrieves from the table. But it seems faster to tabulate the black pieces separately, flipping their steps already in the table, if they were asymmetric.)

Umm, there seems to be a mismatch between the naming of the scalable (SVG) pieces used in the Applet, and the fixed-size 50x50 (GIF) bitmaps in the alfaerie directory. E.g. the wazirknight does not show up because for the alfaerie bitmaps it is actually called knightwazir. The Archbishop / Chancellor / Amazon are my own fault; the SVG renderer used by the Applet creates such compound images 'on the fly', by referring to them as knight--bishop, knight--rook and knight--queen, while in the 50x50 alfaerie set they are of course called cardinal, chancellor and amazon. I should have had the Applet script replace those names when it dumps the design as a diagram using the standard image set.

Thank you for reporting this; it will certainly be fixed one way or the other. For now you can work around it by editing the Diagram description to replace the faulty filenames of the missing pieces by the correct ones. An alternative would be to keep the names, but change the graphicsDir from /graphics.dir/alfaerie/ to http://winboard.nl/my-cgi/fen2.cgi?s=50&p= and the graphicsType to an empty string (just graphicsType= ), to get the same anti-aliased images as the Applet uses (but 50x50). But then you would be using off-site images, and that is really against CVP policy.

For the editors:

In connection with this, it is perhaps a good time to bring up the following issue: wouldn't it be a good idea to improve the availability and/or quality of piece graphics on CVP? The rather ragged-looking alfaerie 50x50 GIF bitmaps in /graphics.dir/alfaerie/ are still the site's standard piece set. Isn't it time to replace those with anti-aliased PNG images, or at the very least provide such a set next to it (e.g. in /graphics.dir/alfaeriePGN/)? I suppose it would be easy to copy the same index page on alfaerie to that other directory, to showcase the pieces.

I would also be happy if there could be a 35x35 alfaerie image set; for the Applet I am currently using an off-site SVG renderer. Of course I could upload a set of 35x35 images myself, even defvote a member-submitted article to them, but then they would be hidden in /membergraphics/MSalfaerie-33 (say), and no other person but me would ever find them there. To get good use of the graphics we have, they really should be provided as options in places where people could decide to use them.

It should now be fixed for new Diagrams generated by the Applet. But it might still be easier to just edit the image names in the Diagram you already made than redoing it from scratch. While fixing the issue I was baffled by the fact that the Applet had stopped working completely; its board mysteriously disappeared. After a lot of debugging it turned out that it was upset that another Diagram had appeared on the same page, in the Comments. The Applet needed to change some settings after initialization, but the way I had programmed that was not resistent to the betza.js file being read a second time, undoing some of the changes. I guess it was a very bad idea to have some of the standard initialization code execute unconditionally when the script gets loaded, in a script that could be loaded multiple times. Eventually I modified the script such that custom post-initialization code can be executed after all Diagrams on the page have done their initialization, rather than just the first one.

I also made the Applet close the ad side bars when the board has more than 10 files. This should prevent the compression we see in the screenshot you posted.

BTW, I noticed that you are using piece IDs of more than one letter. The Diagram was not really designed for that. In particular, it confuses its detection of which promotions are allowed. Because you use both K and DK, and put DK amongst the promotion choices, it now thinks K is also an allowed choice, because there is a K in DK. I am not sure how this can be cured without breaking already existing diagrams.

@Greg:

OTOH, having one or two ugly pieces among good-looking ones would provide a really good incentive for creating the missing SVG. :-) The variants you authored do not seem to feature that many pieces for which we have no SVG yet.

You already put those on this website, at /graphics.dir/svg/ . I haven't made any new ones since then, as it seemed not much was happening with them, and almost everything that I imagined I would ever need was already done.

There is an identical set on the winboard.nl server, where I have the SVG renderer as CGI program. I use them in the Diagram of the Applet through that renderer, but the Applet first looks in the /graphics.dir/svg/ directory on CVP to see what pieces exist. (Browsers do not allow peeking at a website other than where the main HTML page comes from.) The piece table of the Applet contains everything that is there, plus some compounds that the renderer creates on the fly.

There are no SVG for these compounds (or for rotated pieces, or red / green pieces), but since the renderer can supply all those as PGN it should not be too difficult to download those one by one and put them in the PGN sets.

OK, even easier. I did use the on-line renderer. I just transformed the directory listing of http://winboard.nl/graphics.dir/svg/alfaerie, obtained through wget, into a shell script that used wget to download the piece image directly from the renderer, and save them on a file bpiecename.png.

A tar ball with all the black 50x50 PNGs is now at http://hgm.nubati.net/black50.tar.gz .

Now that I have that script, it is even more trivial to turn it into a script for doing white, or red, or 35x35, or upside-down. What shade of red would we want?

[Edit] Now also a complete 35x35 set (white and 'black') at http://hgm.nubati.net/alfaerie35.tar.gz .

Strange, I do see some imperfections in the black pieces with the renderer as well. I don't understand how that can happen; the white seems to cover anything. Could there be color indicators in the SVG that I somehow fail to substitute? Perhaps the Rooks are just sloppily drawn, so that the background leaks through. This is much more visible on a dark piece: 0 to 10% is a huge contrast, 100% to 90% barely visible.

OK, I rendered all pieces with dark color on light backround as 100x100, so that we can easily judge which have imperfections that should first be cured. If you fix those, I will put the fixed SVG on the winboard.nl server so that the renderer uses those, and then query the renderer to make the complete sets we want.

We should also think about which forward-backward compounds we want; the renderer can also compose these on the fly.

Well, I posted it just minutes ago, and it is 9 am here, and I did actually have a sound night of sleep. I will move your new pieces to winboard.nl now.

[Edit] OK, I unpacked your zip file in a directory 'newalfa' on winboard.nl, which means the renderer will now use them if you add the extra argument t=newalfa in the query string. It doesn't entirely work as expected, though. For one, some of the pieces stay white. (I used exactly the same FEN as for the old pieces.) Which probably means the SVG has given them a shade of white that is slightly different from what it was before, and for which the renderer scans the file to substitute it. The rendering also stops at some point. (Probably a missing file, haven't figured that out yet.)

[Edit] OK, FEN rendering stops at the first missing SVG. I copied a few missing ones from the old set (lion, cannon, paovao, nightrider), but very many are still missing.

I think it is best to stick to the original alfaerie naming; I just accidentally misnamed the knightwazir and knightferz. The renderer just uses the names of the SVGs. And the Applet shows the SVG names as they are in /graphics.dir/svg/alfaerie.

The defaults.ini file for alfaerie contains:

f9f9f9
f9f9f9
a0a0ff
e0c080
A89060
compound 64 52 0 3 40
B~ = knight,N-B
R~ = knight+rook,N-R
Q~ = knight+queen,N-Q
C~ = gnu,C-Q
S = silvergeneral
G = goldgeneral
P^ = lance
N~ = horse