Comments/Ratings for a Single Item

Here is a jocly implementation of zanzibar-s + an updated version of gigachess II + timurid :

Distribution :

http://biscandine.fr/variantes/echecs/zanzibar-s.zip

Sources :

https://github.com/fhoudebert/jocly/tree/timourid

The sources used the sprites containing chessvariants icons

to @Hg Muller : Do you retrieve the sources and the distribution, may I remove the zip file?

I did now.

Thanks

I uploaded all the files in chessbase to the Jocly installation on CVP, and added their names to jocly-allgames.js. This made them appear in the list of "other Jocly games". Some of them got stuck on selecting them in 3D mode, which appears to be a consequence of missing or incomplete piece models. I copied the new chessbase/res/fairy subdirectories, which made most new games work, except for Gigachess II and Wild Mirza. It tured out the problem there was missing *-normal-map.jpg and *-diffuse-map.jpg for the crowned-rook and the wolf. There existed such files, but without the hyphen (*-normalmap.jpg). This made all the games run.

There seems to be a problem with the crowned-rook and wolf, though, as these are now wildly painted. Probably because of a collision between pieces you created anew, and pieces of the same name that already existed in my fork. Furthermore, the wolf looks like an archbishop, in Wild Mirza, and I cannot imagine this was intentional. We do have an excellent wolf, but amazingly enough I did not use that in Werewolf Chess. (This uses the Eagle for the Werewolf.)

The 2D board for Zanzibar S is very large. It does not even fit on my desktop's screen.

Probably a merge problem between 2 versions of fairy-set-view.js as this should have been corrected.

I have replaced today the wolf by a snake in wild mirza, it was too strong.

You can see the deployed version of :

http://biscandine.fr/variantes/echecs/examples/browser/control.html?game=giga-chessII

http://biscandine.fr/variantes/echecs/examples/browser/control.html?game=wild-mirza-chess

http://biscandine.fr/variantes/echecs/examples/browser/control.html?game=zanzibar-s-chess

corresponding to the sources of the branch : https://github.com/fhoudebert/jocly/blob/timourid/

I can rename files for the 3d files of the wolf if it helps (it is a new piece). Is your git branch for CVP jocly games public?

Let me know if I can help...

PS : the new distribution zip is available

http://biscandine.fr/variantes/echecs/zanzibar-s.zip

The problem is that there isn't really any git branch for the CVP Jocly games. Originally I created these games by directly hacking the library. I have started to backport all that to source code, and the source code for that fork you can find in the jocly hgm branch of the git repository at http://hgm.nubati.net/cgi-bin/gitweb.cgi . But it is far from complete, and in particular it doesn't contain a subdirectory .../res/fairy/wolf. But the library does. For some unfathomable reason the piece that looks like a somewhat demagnified archbishop has become known under the name wolf, and a grep on fr-wolf in the chessbase directory of the library shows that it is used in several of the CVP games under that name. Amongst which Spartan Chess.

I guess that when I did the backporting (as Spartan Chess is one of the games that is already backported) I chose a more sensible name, as the spartan-chess-model.js refers to the 'aspect' of that same piece as fr-proper-cardinal. So there is no collission at the (backported) source level with your wolf piece. I will just have to fix the collision in the library. (But since there seem to be no games that use your new wolf now that you changed Wilde Mirza, there is no hurry for that.)

The Crowned Rook is another problem, though. The master branch of Jocly at github already included a fairy/crowned-rook when I cloned it to create my own branch on top of it. You now made a new one, and the crowned-rook.js file collides with the existing one. By coincidence the *map.jpg files don't. Only Gigachess II seems to use this new crowned-rook, though. So I guess I will just let it use the 'official' one, and make duplicats of the corresponding *map.jpg files with an extra hyphen to let your code use the maps that belong to that shape. If you want to keep your design I recommend you pick another name for it, so that your fork can be merged with the master branch without collisions.

I think It is important to keep only one crowned rook for all.

I don‘t mind using the existing one but mine is also a good candidate because I obtained the agreement from Zied Haddad and Jerome choain to use their design from musketterchess/jocly. It should be consistent with the rest of jocly.

