Ratings & Comments

Yes, I will be updating the GC presets.  I just want to modify them to use the new fairychess include file while I'm at it and did not get that finished last weekend.  But we have a 3-day weekend coming up so it should get finished.

That table of piece values is quite old so I wouldn't put any stock in it.  Probably doesn't match at all with what I am currently using in ChessV (which gets updated more often.)  The Archbishop is too low probably because I was relying on Betza's logic which significantly undervalues it, but I would not claim that these values are what he would have calculated.  Also, the table shows the value of sliding pieces going up in the endgame, which made sense since there are less obstructions, but seems to not actually be true in most cases.  (The value of the Pawn going up is true, though.)

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

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

In the intervening time, we've had submissions from strong community members who do not have their real names displayed on these pages.  I (and I think we?) still have a slight preference for real names, for the encyclopedic nature of the site, but there are many sites now where site-famous people are later referred to as "user xyz of site abc," so maybe it's fine.

Another thing that changed in the time since your submission: the Diagram Designer.  The use of a period to denote a dot on the board (for movement diagrams) has been deprecated; you can replace them with a pound symbol (#), or a few other options.

My thoughts -

Zebra: The Camel is the more common complement to the Knight.  I think a Zebra is OK on a 10x10 board but would be less mobile than the Knight because more moves would be off-board (although a Camel is color-bound so also weaker than a Knight, but I think this is OK because a Bishop is a colorbound piece that could be considered the complement of the Rook.)  Also, if you keep the Zebra, I think you should keep the name as-is.

No Draws: I'm not sure how advisible this is.  The point of Stalemate is to give the player who is behind something to play for.  For repetition and 100-move rule, at a minimum, the written description needs to be clarified.  It currently says the "last player to move" wins, but your comment says "last to capture".  And for 100-move, do you mean "last to capture or push a pawn"?  That would make more sense.  And do you mean 100 half-moves, like the Chess 50-move rule?  Or do you really mean 100 full moves?  I think that would be too much and I don't see any reason to increase it at all.  Personally, I'd scrap all of this and leave all the victory/draw conditions as in orthodox Chess, but that is just personal opinion.

You do realize that this drives up the bandwidth it requires to download the page, and increases the server load? Browsers would display a table of individual piece images without any further server access, once the complete Alfaerie set is in their browser cache. And the most commonly used pieces certainly would be, from visiting other pages on this site. Perhaps a rare piece (such as the Grasshopper) would have to requested once (from Cloudfare!), and then the user would have that cached too.

A monolythic image of the entire position would be unique for every article though, and have to be downladed. Using a PHP script to generate the image 'on the fly' means it cannot even be cached by Cloudfare.

As I mentioned to you not too long ago, the script used to draw this picture is cached by Cloudflare. Also, the previous diagram had ranks broken into two rows and looked really bad.

Now I am confused. I thought you exempted PHP scripts from caching by Cloudfare, through one of the rules. I don't see how it could be otherwise. PHP scripts are running on the server, not in the client. Surely Cloudfare is not running PHP for us? That would be a much heavier task than just caching the output these generate. (And how would it get the scripts? Normally scripts should not be loadable from other machines, just their output.)

I exempted it from the rule that Cloudflare will not cache PHP scripts. Cloudflare caches the output of this script for different query strings.

Ah OK. I overlooked that. So drawdiagram + arguments is as good as a fixed image, and Cloudfare will carry most of the burden for supplying it. There still could be some concern as to whether Cloudfare would cache unique images of an entire board long enough for the caching to be actually helpful, while individual pieces of the various sets would be requested so often that they would never leave the Cloudfare cache.

Broken ranks is of course awful, and it is good you fix that. But it should be possible to produce good-looking board images from individual piece images through HTML tables (this is what the Interactive Diagram does), so I wondered if it would not have been better (for the server load) to fix it that way.

Server load rarely gets very high, and the rare peak of high server load does not correlate with the site going down. So, even though tables could also work, I'm not worried that using single images will increase the load too much. Also, it has been simple enough to replace various JavaScript diagrams with generated images, because I could reuse the FEN string from the JavaScript with only occassional modifications.