Comments/Ratings for a Single Item

Thanks. Your stag looks nice.

I think it would look fine either way, as long as the symbols used are consistent (As you have probably guessed at this point, I am a bit of a stickler for cosistency). This is more of a matter of personal taste.

The only thing I'll say is maybe giving the black stag image a black border rather than a white one will make it look a bit better. The white border may make it look out of place compared to the rest of the pieces, at least to me.

very nice Stag

I made the change.

I wondered whether I should try to draw a different sprite because the movement is different from the flying stag.
I gave it a try, and we can change for it if you like, or try to do it better...

I saw that you copied over everything, which is good. However, an unfortunate side effect of this is that the Prancing Stag diagram in Chu Seireigi's rules description is that of the Shogi Flying Stag.

To fix this, you will need to copy the image below to the biscandine site without renaming it, and then update the HTML in the Chu Seireigi rules description (You can simply copy the HTML from the CVP file, which you can find here).

taken into consideration

thanks

Thanks.

I've taken the comment into account, which will improve the doc.

@François Houdebert,

While I was on the biscandine site, I noticed a few errors in your rule descriptions, as well as an error in the Tori Shogi Jocly implementation.

In the Tori Shogi Jocly implementation, Player A's Left Quail has its movement mirrored from what it should be.

I have attached the corrected images for the movement diagrams below. I also removed the extraneous black lines from the Mini-shogi setup image.

https://www.chessvariants.com//membergraphics/MSa.-m.-dewitts-miscellaneous-files/corrected-images-biscandine-jocly.zip

I take it that's the program you use for making the SVG?

Here is the lightburn project if usefull to you

thanks

I saw that you copied the updated rules descriptions from the CVP Jocly presets, which is good. I made some fixes to these to improve clarity and remove a few typos I found. I will admit in advance that I am kind of a stickler for consistency, but if you can make those changes that would be great.

For Hectochess and Seireigi you can simply copy the code from the CVP rules files. The only thing you might have to fix is the Lance graph path in the Seireigi file.

view-source:https://www.chessvariants.com/play/jocly/dist/browser/games/chessbase/hectochess-rules.html

view-source:https://www.chessvariants.com/play/jocly/dist/browser/games/chessbase/seireigi-rules.html

For Chu Seireigi the rules description on the biscandine site is much better, but there are still a few discrepancies, and a few pieces are listed twice for some reason. I'd recommend simply copying the source code from the CVP Rules description to fix the text, and copying over the pictures whose links I have attached below.

Corrected Rules HTML

view-source:https://www.chessvariants.com/play/jocly/dist/browser/games/chessbase/chu-seireigi-rules.html

Corrected Movement Diagrams

https://www.chessvariants.com/play/jocly/dist/browser/games/chessbase/res/rules/shogi/graphs/bear.png

https://www.chessvariants.com/play/jocly/dist/browser/games/chessbase/res/rules/shogi/graphs/seireigi-whale.png

https://www.chessvariants.com/play/jocly/dist/browser/games/chessbase/res/rules/shogi/graphs/teacher.png

https://www.chessvariants.com/play/jocly/dist/browser/games/chessbase/res/rules/shogi/graphs/fox.png

https://www.chessvariants.com/play/jocly/dist/browser/games/chessbase/res/rules/shogi/graphs/bird.png

the svg has been exported from lightburn( software used to pilot the laser cutting machine).

The SVG could probably be edited also by inkscape I suppose. If you have any improvements to the rules, I'd be happy to incorporate them, as they're important for introducing people to the games.

I updated the 3d image.

https://www.chessvariants.com/play/jocly/dist/browser/games/chessbase/res/visuals/chu-seireigi-600x600-3d.png

I'll update the svg occasionally, lightburn doesn't work at home (on linux).

I take it that's the program you use for making the SVG?

Also, while I was uploading the Jocly files to the CVP site, I took the opportunity to make the rule description for the Jocly Chu Seireigi preset more accurate. Your version has some discrepancies and doesn't describe everything, thought to be fair I was still finalizing everything then. I can provide you with the files you need if need be.

I did the same for the Seireigi and Hectochess rule descriptions to a far lesser extent, though I am not overly concerned about these two.

I'll update the svg occasionally, lightburn doesn't work at home (on linux).