Which variant uses a 3D crowned-rook ? Would they really be annoyed by moving to the new official one ? I mean comming from : https://musketeerchess.net/p/tools/boardpainterV2/

I don't know who decides what can be added to the master branch at github.

I use the crowned rook in Spartan Chess and Elven Chess, and I would certainly keep using the old one. The difference with an ordinary rook is much more obvious. Furthermore, it fits better with the other pieces I use, where the head of Staunton king is an obvious clue the piece has K moves. (See the 'New piece show case" in the CVP Jocly install.)

I suppose there must be variants that aren't mine that also use it, as why else would it already have been there?

The Musketeer version of Jocly is proprietry; who cares whether it differs from the official one?

It seems that the master branch at github is not active anymore. Your git could become the new master. I didn‘t understand how to clone hgm branch yet.

I’m ok to use your crowned rook but I could also rename crowned-rook2 if you consider usefull to keep a coherence with the other crowned pieces.

I didn‘t understand where to find the 'New piece show case'.

I was given the autorisation to use some pieces from the Jocly of Musketeer inside the opensource jocly. So these pieces can be used in an opensource jocly : squirrel, wolf, giraffe + crowned pieces. It could save time for porting some new variants to jocly.

I would like to add a duchess from this kind of model : http://biscandine.fr/variantes/pieces/t4/blanc/2-femme%20fatale*1.stl https://www.thingiverse.com/thing:6055174 Could you give me help on how to export a diffuse map from a stl with textures for jocly?

It should be possible to add my repository to your git as a remote source, and then pull the hgm branch from it. You could then rebase your branch on top of that. (Which will probably require resolving lots of conflicts.)

"New piece showcase" is one of the "other Jocly games" you can select from the CVP Jocly installation.

Apart from adding new games I did make some enhancements to more basic parts of Jocly, such as the base-model.js (e.g. to allow multiple royals), and even deep in the Jocly core (for animation of multiple capture, and improved trajectory of bent sliders so they do not move through other pieces). So it would not be a bad idea to make this the new master branch.

We will have to solve one problem to prevent a regression, though: to make repetition detection work correctly I had to change the way base-model.js calculates the hash key. (The old way would consider a position different if two identical pieces swapped location, and in games with piece drops this happens a lot.) But the hash key was also used to probe the opening book, so that change made the existing books useless. Recreating the books with the new hash key doesn't seem possible; the program to create the books was not released with the rest of Jocly, and should be considered lost.

Now only Chess and Xiangqi have a book. So we could keep a version of base-model.js that calculates the hash key the old way, and only use that with Chess and Xiangqi. That is not very subtle, though. Another way is to include the routine that calculates the hash key in the *-model.js files for these two games, and set it up such that they use that to overrule the key calculation in base-model.js.

I am afraid I will not be much help with .stl files, or editing/creating 3D pieces in general. As I explained in my reply to Jean-Louis I never got any further than understanding how the piece.js files of Jocly encode the pieces, so that I am able to distort existing shapes by altering the coordinates of the mesh that defines their shape with a text editor. Altering the maps so far was beyond my capabilities. (Well, that is not entirely true, as these are jpg files that could be edited with MS Paint, but that does not produce the subtle hue gradients you need to make the resulting piece any good.)

It appears I have solved the book problem in my Jocly fork; I made base-model.js support both the old and the new hashing scheme. The latter is used by default, but an extra parameter in the game definition:

zobrist: "old"

can be specified to force use of the old one. I made Classic Chess and Xiangqi use that to make their opening books work again.

This means I can now continue adding more of the games I implemented. (Mini-Shogi, Tori Shogi, Chu Shogi, Tenjiku Shogi.) And that it then will be suitable as a new master branch.

@Fergus: Can you please refresh the CloudFlare cache? A few days ago I added several new chess variants to the Jocly implementation here, and amazingly enough they appeared for a while in the jocly-allgames.js file shortly after that. But now they disappeared again, unless I access that file with nocache=true query string. Which Jocly itself of course does not do.

Can you please refresh the CloudFlare cache?

Okay, I purged the whole cache for chessvariants.com.

Okay, I purged the whole cache for chessvariants.com.

That fixed a (completely unrelated) problem that I was having, too. :)

