Comments by HGMuller

I did know about Betza's t[FR] proposal for Griffon, but I had never seen this z(FW) notation. XBetza is only upward compatible with the Betza notation for simple ('single leg') moves, and has its own system for combining these to multi-leg moves, which is more general than any of the suggestions that Betza coined in various scattered places.

The z modifier applied to a slider atom is original Betza notation for a crooked version of the piece, and is still supported in XBetza. On a leaper, such as zW, it never had any meaning.

The role of parentheses has completely changed; in XBeza these indicate zero or more repetitions of the enclosed group. So z(FW) would mean zzFWzFWFWzFWFWFW..., which doesn't really mean anything.

Brackets originally were not used in XBetza, but legs of a move were 'chained' by using an a as separator between the modifiers of each leg. This does the job of unambiguously defining very complex moves, but often leads to a very obfuscated description unsuitable for human digestion. A much clearer notation is possible by using brackets (but in a way that somewhat is different from Betza's t[...] construct). The brackets still enclose a sequence of simple Betza moves, which are supposed to be played in that order. But there is no t prefix (which was redundant, because the brackets are never used for any other purpose than chaining the contained moves), and separates the enclosed moves by hyphens (if continuation is mandatory) or question marks (if the move could also end there). This notation is already supported in the Interactive Diagram for simple cases like the Griffon ([F?R]). Supporting it in its full glory is a desire for the future.

The meaning of z in a multi-leg move has also changed; it now means l or r, but the opposit of what the previous leg did. (So that it can be used to specify crooked paths, while q means l or r in the same direction, and can be used to define curved paths.)

The Zerdinal has mating potential, and it might be useful to give a link to a pre-programmed checkmating applet for it. (E.g. in the Notes section.)

/membergraphics/MSinteractive-diagrams/EGT.html?betza=ZB&name=zerdinal&img=zebrabishop

That also applies to the Half Duck, which does not have its own Piececlopaedia page where such a link can be found. There is no checkmating applet that can do crooked sliders like the Snake, but the non-lame sub-set FN easily forces checkmate, even on 16x16 boards. Forcing checkmate for a piece that has FR3 moves, such as the Tetrarch, is trivial (even on a quarter infinite board), and probably does not need an applet: the piece alone can drive the bare King to a corner.

I would avoid the use of yy in the move description of the Aviaanca, as this is really an undocumented feature of XBetza, to make recognition of some bent riders in the bracket notation possible as long as the latter is still implemented through pre-processing. It will be abandoned when the bracket notation will be parsed directly. Better use [W?AA].

W and F instead of R and B. And afaf(afafaf)W can be written as nHH, a non-jumping Threerider. [W?nHH] for the other move does not work yet. (It ignores the n.) Eventually it should be possible to write this as [W(?nD?W)].

/play/pbm/sets/*.php

I don't think combining brackets with parentheses is implemented at the moment. I guess some special treatment would be needed there. Currently parentheses are expanded by including mutliple copies of the move they appear in, with 0, 1, 2, ... copies of the parenthesized group. But if the leading or trailing character of the group would be a question mark in bracket notation, the maximum number of repeats already stands for any smaller number of repeats as well.

So it seems the meaning of parentheses in the bracket notation should be changed, to only indicate the maximum number of repeats. (I.e that indicated as a number behind the parentheses, or a default depending on board size.) The repeat group can then be chained by question marks if less repetitive versions of the move were also desired.

I think it should be possible to use multi-character IDs in morph and captureMatrix by using comma separation in the rows these occur. This is untested, though. And the Play-Test Applet won't generate this format, but just concatenates the IDs, even if these are multi-character. So you would have to insert the commas by hand.

You would forbid the capture of all non-pawns by pawns in the captureMatrix, and then exempt the pawn's normal captures from this restriction by suffixing it with an apostrophe.

What would not be possible is having some moves that can only capture pawns and others that can capture only knights. (So you cannot implement an Ultima Chamelion with this method.)

And I do hope, one day, to get some of my simpler variants on there.

Your variants are typically more 'regular' than Gerd's, in the sense that they could draw on existing chess-variants infrastructure of Jocly. For example, there is support for rectangular and hexagonal boards of any size and shape, but not for boards with switches, which would have to be programmed from scratch. There is support for normal, and even single locust captures, but not for 'recruiting' moves that make captured pieces appear elsewhere, or for neutral pieces.

For your variants the programming would be limited to indicating the piece moves.

In principle, yes. If these are not too different in style.

Western sources are usually wrong. Of course on can question if there actually is something  like THE original historic rules, as different manuscripts not always agree. So rules might have changed with time and place, like they did for medieval Chess. But since a Teaching King is described as Queen plus Lion Dog, and its move diagram is drawn as that of the Queen with three perpendicular line elements on each move close to the origin, it is pretty certain the LD was more than Q3.

The FF should probably be changed here to conform to this.

GitHub is a website where programmers publish the  source code of the programs they develop. It is not a site where you can play anything. But of course some of the programs published there are games. Those could be downloaded and compiled to run on people's own computers, and often the programmers already offer a compiled executable for download. To offer something there that others could use, you would have to write a program that plays it.

Jocly is one such program available on GitHub. It is a gaming platform for use on websites through a web browser, or running on your own PC through JoclyBoard. It is mainly a user interface, but is designed in such a way that it can easily extended with new games, with already a lot of supports for the tasks most chess variants have in common. So you would only have to program the part that is unique to your variant, in JavaScript.

We have a version of Jocly installed on CVP, and there is also one on my website, where people could browse to, and play the games they support.

Indeed, the names of the promoted versions are swapped.

How about this one, then: "it would be a miracle if there weren't any genuine coincidences".

Well, the knight-on-a-shaped-base is a move-oriented solution, so it ignores the name entirely.

The date no doubt has something to do with it. :-)))

What do you think about switching to the Lance picto-sprite for the Hoplit in Spartan Chess? Then it would have a different symbol from the FIDE Pawns. And I doubt that any western variant will ever want to use a piece that moves as the Shogi Lance. (But they might of course want to use it for a piece with another move for which there is no dedicated representation available.)

Resigning in a 3-player game is a serious problem, though. I think the rule that is currently stated is very unsatisfactory. In fact most games are expected to enter a phase where one of the players has no hope at all to win, and would likely lose interest at that point. If one of the players was obviously winning, resegnation at that point, resulting in a 3/4-3/4-0 score, would rob him of the deserved victory. Preferably resignation of one of the players would not disturb the balance of power between the other two, and desiding upon a result immediately would almost always do that.

As crowns and miters are something worn on the head, some other kind of headgear, such as a helmet or a hat would probably be suitable for a piece with the additional powers of a man. While this might not work as easily for rook+man or bishop+man, these are also rook+ferz and bishop+wazir and are known by other names, such as dragon horse and dragon king. So maybe they could be represented in a different manner. Or all three might be represented by human face pieces like in the Superba set.

Even though chess pieces (unlike the pictograms used in 2d diagrams) are more than just the head or head cover, it is true that the head is the distinctive feature, and the bodies all look alike.

To indicate the KN move in a variant that also features the Amazon, you could leave on the cross. It is very unlikely there will be both a royal and non-royal Centaur in the same variant. Or replace the cross by a spike, to distinguish it both from a Queen and a King head.

The Jocly 3d pieces can provide some inspiration; the Crowned Rook there is a Rook with a crossless King head mounted on top. No room for confusion there; a Rook with a Queen's head would make no sense. For the Crowned Bishop I use a pontifical tiara. Both give pieces that distinguish themselves very well from other Staunton pieces.

the author refuses to further explain his reason for choosing such a number. 

You obviously have not read "The Hitchhikers Guide to the Universe"...

But, no panic!

The S seems to curve in the wrong direction. A prancing horse doesn't bend his back in that direction. E.g. the Ferrari logo:

It is a bit difficult to diagnose the problem. By adding the ?nocache=true you bypass the CloudFlare cache, but the browser would also consider it a file that is distinct from the one without that suffix. So it would keep separate copies in the browser cache for each of those, and when you have seen the correct one through the ?nocache=true prefix requesting the file without prefix might still give you the obsolete one.

And the problem is that in the context of pages in articles by others you have no control over whether this suffix is added.

It seems we are turning into an art website, now that 75% of the pages is devoted to art, and only a quarter contains actual information. (And that is even discounting the ads...)

Perhaps we should move the website to the domain www.chess-art.com, instead of chessvariants.com?

A figure with a horse head or helmet doesn't remind me of a centaur.

the ferz knight in this interactive diagram is wrongly colored for black

Not for me. Try to flush your browser cache; this problem was already detected and fixed in Herculean Chess, and that fix should be effective here too.

Resegnation is a fact of life that cannot be prevented by any rules. The best rules can do is put a sanction on doing it, and the worst imaginable sanction is an individual game is that you would lose. Which is exactly the idea, and thus has zero value as a deterrent. You will have to find a better solution for when one of the palyers forfeits (e.g. loses on time because he simply walked away).

The board is drawn in an unnecessarily much distorted way; many cells are very narrow, without reason. The 'arms' of the board could be made much wider, and all cells could be approximately circular. All edge cells could be of the same, minimal size, and then increase in size towards the center, the three heptagons being largest of all.

Is the Sissa possible in fairy-max?

No.:-(

I am planning to create an engine similar in strength to Fairy-Max which can do anything the Interactive Diagram can do. But it is in a very early stage of inception,  and the project was interrupted by the necessity to rescue the TalkChess forum.

Is the Paste Diagram description here: input broken?

Not that I know; for me it still works. What are you trying to paste?

I would swap the Queen with the d-Rook. But it is your game.

Have you flushed the browser cache? The none-pre-defined pieces are sorted alphabetically after the pre-programmed ones (with move), and I see the Stone after the Squirrel.

The re-rendering of the SVGs at 50x50 appears to have created quite some errors. In this case the SVG fill color was #ffffff rather than #f9f9f9, and thus not recognized as something that should be recolored. I fixed it now, but since the faulty image is still cached by CloudFlare the fix doesn't show  up.

Ah, of course, the PTA is using the PNG pieces, not the SVG, and in particular the 35x35 set. I now have added the stone there too.

As I said below, I am using this as a game simulation for Territorial Chess, a combination of Chess and Go.  

OK, I see. You want to have Go-like capture. One way would be to define the move of the Stone as cU (Universal Leaper). Then you can use a stone to capture the entire chain you want to remove one by one, and finally move it back to where it came from.

Well, this is a bit tricky, since the webspace I use there is not really my own, but is hosted by someone I cooperated with long ago for the development of XBoard. And the problem appears to be that someone (not that person, so presumably someone from the hosting company itself with root access) renamed the gitweb.cgi script to 'gitweb.cgi_disabled_by_HL'. Now I could of course rename it back, but I suppose they intervened with the private files of their customers for a good reason (probably to do with security), and don't want to anger the hosting company and create trouble for the person that allows me to use his webspace. So I am still trying to figure out what to do that would keep everybody happy.

BTW, that gitweb.cgi is no longer there should not prevent you from pulling from the repository.

OK, now I also added an SVG for the Alfaerie 'stone' image.

Ok, I'll remember that for the future!

No, don't, because it was wrong. The relative pathname would still have needed a graphics.dir in it, as it would not be interpreted relative to the graphicsDir of the Diagram, but to the URL of the page, which is something like /rules/grand-apothecary.

The problem was in the betza.js. It takes apart the name of the %-containing image at the dots, to test whether it already contains a file extension or that the specified graphicsType still should be added. But then it has to put everything that was not an extension together again, (separated by dots), and it was forgetting the last part.

Why a Go stone? Wouldn't a checker be good enough? This already existed in Alfaerie SVG, but was never copied to the directory that the DEsSG got its pieces from. I copied it now.

I don't think it is a good idea (to put it mildly) to have computer-generated images of pieces in the piececlopedia. Photographs of actual 3d-printed designs might be another thing; if we would also publish a link to a file people could use to 3d-print those themselves these would serve a purpose. Many of the virtual pieces I have seen here are unacceptably ugly, fragile, or unsuitable.

However, pieces with these names should show a woman with snakes for hair rather than a target with lines or arrows coming from it, which seems to be based on how a particular piece moves instead of its name.

In biology 'medusa' is a stage in the life cycle of jellyfish, and I think the image attempts to depict that (the dashed lines representing the tentacles).

Anyway, the original Alfaerie GIFs used this image, and I just made an SVG copy when I needed it to equip some variant article with an Interactive Diagram. I never used the piece myself.

I am from April 19, if that may help...

Well, on the website it is now solved. But of course you will not be looking at the website as long as CloudFlare thinks the copy of it that it has cached is still valid.

Until the CloudFlare cache gets cleared you could try to replace the "wmedusa.png" in the custom-set definition of the preset by "wmedusa.png?nocache=true".

I did push the required patch of base-model.js now, so the current version should be fully operational.

Next I will make a similar evaluation function for Chu Shogi.

I think it would indeed be better to slightly demagnify the Ram part (so that it can be squeezed less, as the width seems OK). It is not just that it is in front, but the size of the images is not really to scale; in real live a Ram is much smaller than an Ox. Which is no problem if they are individual images, but might seem unrealistic in a composit. (Let's hope we never need a Spider-Elephant compound...)

Indeed. The SVG for the Gorgona was derived from that for the Medusa, and apparently it inherited the characteristic that prevents its rendering by fen2.php. I also had these on my own PC (made with fen2.cgi on winboard.nl, before this was made available on CVP in a PP wrapper, where it was apparently not a problem), and uploaded these now to the alfaeriePNG folder.

I now have added a promotability evaluation to Scirocco that doesn't seem too idiotic. The idea is that the promotion gain of each piece is multiplied with the estimated probability the piece will promote. Sliders then get 90% of that value added to their piece value, while for leapers it ranges from 20-90% depending on how far they are from the zone. (Measured  in the difficulty to go there, considering the size of their leap, but also the number of forward moves with such a leap; a Dababba would be discounted more than an Alfil in the same location.)

The probability estimate assumes there is a certain minimum army strength required to defend the zone, and that you first have to reduce the opponent army to that level by equal trading before you can promote. What you have left at that point will promote.

This doesn't account for the fact that some pieces gain more on promotion than others, and that you will try to selectively preserve those in the unpromoted-trading phase. Because the opponent of course will try to preferentially trade your good promoters away, I am not usre how successful such a strategy can be on average.

Another subtlety is that there are fast promoters (sliders), which will start promoting as soon as the entire zone cannot be defended, and slow promoters (leapers), who will take some time to get there even if unobstructed, and can much easier be defended against because of their low mobilty. You would only have to defend the entrance of the zone, and can often even prevent they reach the zone by meeting them far before they get there with your own leapers.

In a contest where one side has fast promoters and the other slow ones, of equal total value and gaining equally on promotion, the player with the fast promoters would promote those before the slow ones can promote, and then try to trade those according to their increased value for the yet unpromoted opponent pieces, leaving him a surplus after the slow ones are annihilated. This is currently not yet accounted for. In Scirocco it might not be that important, as there are very few sliders in the initial setup there. (And the Scirocco's don't have such a strong promotion.) But it would be for Chu Shogi.

Both look good to me. If the left/right part would be perceived as specifying a temporal order, the one with the Ram facing right is the correct one, as the piece first 'pulls' (= Withdrawer-captures) a 'you' (= enemy piece), and then 'pushes' (= Advancer-captures) another 'you' out of existence. So if there is anything inconsistent, it is in the name, and not in the image.

You could also call them the Bent Betzas!

Note that Americans might get upset by the pun.

Yes, I am already working on the others. For some the custom evaluation was entirely wrong. (E.g. in Elven Chess the testing for insufficient mating material made no sense, as by using fairy-piece-model all type numbers had changed. And the bonus for advance Pawns did not take into account that the promotion zone was 3 ranks rather than 1, and was only awarding the bonus when the Pawns were already in the zone.)

And Aanca is indeed Acromentula. I thought I had replaced that everywhere, but apparently I missed some.

[Edit] I have now fixed the obvious evaluation errors in my non-Shogi variants. But:

• Makromachy has no dedicated evaluation at all. So it won't encourage Pawns to advance, no matter what set of eval parameters it uses, and it won't recognize insufficient mating material. (But it is so large that the latter might not matter.)
• Scirocco needs to encourage many other pieces than Pawns to advance towards the zone. Especially the very slow ones, such as Ferz, Wazir, Steward and Commoner, but to a lesser extent also the range-2 leapers Alfil, Dababbah, Stork, Goat and the enhanced Knights.
• That holds also for other Shogi variants without drops. (Scirocco is a sort of Chess-Shogi hybrid.)
• Minjiku Shogi currently also has no dedicated evaluation.
• Chu Shogi still has the unmodifed Classic Chess evaluation, basing its 'insufficiant mating material' judgement on the idea that piece types 4 and 5 are Knight and Bishop, and Pawns promote on last rank only.
• Shogi, Tori Shogi and mini-Shogi have empty evaluation functions. They would really need some King-Safety term to play sensibly.

OK, sorry. I overlooked that you were not changing the stroke:none but the fill:none. (And I did not see any filenames, as I just copy-pasted them from your comment in WYSIWIG mode.)

But then the good result is entirely accidental, and cannot be generalized to other images that contain a 'none' filling or stroke.

I think I understand what was causing the problem, though: because this image did not have a black outline with white/blue fill, but had a black ouline without fill, and an exactly matching white/blue area without outline inside it, the latter gets white/blue pixels that are partly transparent when rendered as a raster image. Normally only the black outline touches the transparent background. Apparently the palette did not contain the white/blue with the required transparency, and rounding took place which either made the pixels entire white/blue, or entirely transparent. (Mostly the latter, it seems from the mottled result.) When you apply the fill to the outline, the holes in the inside area make this fill shine through, which camouflages them. In fact these stroke:none elements seem entirely redundant if the other elements are filled.

This SVG was probably generated automatically with the help of an edge-tracing function; these often do not treat the outlines as outlines, but as borderless black-filled areas, tracing both the inner and the outer side of the black lines. And then they create separate areas for the interior.

Well, no one had made an SVG of a back-to-back Camel and Knight either. If you are referring to the Ox-Ram chimera shown in an earlier command: SVG of the Ox and Ram are available too.

In my opinion, the first ones look best. So I don't think I made any mistake here.

We have a proverb: "In the land of the blind, one-eye is king". The goal is not to be best, but to be good. This 'first one' has much to narrow outline compared to the other alfaerie pieces. It is not the original. As my math teacher used to say: "nearly correct. Thus faulty!"

A Knight-Camel chimera seems a very odd choice for a Push-Me Pull-You, which neither moves like a Knight nor a Camel. Encouraging its use seems the opposit from what we should do, as it can only cause confusion. If this page uses it, the proper action would be to replace it on this page for something more sensible...

That's not true. All the original GIF pieces and their PNG replacements have separate white and black pieces regardless of how the black pieces are colored.

I was talking about SVG pieces. So far these were only used as input for rendering scripts. The browser on my tablet wouldn't render them if I used them directly (as I did in one of the Comments below). So they cannot be used directly. And if a script is used to render them, this script does not have to be awfully clever to know that when someone asks for bxxx it should render wxxx with teh default white color replaced by the default black color. So we had no use for the black alfaerie SVG.

The XBoard (and Motif) pieces do have essentially different designs for black, though. In fen2.php you can request these by asking for black color #202020.

Another detail about minjiku: the rules don't match the sprite for the ninja. Even if you don't have time to make a 3d ninja, it would be nice to have an updated model.

I now used the Gate in the game implementation as well. This is not such a bad choice, as this piece was intended to represent the Ski-Rook, the hole at the bottom symbolizing it would skip the nearest square. I used it in Scirocco for the Wagon (which is a lame Ski-Rook). And the Ninja has a sideway Ski-Rook move. The only good idea for having a dedicated easily recognizable Ninja representation was to use a shuriken, but this is not tube-like, and would have to be made entirely by hand. (But we could have used the Star...)

Unfortunately there was a lot more wrong with Minjiku Shogi. Apparently I broke the SkiGraph routine for doing ski-slides when I enhanced it for doing the Osprey. So it was doing a normal Rook move rather than a ski-slide. This must be fixed in locust-move-model.js.

And that is not all; the flying generals do not respect the ranking as promoted pieces. The ranking is part of the piece-type definition, but to make testing of it more efficient, I copy that to the piece object, so it can be easily tested by the move generator or GetAttackers function (which is called really often). But promoting a piece just alters the number of the piece type (piece.t). It does not add or change the ranking number if that new type had a ranking. This must be fixed in base-model.js, which handles the flying pieces.

And when I am at it, I might as well provide a method for requesting 'double promotion' in base-model.js as well. Perhaps I should allow specification of negative numbers in the promotion-choice arrays returned by the user-supplied promote() routine. The base model could then interpret these as their absolute value, but whenever such a promotion is applied to the board, call a user-supplied custom routine for adapting the game state. In the Minjiku case this routine could then set the ranking of the promoted piece, and in Team-Mate Chess it could add the extra promotion piece to the origin square of the move. (Problem: the legality testing, (through cbQuickApply), which ignores promotion, might reject the move if it doesn't realize the origin square is not evacuated. But I guess it even has that in common with the ranked pieces; the promoted piece might block a flying attack that the unpromoted piece would not. This will require some careful thinking.)

Since no one else did it, I have now created wknightcamel.svg and bknightcamel.svg by removing the zebra stripes from wcamelzebra.svg and changing the color for the black piece.

I guess normally one uses the Wildebeest icon for this compound. Usually we don't have any black SVG, since the fill color can so easily be adapted to anything. Only for piece sets that have their black pieces really black we have separate symbols, as filling with black would make the inner lines invisible.

I replaced "fill:none" with "fill:#5984bd" in bbadger.svg and "fill:#f9f9f9" in wbadger.svg. I uploaded both corrected files and used them to generate new PNG files.

That is not the correct thing to do, and will alter the image. To figure out what these invisible strokes are, I replaced 'none' by #ff0000, and then I get:

So it seems these invisible outlines cover partly the black, and partly the white areas. It would be less critical if you would first reduce the stroke width to 1.

There must be a bug in the SVG rendering routine that it cannot handle the 'none'.

I am afraid that it is more a matter of being tenacious and making long hours, than of talent.

I am still not entirely happy with the eyes drawn by the Tube tool. The mapping of the tube surface onto an 80% x 80% area of the diffuse/normalmap sometimes causes very poor resolution in one of the dimensions. Especially in designs with long legs, such as Spider or Octopus. It divides the entire height of the maps over the sum of all the lengths, while each tube can use the full width of the map, no matter how tiny the tube diameter. I already improved the situation a bit by allowing parts that need little detail to be vertically compressed, to make more room for other parts, but this doesn't help enough, and can still result in eyes being drawn with very poor vertical resolution.

What is really needed is to keep track of the ratio of the total tube length (along the surface) and the maximum circumference. If that gets extreme (say > 3), it would be better to map it to a rectangle that is 4 times higher than wide, and split that into an upper and a lower part, which are then displayed side by side to fill a square. The maps nor also always leave room for a disc in the upper-right 20% x 20% to which a cone segment can be mapped, even if no such segment is used. (And I hardly ever use it...) Without the disc the map could be structured as two side-by-side 50% x 100% areas, and even with a disc the left part could be 50% x 100%, and the right part 50% x 75%.

It would probably a bad idea to have discontinuous mapping of a single tube onto the maps, but very long tube length typically occurs because there are multiple tubes in the design. So it can roughly split the tubes into two approximately equally long sets, one going into the left part, the other in the right part. It might also be useful to make it pay attention to the diameter of the tubes. Those with very small diameter, such as the Spider legs or Octopus tentacles could be mapped into a narrow area on the right. Perhaps it would in general be better to not split the width of the map 50-50, but 70-30, mapping the narrow tubes onto the 30% half.

I will take a look at Minjiku.

There also is the issue that I amended the rules of Team-Mate Chess here on CVP with the possibility of a 'double promotion' to a pair of inverted Silver Generals. And that the Jocly implementation still uses the old rules. This would require extra code. While Team-Mate Chess so far was the only variant I did for Jocly (and therefore did first) that didn't need any code modifications.

It depends on whether they would offer the same promotion choice or a different one. For the same choice all you would have to do is add the line

maxPromote=2

to the Diagram definition, and make sure the two promotiong pieces are the first two in the table. It doesn't matter what their ID is; only the IDs of the pieces they promote to must be used in promoChoice, never the ID of the promoting piece.

Offering a different choice is possible in the Diagram, by only have the first piece promote normally (the default situation), and defining a second promotion set, and letting the second piece morph to that. But this is not supported in the GAME code yet; only automatic morphing into a single type is supported there.

Spider SVGs:

Perhaps the inner lining of the black one still needs some work. Maybe I should make it entirely black.

You are a bit too hard on our non-programmer users. Since Game Courier is partly implemented server side through PHP, and partly client side through JavaScript it is not really possible to know what task is done where if you don't know the exact details of the implementation.

For clarity: the rendering method is decided server side, (so communication with the server is needed to chage it), and only the Table and CSS rendering method, once provided by the server, would allow you to move pieces through mouse clicks.

BTW,  isn't it possible to make the system more user friendly by automatically requesting a new page load when someone changes the setting of the render method? It should be possible to attach a JavaScript event handler to such a change of the selected item.

You should not see any search results, because you did not request a search. The confusing thing here is that the address bar is used for two pupropses. If you type a URL there (presumably recognized by containing no spaces, and a number of internal dots) it interprets it as a website address, and goes there. If it doesn't recognize what you type as a URL, it sends it to the website of your defaut search engine (apparently Google), and that will then return search results for your request, which will be displayed with clickable links.

If you get no response, it usually means it cannot even connect to the address that you typed.

The reason I put up that page is that when you also suffer a crash loading that, we can systematically start deleting parts of it until it starts working, and determine that way what the offending part was.

[Edit] I now made a page so simple that it should never cause a problem for any browser, at https://chessvariants.com/hi.html . Check if you can see that.

I was wondering if we could finalize the 2d and 3d visuals for team mate.

The following things would have to be done there:

• The 2d Cobra image would have to be improved. (There were complaints it looked too much like a tennis racket.)
• The Spider must be added to the fairy piece set. This requires:

1. Creation of a 2d Spider icon for in res/fairy/icons.
2. Adding that to the wikipedia-fairy-sprites.
3. Some hand-editing of the 3d mesh file, for shaping up the inner legs.
4. Making a visual of the 2d+3d representation for in res/rules/fairy.

• Making the team-mate view use those.
• Make 2d and 3d visuals of the team-mate setup.
• Making a new thumbnail.

I think I will start with the mesh editing.

There are quite some more differences than I would have expected. Apparently there are a lot of SVG images that have not been incorporated in the PNG set. Mostly 'ferzed' or 'wazired' versions of existing mimages, by drawing a cross on those.

The PNG set has a number of inverted images, which were no doubt made by rendering the normal SVG upside-down with the aid of fen2.php. It has also a gnu, as a knight-camel composit, and many elephant composits. These were probably all made with the aid of fen2.php's ability to combine two images.

The white crookedbishop was wrongly named in the PNG set. The bknightgeneral is missing from the PNG set, which has a wknightgeneral. There is a wpegasus.svg file in the PNG directory, which doesn't belong there.

The best approach is probably to just copy all the PNG50 files to the PNG directory, which will make all the files in the rightmost two columns available, and replace every image not in the left two columns by their 50x50 equivalent. Then only the images in the left two columns might have to be reconstructed at 50x50 through a more dedicated action than just rendering an SVG. Although some of these already are 50x50.

[Edit] I remade all the remaining images, so all alfaeriePNG are now 50x50.

Browsers nowadays use their address bar not only for entering web-page addresses, but also for using search terms that should be passed to a search engine. Many years ago you first had to type the address of the search engine's website (like www.google.com) into the address bar, to get to a page where you could then type your search terms on that page. Such pages still exist, but seem to automatically transfer anything you type on them to the browser's address bar, like you were typing there.

Anyway, which search engine would be used to find things you type in the address bar that are not web addresses is usually a browser setting. On FireFox you can specify what your default search engine is. The default setting for this is google.com, which is probably why it displays the Google icon next to the address bar. But you can alter that in the FireFox settings menu. 

I hit the back arrow and brave said it had a '500 Internal Error', whatever that means.

The message probably was '500 Internal Server Error'. When you get such an error it is not your browser's fault; the website you were viewing did produce the page with this error message (which your browser then correctly displays) because something went wrong on that server. In this case that doesn't tell us very much, because we cannot be sure which website we were accessing after using the back button. It could have been the website of the search machine.

Since the errors already occur when you directly type chessvariant.com addresses in the address bar, it is best not to involve any search machines.

Just out of curiosity:

I made a copy of the page souce of the CVP home page, and put that back on the site as http://chessvariants.com/home.html . Can you access that page with your iPhone?

I now ran some matches with the individual Zen-Zebra pieces against their FIDE counter-parts, in a FIDE context. Only the Charging Zebra was able to beat the Bishop pair, with a moderate 54.5% score over 199 games (where the statistical error should be 2.8%). Such a score corresponds to a quarter of a Pawn, and that for a pair of pieces.

The other Zen pieces lost, sometimes badly. The FIDE Rooks won with a 66% score, about the same as Pawn odds, suggesting they are each 0.5 Pawn better than their replacements. The Knights won by 56.5% over 100 games (4% error), which translates to a 0.15 Pawn superiority of a single Knight. Perhaps somewhat surprisingly the Queen replacement did very bad: the FIDE Queen won with a 59% score, slightly over half a Pawn, and that for only a single replacement.

This is all very tentative, as I only run the tests with white suffering the replacements (which normally should have given them the advantage), and I did run all games from the same initial position, and did not check for duplicat games. But is seems especially the Rook and Queen replacements fall short of their target.

So it seems the Zebra moves, despite their large leap, are not dangerous enough to compensate for the fact that they more often fall off board. It could also be that the asymmetry of the Z moves in the Zen pieces disadvantages them. It enables them to raid deeply into enemy territory, but they then cannot get out the way they came, and might be trapped there. This desrves an investigation, e.g. by testing FffsbZ (asymmetric) against FvZ and FsZ (symmetric).

I would suspect an unsupported or incorrectly implemented html feature in the browser, rather than a javascript error. If I include buggy javascript on a page the page displays as it was loaded (i.e. as you would expect from the Page Source), but the scrpt just stops working (no longer modifying the page) at the point of the bug (or did not do anything at all, if it contained a syntax error), and the page won't react to mouse clicks. In the console (popping up by hitting the F12 key in FireFox, in the console tab) I can then see the error message, and the point in the javascript source code where the error occurred.

The browser message that a page crashed I only saw when I intentionally terminate the corresponding firefox.exe process with the Windows task manager. (Sometimes I have to do that, when pages try to grab more memory than is physically available, and cause my entire PC to practically grind to a halt.)

I have no Apple devices, so I don't know how to do the corresponding things in Apple browsers.

In a preliminary test with Fairy-Max (using the piece values of the Nutty Knights army) the Zen Zebras lost 61.5-38.5 from FIDE. While most of the armies beat FIDE by such an amount. I am now running some matches with 2-for-2 substitutions of the individual piece types, to see which piece is the weakling.

I don't see the use of having separate tables for the pieces of the north and south player. These are almost completely the same. And I doubt that one of the differences would be correct: Although it is Japanes custom to have one of the players use 玉将 (Jade General) for royal piece, (not necessarily the north player, btw), Google translate doesn't know any translation for 玉妃. The few differences can easily be mentioned in an extra column, or even both in the same table cell.

And they still don't supply the most important information: which name belongs to which image. You are not showing kanji pieces here, so the Japanese name gives no indication which piece is which.

There doesn't seem any need to list different abbreviations for the two players; in western Shogi notation (PSN) one uses capitals for both players.

You also give no description of the moves. Although many articles here write "pieces ... move as in orthodox Chess", I don't think that we can assume every reader here knows Shogi.

The article is very repetitive anyway; you mention in two places that the difference is the addition of the Princess, even before you start a section "differences with Shogi". Much of that is redundant.

I cannot even imagine how it could happen in principle. You can only be stalemated if it is your turn.

'Japanese Rook' here means 'Lance'? Better say 'Shogi Lance' then, as people that do not know Shogi would certainly have no clue what 'Japanese Rook' means. Or better yet, say 'forward Rook', so that everyone knows what it means.

I wonder about the balance. Zebra is significantly weaker than Knight on 8x8, but that is because it is so clumsy, and gets easily trapped because most of its move fall off-board. But as a compound with stepping moves I am not so sure. The steps restore good manouevrability, and the Zebra moves can be very dangerous because of their long reach, which allows them to attack behind Pawns without getting in their reach. The Charging Knight (fhNbsWbF) is significantly stronger than a Knight, and the Charging Zebra might be similar or even better.

You don't have to attack your own King for forcing checkmate with a Rook, do you?

It is not completely clear what "being in check by your own pieces" means. In FIDE rules the checking rule is formulated as that you cannot expose your King to (pseudo-legal) capture. But my own move would never do that for my own pieces, as after that it is not my turn to move anymore. And it is conceivable that the opponent is forced to resolve the self-check before it becomes your turn again, or that this turn will never come. E.g.

When white plays Qe2 here black is checkmated, and if that terminates the game there is no danger that the white King would be captured by its own Queen. Also, if black is on move here, can he play Ke2, because the Queen is not allowed to capture him, as this would also attack her own King? In FIDE rules capturing a King trumps the checking rule, and is allowed by any pseudo-legal move. But in Atomic Chess the rule that you cannot blow up your own King trumps capturing/blowing up the enemy King, and Ke2 would indeed be allowed in the given position.

So it is important to specify the priority of the rules, in particular what would happen in a position where you can both capture your own King and the enemy King. The opponent could put you in a discovered check from your own piece. Can he do that while exposing his own King to capture elsewhere, because you must save your own King from self-capture first? Would you already have lost, because you must capture your own King even when you can also capture the opponent's?