It doesn't really matter if there are extra spare parts, the main thing is that the game is complete.

I've also been looking for ideas for a lion hawk icon distinct from the griffon icon.

If there were an acceptable candidate, it would probably still take quite some time to  to finalize.

If you want something that is nice and easy to make a diagram of via the Musketeer Chess site's board painter, the site should have the first and third icons available for use. Personally I'd recommend the first one, as it is a winged lion. The one used for Chu Seireigi can also work.

Here's a new setup picture for your rules description (refresh browser cache if old one shows up):

https://www.chessvariants.com/play/jocly/dist/browser/games/chessbase/res/visuals/chu-seireigi-600x600-2d.png

I'm working on a new 3d picture as well. I'll post another comment with it when I am done.

P.S. You may need to update the laser cutter SVG, but I am not overly concerned about that. You did include two extra Rooks in it though.

I made the change.

I've also been looking for ideas for a lion hawk icon distinct from the griffon icon.

If there were an acceptable candidate, it would probably still take quite some time to  to finalize.

@François Houdebert,

I made one last change to Chu Seireigi and Dai Seireigi, renaming the Lion to Lion Hawk to avoid confusion with the Chu Shogi Lion, while also keeping the Bishop + Squirrel move from before, whose Jocly code is shown below.

graph: this.cbDropGraph(geometry, [[-2,0],[-2,-1],[-2,-2],[-1,-2],[0,-2],[1,-2],[2,-2],[2,-1],[2,0],[2,1],[2,2],[1,2],[0,2],[-1,2],[-2,2],[-2,1]],[[1,1],[1,-1],[-1,1],[-1,-1]]),