Good news

The number of chess variants implemented in Jocly raelly starts to explode, and with it the size of the src/games/chessbase directory. (As each variant has several filles there: a model and a view, a thumbnail, a description, credits, rules...)

Perhaps we should make a cleanup attempt, where we create a sub-directory in chessbase for every variant, and move all files related to that variant there. That would make the sources a lot less messy. An alternative would be to put a modest number of variants that are somehow similar into a single sub-directory. E.g. all 10x8 chess with BN and RN, all variants invented by the same person, etc.

We should also decide on how to organize the res/fairy directory for new pieces. Perhaps it is a good idea to put pieces that are only slight variations on each other in the same subdirectory. I have for instance added many resized pieces (which can continue using the same normamap and diffusemap), to get a better correspondence between size and importance in many games. The alternative crowned bishop and crowned rook could likewise share the directory with the existing versions. When I create a distorted version of a piece (which also can use the same maps) I also put it in the directory of the piece it was derived from.

I agree, I prefer to group the files by familly of variant : sometimes like src/games/chessbase/1212 src/games/chessbase/108 src/games/chessbase/1010 src/games/chessbase/88 src/games/chessbase/14+ src/games/chessbase/3d

It would also be a good idea to group into a subdirectory all the ressources for a piece. It could be interesting to be able to find the correspondance : name / icone into the Piececlopedia.

how do you see the refactoring being done?

Transferring the files from chessbase to a subdirectory is not very hard. I just tried that for Shogi, where I now have Shogi, mini-Shogi and Tori Shogi in a single subdirectory 'shogi' (and am currently working on adding Chu Shogi). I just pushed the commits to the hgm branch of my on-line repository. It is just a matter of moving the files (which are already named to coexist in the same folder) to a newly-created folder, and change the modelScripts in the index.js file to point to those. And commit the changes to git.

This index.js file is also becoming unwieldly; there is nearly a full page of stuff for each game there. It would be much better if that stuff was in separate *-config.js files stored with the model and view files. This would require changing the building process, though, and I have no idea how that works.

I just realized that jocly-board won’t be able to handle the subdirectories which is annoying.

What is jocly-board? Is that built from the project? One would expect it to use the library rather than the sources. There the config, model and view files are still all in one directory.

Anyway, I did some grouping. There now are directories shogi, 3d (2), hex (5), circular (3), mini (7), capa10x8 (3), tressau (2) and cazaux (5). I will probably add 'historical' as wel. Janus Chess should probably go into capa10x8, Los Alamos Chess into mini, and Wild Tamerlane in cazaux.

During testing I noticed that the new zobrist scheme broke Metamachy, because it is still directly calling the old scheme from its model code, to calculate keys for the initial setup. I will fix that later.

Joclyboard is an offline desktop application https://github.com/mi-g/joclyboard quite convinient

Ah, OK. But I see it is open source. So it could always be changed to do whatever is needed.

I doubt that something would be needed, though. The model and view files for the various games in src/games/chessbase would not work on their own; they must also use underlying models and views for piece sets and boards. The only place where it is indicated which piece set or board model must be used for a given game is index.js. And the latter contains the path name of the models and views specific for the games.

But that is assuming that jocly-board uses the source code. Building Jocly does not only create a library in dist/browser, (where for each game all required model and view files are combined, and put into dist/browser/games/chessbase in compressed form), but also in dist/node. I never used the latter (I always test the builds through the browser part), but I suppose this is intended for any off-line application.

Usually I copy jocly/dist to joclyboard/app/node_modules/jocly/dist

but you are right, I should investigate more since It should be fixed easily if it is confirmed

Usually I copy jocly/dist to joclyboard/app/node_modules/jocly/dist

but you are right, I should investigate more since It should be fixed easily if it is confirmed