Comments by HGMuller

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.

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.

Link?

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

Yesterday I forgot to push the patch of base-model.js that Scirocco needs to work; for evaluating the promotability it needs the total army strength. Rather than having it calculate that again, I now pass it from the standard chessbase Evaluate function, (which already calculated it, but then only passes the difference of the two armies in evalValues), as the 4th parameter to the dedicated evaluate().

Perhaps everything that Evaluate() puts so much effort in calculating (by looping over all pieces) should be put into a single object, rather than just variables private to Evaluate(), so that the dedicated evaluate() can use that directly by passing it this object. Rather than having to rely on the often useles combinations that are made of the results and passed as evalValues.

BTW, I was a bit shocked how weak the Jocly AI is. I tried a game of Scirocco against the Interactive Diagram, with Jocly on level Medium (~10 sec?), and the I.D. at 2.5 ply (~0.1sec), and even though the I.D. did some trades I considered bad (but were good according to the piece values it guestimated) it massacred Jocly (until it finally lost with a huge advantage by not knowing that repetition is forbidden). It appears that Jocly at this level still overlooks quite elementary tactics, such as the only protector of a piece being traded away so the piece hangs, or by relying on protection from a piece that is soft-pinned.

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 am from April 19, if that may help...

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

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.

There was an error in handling the dots in the alternative filename by the betza.js script, which I thought I had fixed some time ago: it choked on the dot in graphics.dir. Apparently I fixed that wrong, although I thought it did solve the problem we had at the time. Anyway, it should now work correctly. (After flushing the faulty version out of the browser cache).

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

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.

Make sure to flush your browser cache. Otherwise it won't see the new images, because it uses the cached directory listing for seeing what pieces are there.

Well if you have a piece that does have a defined move, you could move any piece you want to get rid of in its path, (through an illegal move to an empty square, which is always accepted), capture it with that, and then move it back. I agree this is more cumbersome, but I don't know how often thise works.

I don't know what variant you are using this for, but when you want Alfaerie pieces, you could also use the Play-Test Applet, which uses these by default. There you can define the correct moves, and if you want whole-board images, you can just take screenshots of it.

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.

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.

I wouldn't start an article with a large diagram of another Chess variant. The diagram of the initial setup should be the dominant eye-catching feature of an article. At the stage of the introduction it is not of much interest to the reader what exactly the setup of Fortress Chess was, other than that it started the Kings in opposit corners, behind a rank of 4 extra Pawns. (Which is also visible in the setup diagram of Guagamela Chess.) If you want to show a diagram of it, I would advice to do it in the Notes section. Then you can also discuss in detail what imperfections you percieve there that you wanted to improve on.

But it is not clear to me what the 'perfection' is. The 'Fortress Chess' setup looks much more convenient. A Knight on g1/b8 is awkwardly placed; it seems much better to swap those with the Rooks on e1/d8. And the Bishops in the original also seem more easy to develop.