(Keeping the Lion Hawk's value at 11 is reasonable, as it is basically equal in strength to a Queen, and may sometimes even have a light advantage)

In case you are wondering what a "Lion Hawk" is, I imagine it as a Japanese version of a griffin.

For the new diffusemap, simply use the Tenjiku Shogi Lion Hawk diffusemap.

For the 2D sprite, the best choice in my opinion for this piece may be the sprite two spaces to the left of the "gem" image in this spritesheet, as it resembles a griffin head with cat-like ears, at least to me. (If for some crazy reason you plan on implementing Dai Seireigi in Jocly, I would save the "falcon" image used for the griffin in other Jocly presets for the Flying Falcon or Cloud Eagle).

If you can implement these changes on the biscandine site that would be great.

P.S. Thanks for playing that test game with me. It helped me finalize the Lion Hawk's move.

I think I've mentioned in our game chat why I prefer KNAD (or, to me, KNS) for the Lion: it does at least have some history. I don't know of anywhere else where a Lion is BNS. (Even so, if it had an adjective on the name, reflected by a compound in the Greenwade graphic, I could deal with it.)

I'm actually starting to lean back towards the Bishop + Squirrel move for Chu Seireigi and Dai Seireigi, since in my test game of Chusei with you, if the Lion had the KNAD move you would be able to force mate in 3 with just the Lion, and I don't want one piece to steal all the show from the others.

Edit: Looking at the current position you can still force mate in 3, but you need to get more pieces involved.

false alarm : it was a cache issue

Thanks. I know you may be a little frustrated, and I apologize if you are, but it is an unfortunate truth of development for my more complex games that updating them can be quite laborious and tedious, especially when several options exist for playing them. As a general rule, I want my games to be well-thought out and high in quality, so I am willing to make changes like this to try and make my games better.

Check your rabbit in daiseireigi. they are promoted by default in stag.

Can you elaborate further on this, please? I'm not sure what you are trying to say here.

I did check the Running Rabbit in the diagram and the text, and everything seems to be in proper working order, including the text that shows the legal moves of the piece when clicked.

Done.

Check your rabbit in daiseireigi. they are promoted by default in stag.

I made one last change to Chu Seireigi, making the Lion move like its Cazaux form (a Chu Shogi Lion that lacks multi-move capabilities). If you could implement that on the biscandine site that would be great.

I'll even make it real simple for you on what you need to do. You'll need to go into your http://chu-seireigi-model.js and look for the Lion definitions (searching for "sh-lion should do"), which looks like this:

				66: {
					name: 'lion-w',
					aspect: 'sh-lion',
					graph: this.cbDropGraph(geometry, [[-2,0],[-2,-1],[-2,-2],[-1,-2],[0,-2],[1,-2],[2,-2],[2,-1],[2,0],[2,1],[2,2],[1,2],[0,2],[-1,2],[-2,2],[-2,1]],[[1,1],[1,-1],[-1,1],[-1,-1]]),
					value: 10,
					abbrev: 'LN',
					fenAbbrev: 'N',
					initial: [{s:1,p:55}],
					demoted: 67,
					hand: 18,
				},
				67: {
					name: 'lion-b',
					aspect: 'sh-lion',
					graph: this.cbDropGraph(geometry, [[-2,0],[-2,-1],[-2,-2],[-1,-2],[0,-2],[1,-2],[2,-2],[2,-1],[2,0],[2,1],[2,2],[1,2],[0,2],[-1,2],[-2,2],[-2,1]],[[1,1],[1,-1],[-1,1],[-1,-1]]),
					value: 10,
					abbrev: 'LN',
					initial: [{s:-1,p:168}],
					demoted: 66,
					hand: 18,
				},

Set the Lions values to 11 and replace the current graph definitions with the following:

					graph: this.cbDropGraph(geometry, [[-2,0],[-2,-1],[-2,-2],[-1,-2],[0,-2],[1,-2],[2,-2],[2,-1],[2,0],[2,1],[2,2],[1,2],[0,2],[-1,2],[-2,2],[-2,1],[1,1],[1,-1],[-1,1],[-1,-1],[1,0],[-1,0],[0,1],[0,-1]],[]),

Once that is done, the biscandine Jocly preset should play at least somewhat reasonably.

Thanks. It looks much better.

copied

@François Houdebert,

I've noticed for a while that for the 2D Classic Jocly sprites for Seireigi, all the promoted (red) kanjis being mirrored rather than being rotated 180 degrees like they should be, which looks a bit ugly and may confuse certain players, especially those who are used to single-kanji graphics.

Attached is a spritesheet that fixes this, which I would like uploaded to the biscandine site.

www.chessvariants.com/play/jocly/dist/browser/games/chessbase/res/shogi/seireigi-shogi-sprites.png

the command to filter chess game would be :

gulp --no-default-games --modules src/games/chessbase build --prod

We could also ask the more general question of not keeping anything other than chess variants. Something to think about.

Indeed, that occurred to me too. We could easily delete all lines in the jocly-allgames.js file that do not refer to chess variants.

OTOH, the preferred access to the variants on this website appears to be through the Jocly overview page, not through the 'other Jocly games' link that the applet always shows. It is a bit silly when you first have to select a variant you don't want to play, and then switch. And the switch works in the applet, but not for the rule description page we embedded the applet in.

But the overview page also needs refactoring; listing the available variants by date is not helpful at all to the unwary visitor of this website. I am not sure what the best presentation is, though. I suppose alphabetically, even though this competes with what you could do (with some more knowledge and effort) in the site's alphabetical index.

I am also thinking of 'modernizing' the install here. By replacing jocly.game.js the Jocly core is already fully compatible with the recent source code. The only variant in the CVP install that has not been back-ported to source yet is Tenjiku Shogi. Since all game-specific model and view files include a version of the chessbase model and view, there is no harm in different variants needing different versions of these.

So we could replace all model and view files in the chessbase folder by those from the most-recent compile, and the images and supporting info file these use in the chessbase/res sub-tree as well. I think Tenjiku Shogi exclusively uses sprites, mesh files and diffusemaps from the shogi2 subdirectory, which does not exist in the source tree. Only jocly-allgames.js must be made to always have the extra line defining Tenjiku Shogi, compared to the version created by building Jocly from source.

I suggest you update jocly with HGM's version of capablanca and my timurid's version: they now have a prelude allowing you to select a sub-variant.
this will remove the need

• carrera, janus, gothic
• babur, wild mirza,wild babur, wild timurid

You could also add Fantastic XIII and bigorra.

We could also ask the more general question of not keeping anything other than chess variants. Something to think about.

That's perfect.

better like this ?

@François Houdebert,

I noticed a bug in the Hectochess implementation. When castling, the starting squares of the Champions and queenside Knights (b2/b9, c2/c9, and i2/i9) are not being checked to see if a piece is occupying them or not, allowing castling when it should not be possible to do so.

Thanks.

Can you also do the same for normal Seireigi? It has the same problem with its 3d Kanji pieces.

There appears to be a mismatch between the shogi graphics on CVP and that in the current source code. On CVP there are directories .../chessbase/res/shogi and .../chessbase/res/shogi2. The first contains the tile meshes and diffusemap for mini-Shogi, the second for Chu and Tenjiku Shogi. The current source code was derived from the latter, even though it reorganized the location where the diffusemaps are stored.

The problem occurs because the newly made Seireigi diffusemaps are made according to the Tenjiku design, (and placed so the view files can find them), but use the mini-Shogi tile mesh files. And it appears that these mesh files specify the use of a different part of the diffusemap for painting the top face: the mini-Shogi tiles use the top-left quarter, while the Chu-Shogi tiles use the bottom-left quarter of the maps.

I fixed the problem by editing the chu-seireigi-view.js file, to make it use the mesh files from the shogi2 folder. The kanji then appear. But apparently not all mesh files used by seireigi are there, as some of the pieces now disappear completely.

[Edit] The problem was in the map files: some Seireigi pieces use the diffusemap of Chu-Shogi pieces, and these are in a different location on CVP from where they are in the current source code (and have different filenames too). I adapted the path for the diffusemaps of Copper, Kirin, Phoenix, Lion and Queen to where these images are on CVP, and now the initial position of Chu Seireigi is correctly displayed.

For some reason, the 3d graphics for Seireigi and Chu Seireigi are only showing as blank Shogi pieces, and in the case of certain Chu Seireigi pieces, not showing at all. Any help would be greatly appreciated.

Also, I noticed a bug in the Hectochess file, where, when castling, the Champion starting square is not checked to see if a piece is there or not.

Therefore Fergus created separate HTML pages for individual variants, which embed the Jocly applet preconfigured to run the corresponding variant, with a rule description. The overview page you refer to contains links to those individual game pages.

While I used to make separate HTML pages for individual variants, I replaced this practice with a PHP script that gets called through a semantic URL whose relative part starts with "/play/jocly/". If you want to review its code to see how it works, you can find the script at "/play/jocly/control.php". It relies on certain files being in place to display the description, rules and credits. It should work with games that have not been indexed yet, and if you do use it with unindexed games, you can, as an editor, add them to the index.

Edit: Also, Hectochess doesn't have the 3d Queen, Marshall, and Cardinal for some reason...

Indeed, I noticed that too. I did upload a newer fairy-sprites file, and that made the Champion and Wizard appear.

[Edit] OK, that should be fixed now too. Hectochess was using the proper-*.js files for these 3d pieces, which differ from the original ones by a scale factor, to give them a more natural size. But these were not present on CVP.

[Edit2] I now moved a lot of the new 3d pieces to the CVP Jocly install as well. I had never payed much attention to the version here as far as updates go, because the CloudFlare caching made it pracically impossible to see any changes. But now that Fergus has exempted Jocly from this, it makes sense to bring the version here up to date as well. Makromachy already works. For Minjiku Shogi some of the promoted pieces seem to be still missing.

Hectochess now works, albeit with a few sprites missing. I just need to upload the sprites and diffusemaps for the Chanpion and Wizard.

Edit: Also, Hectochess doesn't have the 3d Queen, Marshall, and Cardinal for some reason...

As the matter of fact, why don't you update that page "Play Chess Variants with Jocly" which was listing all available games until last year?

The problem is that it is a matter of taste what 'available game' means. The Jocly applet itself allows you to select any game that is implemented, through the 'other jocly games' link. But this applet is not able to show rule descriptions or credits, which are also available for most of these games in the Jocly source package.

Therefore Fergus created separate HTML pages for individual variants, which embed the Jocly applet preconfigured to run the corresponding variant, with a rule description. The overview page you refer to contains links to those individual game pages.

In general the reason for there being no link to a certain variant in this overview page is that there doesn't exist such a separate HTML page for that game yet. Someone would first have to create those pages.

@ HG: "If you want to see a running install featuring the newly added games, you can use the one on CVP (just select any of the dedicated variant links on the Jocly overview page, and then click 'other jocly games' at the bottom right to select a game)"

Yes, that's what I wanted. Thanks.

I also know the address for François's Biscandine.

As the matter of fact, why don't you update that page "Play Chess Variants with Jocly" which was listing all available games until last year?

Maybe it is what you plan to do later on?

Apparently the jocly.game.js was still the original one from 2017. The addition of LetsTwist (to make the Mersenne Twister random generator available to the game-specific code) is the only modification I ever made in the Jocly core. I have now replaced that file with the one on my website; this should make it work.

You also have to add a line to /play/jocly/dist/browser/jocly-allgames.js to make Jocly notice the files that you placed in /play/jocly/dist/browser/games/chessbase/.

I've done that. It shows up on the Other Jocly games panel, but when I try to load it, it doesn't work. I get the following error:

hectochess-model.js:257 Uncaught (in promise) TypeError: JocGame.LetsTwist is not a function
    at ZobristInit (hectochess-model.js:257:20)
    at Model.Game.InitGame (hectochess-model.js:354:3)
    at JocGame.GameInitGame (jocly.game.js:3:7385)
    at JocGame.Init (jocly.game.js:3:1572)
    at e (jocly.core.js:1:1233)
    at eval (jocly.core.js:1:2511)

Where can your work on Jocly with François, HG, can be found?

That depends on what exactly you want. The source code is in my on-line git repository, but it is currently not possible to view that interactively on line because the hosting company disabled the viewer for that ('GtitWeb'), and I haven't had time to fix that. It is still possible to pull from the repository with 'git', to view the source code locally. And I suppose François has a mirror of it on GitHub.

If you want to see a running install featuring the newly added games, you can use the one on CVP (just select any of the dedicated variant links on the Jocly overview page, and then click 'other jocly games' at the bottom right to select a game), or the one on my website, which are old Jocly installs that I hacked to add some variants. I suppose that François has put up a version directly compiled from the most recent source code somewhere.

You also have to add a line to /play/jocly/dist/browser/jocly-allgames.js to make Jocly notice the files that you placed in /play/jocly/dist/browser/games/chessbase/ . I think Fergus exempted the Jocly files from CloudFlare caching, so you should see new games immediately after flushing your browser cache. To do that I sometimes have to access the modified .js files (including jocly-allgames.js) directly with the browser.

Unfortunately the wikipedia-fairy-sprites.png file on CVP is not entirely compatible with the one that is now in the source repository.

@Adam: you wrote "uploadnig a new Jocly game to the site." Which site are you talking about? The one linked to this comment brings to a page where the last update is from 2023. And that page has a hyperlink on "Jocly" word which is broken.

Where can your work on Jocly with François, HG, can be found?

Thanks

I have uploaded François Houdebert's files for the Hectochess implementation to the site. I guess now it's just a matter of waiting for the server cache to clear, unless I need to do something else when uploadnig a new Jocly game to the site.

Yes the lance might be suitable.

I'd also wondered about the captain, and you may consider using the machine that is used with the same movements in other variants. But the choice of the lighthouse is perhaps aesthetic, as its 3d representation is more successful or better proportioned than the machine.

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

Let's just say that I thought it would be interesting to complete the fairyset, but if the idea doesn't meet with unanimous approval, we can think about it later.

As for spartan, it's a point of detail, since the set is already well developed, but it would probably be better to have a V or a spike on the top of the black pawn to distinguish them from the white.

In short, I'm not doing anything on pullreq, I'm just testing on my personal branch.

Does Jocly currently support any variant that uses Berolina Pawns at all? The 3d realization was made mostly as a test case for the initial version of the Tube tool (it is a purely cylindrical design). In that sense the committing of it was a bit premature, like for the Flamingo.

The design you have here looks a lot like the Alfaerie design, which is a variation on the Alfaerie normal Pawn. But the Wikipedia set uses an entirely different Pawn design. If we want to add new Pawn types, I think we should use that as basis.

Spartan Chess is an implemented variant that uses a different Pawn type, for the Spartans. These 'Hoplits' are very close to a Berolina Pawn, but not exactly equal, because their initial double push can jump, and isn't subject to e.p. capture. They do have their own 3d image, (a Pawn modified to carry a lance), but also use the normal Pawn image in 2d. If we want to distinguish the Pawns in 2d it seems more urgent to do find a symbol for those. In the WinBoard implementation I use the Lance pictogram for those. We could also do that in Jocly (now that we added the Lance). But it would still not have its own picto-sprite in that case. (But who would want to use a Lance and a Hoplit in the same variant...)

I am not sure we should go for a double-head design in 2d if we did not also do that in 3d. An alternative would be to write a V on their breast, to symbolize their non-capturing move.

And what about the Asian Pawn, for the western skins of the Shogi variants? These now also use the normal Pawn symbol.

I made a second attempt to find a 2d representation for the berolina pawn with less white on the black pawn.

I'd like to add it if the result is acceptable because i find it preferable to have a different representation instead of the ordinary pawn if possible.

It might be interesting to add a 2d sprite for the berolina pawn since there's a 3d representation in the fairy set.

It could be inspired by alfaery sometimes like that

or may be a more pointed pawn to go with the 3d image.

Indeed, Pulling still works!

So I am still trying to figure out what to do that would keep everybody happy.

Suggestion: Contact the admins at the hosting company, and ask. Barring anything else (meaning, if you don't get a reply after two tries), leave the "disabled" cgi in place but copy it to a new regular one.

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.

Do you have a way to reactivate your git server, I haven't retrieved the patch from base-model.js yet.

your git server seems stopped

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.

It's true that Jocly is not very strong, which is not necessarily a problem for introducing games to the general public. They need a game that is intuitive, beautiful and against which they can hope to win without too much research.

To assess relevance you need to select "strong" level to have realistic results. One day the jocly UI will perhaps serve as a basis UI for a more specialized application for chess variants.

Are you going to continue to improve the evaluations for your shogivars? Do I have to wait to push the latest changes to scirocco?

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.

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.

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.

well done, that changes everything. Do you want to change gameOptions in index.js on games like elven, spartan, werewolf, scirocco? even makromachy, minjiku?

The rules refer to aanca, is it the acromentula?

I implemented pair-promotion to Brutes in Team-Mate Chess, and updated the rule description accordingly. I also improves the evaluation, making it recognize insufficient material draws were all remaing pieces are color bound and on the same shade. I think that should finish it.

The name doesn't really speak for itself. Don't hesitate to make any necessary changes, maybe for the shako too.

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.

it's a good point to detect and be able to make this type of finish now.

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

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.

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 hadn't anything special in mind for Owl or Flamingo. I made these mainly as test cases for the Tube tool, to try out whether the newly implemented feature for tilting the rings and defining multiple tubes was workable. (The Owl used a second tube for its beak.) Up to that point I had only been able to make pieces that consisted of a single, vertical tube consisting of stacked ellipses. The Flamingo is associated with a (6,1) leap (which is pretty useless on an 8x8 board).

Bravo you have graphic talents.

As for my understanding of the fairy set, I was wondering what the owl and flamingo would be used for.

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.

yes, I would say entirely black for the black one. I think it's better. Or just the small top triangle in the head in white.

It looks good, but for the black one might expect the reverse color drawing for the hooks and mandibles.

Spider SVGs:

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

I like both too.

I think I'd rather vote for the first, but frankly I'd be happy to go with the general choice because I like both.

I made these SVGs:

But I am still not sure whether it wouldn't be better to only show the head+hood part. Like this:

The inspiration comes from here. Same kind of drawing tutorial here.

I'd say you can take inspiration from a drawing tutorial to make your own drawings, as long as you customize them enough.

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.

Here are some cobra tests:

• the same without the tongue
• another in profile
• the last one less round, I'd thicken the lines if it's worthwhile

Well, I think the existing cobra is okay. I don't know whether to look for a better one or make slight improvements to the existing one.

I'm going to try it out.

Would the existing spiders in the musketeer editor be suitable?

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.

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

I have a feeling it's the last remaining important task for the pull request. It might be an opportunity to reconsider the choice of sprites for phoenix, cobra and acromentula, which might have also an impact on the rules as well. I can help if needed.

I like it this way. It will make the game much more accessible. I've also added a draft file of rules that you should feel free to revise.

There are still some 'quick wins' for jocly, I'm thinking in particular of Team-Mate Chess. If you use phoenix, cobra and may be mortar sprites. It would be easier to start with.

After I know that you might use a spider for the acromentula, but if you don’t, a rhino would be easier than the eagle.

Good idea. Note That I have amended the rules of shogis included chu shogi.

I made the Tori sprites, and pushed those to pullreq. I did demagnify the Goose somewhat, as it seemed unreasonably large for such a weak piece.

To have the white Quails look towards the center, the Right Quail had to look to the left. I don't know if that should be considered confusing.

I think so. The Stork, Elephant, Leopard and King are all in the fairy-sprites.

There only is the matter of diversifying the Quail. It is probably best to have the Left Quail look left for both colors. Then the pieces are flip-invariant. I does mean that in player A view the white Quails look inward, the black Quails outward.

Looks good to me. Do you have all the sprites for a set?

The Goose is excellent. For the Pheasant and Quail, I made these:

for my part I prefer representations based on the move.

I made a second try. What should be kept / improved / abandonned ?

For the quail, I was not inspired, I tried a quail chick (hieroglyph) or origami (japanese theme). But I can try more.

For the pheasant : 4 candidates ...

It is always a dilemma whether one should pick the representation based on the move or on the name. I tend to go for the move; names you can in principle do without. E.g. in Elven Chess the Warlock is represented by a Lion, not by a Wizard symbol.

A move-inspired pictogram representation for Tori Shogi would use the King for Phoenix, Leopard for Crane and Elephant for Falcon. The Goose, Pheasants, Eagle and Quails are unique to Tori Shogi. We happen to have a good Eagle pictogram, but for the others 'anything flies'.

Name-based pictograms offer the challenge to make many different distinguishable and recognizable birds. That is hard, as some of the birds would look very similar. The sprites you used are all very much out of style with the Eagle. We do have a Phoenix and a Falcon in the fairy-sprites, and as far as I am concerned the Stork we have there is indistinguishable from a Crane (other than by coloring, which the pictogram does not show). That also leaves Goose, Pheasant and Quails. For the Quails this one would be in style. (But is seems to be copyrighted...) For a Pheasant this one is the closest I could find. (But it is too wide; to match it in scale we would have to cut off the tail feathers. But a long tail is the main charcteristic for a pheasant; otherwise it looks like an ordinary cock. This one has the right style, but I don't recognize it as a pheasant.) This seems a good Goose. (But again a copyright issue.) Perhaps something based on the top-right drawing here (omitting the colors).

[Edit] This could also make a good Quail.

And the head of this one could be a good basis. I recognize it as a pheasant even without the tail.

Thanks.
I've added the skin that uses these sprites as well as the rule files I had already created.

Feel free to rework them as you want, I just wanted to have a minimum doc by default.
Would you be inspired to do the same for shogi tori?

I tried it out but it wasn't very accomplished, but perhaps you have some pictograms that might be suitable ...
Maybe there'll be some artists on the cvp site who'll be inspired...

We can also rework the sprites to be finalized if we agree on a first draft

OK, I pushed the reworked sprites to pullreq, under the name shogi-picto-sprites.png.

no problem, Jocly can wait, we'll talk when you're free.

How about using the Prince fairy sprite for the Jeweled General?

Sorry I had so little time to spend on Jocly; there was an emergency at the talkchess.com forum, for which the hosting was terminated per March 1, and for which we had to set up a new server. We managed to do that in time, but there still are some imperfections that have to be ironed out. But I will try to update the shogi picto sprites.

I'm back on the subject of adding a skin with black and white pictograms in jocly for the shogi in addition to the kanjis, at least on the current pull request. For the moment, the candidate skin can be seen on this link.
I remembered that having a tokin appear in this form was not consensual, it could be replaced by a gold general or the icon could be different...

Tell me if it's acceptable as it is, if we should wait for another one or leave it as it is.

For CVP we could add even more skins but I think we need at least one alternative skin for the basic jocly.

For the pullrequest in progress, I'd be interested in a skin that suits you for the shogi, with pictograms and colors.

I don't know if you have the time to come up with one right now, but it would be an important step in finalizing the work in progress.

A distinct file would have the advantage of being easy to customize.