Comments by HGMuller

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.

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.

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.

The rightmost board-painter image looks like it would fit well within the set. But are we allowed to use it?

I will redraw the Cobra more like the opper part of the rightmost image.

I have already tweeked the 3d Spider enough to make it acceptable.

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.

I now used the new pieces in Team-Mate Chess in the Jocly on my own website. (With an all-black Spider for the 2d.) The white Cobra might still have a little too fat outlines. I will still have to put the new sprites in the move diagrams in the rules description, and then I am ready to push it.

I also want to use Spider and Octopus in Scirocco; these occur there as promoted pieces.

Just to be sure I understand what is going on: showpiece.php also renders the white SVG files as a raster bitmap, after replacing the #f9f9f9 by some other color? And then saves this bitmap as a PNG image with palette encoding?

I know for sure that all areas of the images you mention that must be recolored are filled with #f9f9f9. Otherwise the rendering of the black pieces with fen2.php would not have worked. But there the inside of the Rook is always blue.

So the problem is not in the SVG; it must be in showpiece. It must overlook one of the #f9f9f9 strings when it replaces those. That it always does it in the Rook part suggests that the string is in some special context there that prevents it from being recognized by the substitute command. These images are all composits, and they were probably made by Greg (I usually relied on fen2.php's ability to combine SVGs on the fly, without first making SVG for those) with Inkscape by combining the existing SVG images of the pieces they combine. Perhaps this combining created the context that prevents the recognition of the color string.

The bbadger.png looks weird. I suspect something has gone wrong in creating the palette. Perhaps an overflow of the number of colors. It is all the pixels that would interpolate blue and black that seem to be missing.

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.

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

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.

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

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.

And if it's not, why do your badger pieces look exactly the same?

You really cannot see the difference between:

and these?:

It appears that the configuration of all the variants I added still needs fixing in index.js. I never realized that he AI's evaluation is controlled from there, and always just cloned the same game definition, only changing the build scripts and filenames of visuals and such. But I just found out that the weights of the various evaluation terms are controlled in the property config.model.gameOptions, in a property levelOptions.

It appears that the version I cloned was referring to config_model_gameOptions_2, which is a setting for Shatranj or mini variants, and doesn't award advance of passers very much. Most of the variants would need the settings used for classic-chess.

You could also call them the Bent Betzas!

Note that Americans might get upset by the pun.