Comments/Ratings for a Single Item

I will check that in the evening

for the terror : zip initial version and zip tested on my env

I still had a file dragon2.js in the terror directory, and when I renamed that things worked again. It was totally different. I guess I tried to download the file directly from GitHub when I committed the addition of the Terror, using wget, and this appears not to work. In fact accessing GitHub from the machine I develop Jocly on seems broken; I can for instance also not get to the joclyboard page. The browser then displays a blob page without content, and a waiting symbol that lasts forever. To get joclyboard I had to download it on my Windows PC, upload it to some website, and download the tar ball from there.

[Edit] OK, so I have JoclyBoard, now what? I can run it, but it does not offer any of the new games we made. And there seems to be no documentation on it at all.

Jocly v0.9.13 is the version they published after the recent pull requests. Joclyboard, which was broken, was recently repaired and now includes this version.

We are working on the next version 0.9.14 ? Joclyboard 0.9.14 will carry it.

Now (with gulp 4 et nodejs 18) we can work on any machine even a windows desktop as long as nodejs 18 is installed.

I use joclyboard to test (I copy fresly compile dist directory in joclyboard/app/node_modules/jocly) : thmbs, visuals, the 3 html files ...

You can access the documentation via the rules, credits, about button (test from this morning).

This is what they will use for each variant before accepting the next pull request. I also believe that the html and images will be used in the next mobile application.

I don't know if it's still time to talk about that. I have a new candidate for the 2d hawk sprite: a Falco peregrinus.

@Jean-Louis : Do you like it better than the aquila. Would a rounder eye be better?
@HG : At least if it was selected. It would be better to modify the sprites file on your side. It's up to you to decide to keep it or not.

@François: Yes I like this one better than the Aquila to represent the Hawk.

A rounded eye will look less aggressive, but it's up to you, I will like both designs

You can access the documentation via the rules, credits, about button (test from this morning).

That button only gives me the documentation on the currently selected variant. But I cannot even select that variant. What I need is documentation on how to use JoclyBoard.

if you install the expected version of node on another computer  while waiting to solve the problem :

https://nodejs.org/download/release/v18.19.0/

then you could clone http://hgm.nubati.net/git/jocly.git

then npm install

Turns out there also was a cbMoveMidZ definition in grid-board-view.js, which overrules that in base-view.js. So I made the improvement there. I think the new version should almost always be satisfatory. I just have to solve one tiney problem: when a piece slides to a destination a (2,1) leap away, the animation takes an orthogonal step first, This is wrong for the Griffon. (For more distant destinations of bent sliders it takes the smallest leg first, which is always OK.) I should still implement some guidance there, as it should be clear from the move graph what the first step of the move was.

I haven't had time to test it, but all the changes have been uploaded to github.

The only info I got is from https://github.com/aclap-dev/joclyboard

Note that there is a hidden(collapsed) menu at the bottom of the page when you play to control parameters.

I haven't gone into the details yet. But I'd like a few clarifications to make sure I understand.

Does this mean that when it's finished, I won't need to implement cbMoveMidZ in the views for standard variants built from a FEN string? Or is it broader than that, e.g. all variants that use fairy-move-model?

By the way, if you think it is usefull, I can make a documentation on how to use joclyboard for dev from scratch in the latest version.

Concerning the hawk/falcon visual, I asked Jérôme for help because I couldn't manage to make a decent one on my own. Here are his suggestions. what do you think?

They are ready to use, personnally I prefer the one with round eyes.

If usefull for minjiku or any other of your shogi variant, I Can send you the fortress / tiger piece which have beautifull visuals in 3d.

Does this mean that when it's finished, I won't need to implement cbMoveMidZ in the views for standard variants built from a FEN string? Or is it broader than that, e.g. all variants that use fairy-move-model?

The new default cbMoveMidZ for grid boards should be satisfactory for any variant with pieces that do not move too strangely, no matter how it was defined or whether it includes fairy-move-model.js. The algorithm I use is

1) if the distance moved (as according to the geometry, i.e. measured in King steps) equals 1, it slides.

2) It examines the move graph of the moved piece from the given square, to find the move's destination in it.

3) If the destination is the first square on a path, jump

4) If the destination is reached through other squares, but the move is a capture, and is indicated as a screen capture: jump

5) Slide, but if the first step of the path is not orthogonal, use a kludge that I buld into the animation function in Jocly's core to request diagonal preference as tie breaker.

One of the improvements I made in the animation function is that in case of sliding it splits oblique moves into an orthogonal and a diagonal leg, and then first animates the shortest of those, and then the longer, each in half the time. This to prevent Griffons and Rhinos to blunder through other pieces. But when the two legs have equal length (as on a (2,1) move), it would normally prefer to take the orthogonal leg first (as for the Xiangqi Horse). But cbMoveMidZ can revert that by specifying an invisibly small negative hop height. This is needed to also get the Griffin move to the N squares right.

I think the algorithm would break only if a piece has multiple ways to get to a square.

If usefull for minjiku or any other of your shogi variant, I Can send you the fortress / tiger piece which have beautifull visuals in 3d.

Apart from Minjiku Shogi (which does not feature a Tiger) all Shogi variants use kanji tiles. It would be nice to have a 2d Tiger, though, for the Chu Shogi (and later Tenjiku Shogi) Blind Tiger. I now use a Buffalo for that...

That's a nice present for Jocly.

This means we can test it simply by commenting cbMoveMidZ in a view like bigorra-view.js, which contains almost all the pieces.

right?

This means we can test it simply by commenting cbMoveMidZ in a view like bigorra-view.js, which contains almost all the pieces.

Exactly. This is what I did for Makromachy, which also has a very diverse set of pieces, to test it. I just pushed the thus debugged version.

I am having some second thoughts about this old patch of the animation routine. This was in base-view.js, btw, so only affecting chess variants. But this code is also used by hexagonal variants, or variants with irregular board topologies. There the way I use to detect oblique slides, and break them up into on-ray legs, would not work at all, and probably break things. The original default cbMoveMidZ at this level would always slide. Only when you use a grid board this would be overruled by one that jumps for all obliques, and slides otherwise (and which I now replaced by a more advanced one).

So this animation patch in its current form is probably not acceptable for Jocly in general. The animation routine consults cbMoveMidZ to calculate the trajectory along which it will move the piece during animation. So a solution would be to only break up the trajectory into two legs when cbMoveMidZ requests this, as each board topology would have its own cbMoveMidZ. So the latter would then not only be used to define the Z coordinate half-way, but also the (x,y) coordinates.

Since the (x,y) path of a move that hops over other pieces is irrelevant (and thus can be the normal straight line it is now), we could use negative value of the number returned by cbMoveMidZ to specify the intermediate for a slide. (I cannot imagine you would really need jumps with negative height...) E.g. minus the number of the square over which the slide should go, minus 1. Then a jump height of 0 would indicate a normal slide, as the original use of cbMoveMidZ intended. The default cbMoveMidZ for the grid board would then recognize oblique slides, and determoine the intermediate square itself. I guess for the moment it would be good enough to just take the first square on the path as the intermediate. That would work for Griffon, Rhino and Osprey.

It would even work somewhat for the Grant Acedrex Unicorno (which would squeeze itself between the pieces shielding it from its first target). It might even be nicer if in that case (i.e. a path starting on a non-adjacent square) would be animated as a jump in the first leg, followed by a slide. That would also be good for the Osprey. The animation routine would then have to determine a default height for that, though, as the value returned by cbMoveMidZ would indicate the horizontal intermediate. Perhaps we should make it possible for cbMoveMidZ to return an array, with both a height and an intermediate.

I have to say I'm going to defer to your analysis because, apart from distinguishing irregular board from regular board, I wouldn't really know how to go about it.

@HG and François: Congratulation for your work on Jocly!

A remark on the 2D icon for the Snake. It is a cobra's head seen from face. But when reduced at the size on an icon on a board, it is not straightforward that it is a snake. It looks like a sort of racket or a balloon or... Well. Why don't you use the icon which is used on Alfaerie (maybe drawn by HG?) which is much clear imo?

It might be a bit early to test, but I thought it might help to get some initial feedback.

Jean-Louis helped us to check the moves on bigorra without custom cbMoveMidZ in the view:

Snake: When the Snake does a non jumping "Knight" move (2,1) to its right, and only in this case, it starts by the diagonal step prior to the vertical one, which is wrong.

Rhino: sometimes, it starts also by the diagonal step when making a non jumping Knight move. But not always, it depends on the square it starts! (For example Black Rhino on j11 to go on k9 or k13)

Camel: it's sliding, not jumping Sorceress,

Canon: sliding for capturing instead of leaping (Archer is correct)

Marshall: does the opposite: slide as N and leap as R

By the way, I posted the hawk sprites may be a bit too early. It is better to retrieve wikipedia-fairy-sprites.png to avoid a clash on the binary file before the next pull command.

I agree the Snake icon is not very good. (My fault, I made it.) The Alfaerie one is much better. I was hesitant to grab Alfaerie icons, though, as the piece set Jocly uses is really CBurnett.

Snake: When the Snake does a non jumping "Knight" move (2,1) to its right, and only in this case, it starts by the diagonal step prior to the vertical one, which is wrong.

I noticed that too. I made some changes now (and already pushed those), both to the cbMoveMidZ default for grid boards, and the animation routine that uses it in base-view.js. This should cure any problems the previous animation patch had with hex boards. (Assuming no one would use jump heights -1 or -2 there.) And as far as I could see it now does all Griffon/Ship and Rhino/Snake moves correctly. As to the Osprey and the Unicorno there still is a problem that it makes the first leg a slide too, even though it really is a jump. In both cases over the Wazir squares.

It is a bit hard to let cbMoveMidZ tell the animation routine that the first leg is a (possibly oblique) jump, as the animation works purely in pixel coordinates, not in terms of board squares. Perhaps I should allow fractions on the -1 or -2 that request bent trajectories, for indicating at fraction of the long side of the rectangle containing the move would be the start of the animation, and possibly jump there if that is not immediate. E.g. a Snake (2,3) move would require a hop height -2 for ordering an orthogonal-first bent trajectory (so via (0,1)). But if it was a Unicorno using a hop height -2.666 could be taken to mean that the slide starts at 2/3 of the 3, i.e. at (1,2), and (ideally) that it should first jump there.

I redeployed your change.

@Jean-Louis : do you have time to take a look?

Jean-Louis confirmed that the patch solved the moves for Snake, Rhino and Sorceress.

Camel, Marshall and Canon remain to investigate.

For now it is probably best to let pieces that do not purely slide oner a contiguous trajectory jump directly to their destination. So that would not only apply to pieces like Ospray and Unicorno, but also to ski-slides, and Dababbariders. The heuristic would base that on the size of the first leap in the trajectory.

That's fine with me.

I'll initialize a western skin2d with your sprites for the mini shogi. I'll send you a zip and let you commit it to make sure you're happy with it. That'll give you time to work on the movements and the missing pieces (samurai) ... if you're up to it.

"Camel, Marshall and Canon remain to investigate."

For Camel, just do as for the Knight or the Giraffe.

For Marshall, just invert N's part (should leap) and R's (should slide)

For Canon, just do as for Archer and Sorceress.

For Camel, just do as for the Knight or the Giraffe.

For Marshall, just invert N's part (should leap) and R's (should slide)

For Canon, just do as for Archer and Sorceress.

All these pieces already work for me. (Tested in http://hgm.nubati.net/jocly/jocly-master/examples/browser/control.html?game=makromachy )

Jean-Louis tested here :

http://biscandine.fr/variantes/test/examples/browser/control.html?game=bigorra-chess

Here is a draft for a western 2d skin with your sprites (you can retrieve for local checking or I can commit it if you find it more convinient)

You can see it here for : shogi and mini-shogi (select 2d western first)

Note that we will probably create a 2nd pull request after the big pull request we are doing.

So it will probably be possible to fix some icons and to comment some cbMoveMidZ functions later.

Jean-Louis tested here :

http://biscandine.fr/variantes/test/examples/browser/control.html?game=bigorra-chess

Well, it appears that this contains a very obsolete cbMoveMidZ, (from more than 3 versions ago), which never worked. It uses a forEach to loop through the piece types, and apparently that doesn't work on an object. So in the first working version I replaced it by a for(in). Strangest thing is that the version with forEach is not in git; the very first commit for cbMoveMidZ already uses the for(in).

BTW, about piece naming:

'Squirle' is not the correct English spelling for Squirrel.

There are already two spellings around for the Griffon / Gryphon. Let us not add to the confusion by now also introducing Griffin...

Wouldn't it be better to call the Huscarl just an Axe? Huscarl is not a widely-known word. I had to look it up, and it is not something that I would think of if I needed a piece that looked like an axe.

sorry for the inconvenience, I'll check and update

Here is a draft for a western 2d skin with your sprites (you can retrieve for local checking or I can commit it if you find it more convinient)

Nice to have it, BUT:

I am not so keen on upside-down western pieces; there is no need for it, as they are already distinguished by color. And is not compatible with board flipping ('View as player B'), because it is then the other player that should be flipped. (This is of course also a problem with kanji pieces, but why export problems if there is no need?) And the generals are not flipped anyway.

If I promote a piece, the dialog that pops up still shows the kanji even in western mode.

I've updated the link with the returned black pieces. Feel free to make any changes you like directly.

For me it's acceptable to have temporarily the promotion dialog that displays the kanji even in western mode. As far as I'm concerned, it's still understandable. Maybe we'll find a solution soon. I'd prefer to be able to play with this skin for beginners right from the start.

Congratulations for the 3d samurai.

I remove Griffin.png

It is better to refactor Squirle to Squirrel.

I prefer Griffon, I don’t know what is the best word in english.

I renamed the glidder in Huscarl because it reminded me of the Scandinavians who had axemen (vikings). But Yes we can refactor to axe ou axeman.

I will start to refactor Squirrel and axe.

PS : Is it allowed for the jumping general to go to the black line? same level as the brouhaha squares?

I now adapted all chess variants (I think) that accessed the Zobrist API directly to using the new API. This were Metamachy and Leychessalpha (for setting up a user-selected initial position), Shafran Chess (for performing a non-standard castling) and Modern Chess (for performing a Bishop swap). I could not find any other files that contained the word 'zobrist'.

I think this is necessary for making the Zobrist patch acceptable for inclusion in the master branch; in the pull request we will prepare these commits must all be squashed together with the actual change in the API. Which must be one of the first things committed, as variants that I committed later rely on the new API.

I tested all the games, and the actions for which the Zobrist API is accessed all worked without problems. I have not tested whether this actually produced the correct key. For setting up the position this is not even theoretically possible, as the variants that do it have no opening book that requires a correct key to probe it, and the start key is completely arbitrary anyway. So the whole key-update rigmarole is in fact completely futile there. And even if they had an opening book it would have been sufficient to just use a different arbitrary key for each of the start positions the user can select.

You are right, I think that zanzibar-s is also concerned since it is a metamachide variant

A yes, I overlooked that one. (And the old code was buggy as well, so it is a good thing that it served no purpose.) And Chess960. I now did those too.

After a test, I can confirm that it works.

Check the jumping general in minjiku when there nothing between him and the black line. Not sure it behaves as he should

Check the jumping general in minjiku when there nothing between him and the black line. Not sure it behaves as he should

You mean jump/slide-wise? I guess this is a tricky case, as the Jumping General both has 'screen capture' as well as normal capture. As soon as the default routine finds a move to the destination in the graph that has screen-capture rights it decides to jump. It doesn't actually test whether there is something to jump over.

I consider this acceptable behavior. A Dababba (or Knight) also jumps if there is nothing to jump over.

I was wondering if He can go to the black line like here for instance

I commited the refactoring of 'Squirle', Griffin, Axe.

I've left the western 2d skin code so as not to lose it, but I've commented it out in the views in the index so as not to activate it.

I looked at what I could do to help next. I noted that we could change the visuals for mortar (cannon2), phoenix and cobra in team mate.

I can also look for a trick to change skin for the promotion boxe on shogi.

Otherwise it could be on the doc. or testing cbPiecesFromFEN on 12x12 board. I've got a bit of time today. Let me know what you would consider usefull.

I tried to reorder commits in the trial branch yesterday, to get patches on the same feature together so they can combined, with teh aid of "git rebase -i". This turned out to be a disaster. There are now hundreds of commits, and even when I use the "git rebase -i" without re-ordering anything, it complains about conflicts. By now there are hundreds of commits, and nearly everyone of those complains about a conflict in fairy-set-view.js, in which it then has added dozens of lines to indicate where in the file the conflict is, which you all have to edit out to get the version you want. I spent about five hours yesterday doing that, and ended up with an utterly destroyed source code.

One of the problems might be that commits got duplicated in the process of pulling repeatedly from each others repository, and that I have to skip those rather than apply them. I will make another attempt today, on a freshly copied branch.

You could also start a new branch just copying sources from https://github.com/fhoudebert/jocly/tree/trial It would squash everything in one commit while retaining your authorship on your shogivars.

I can also rebase my trial branch if it helps. I used to do it before always and stopped because it became fastidious.

in the meantime I'm going to overide cbCreatePromo in shogi-views because the alternative skin seem a must have for me for shogi

Well, for most of the history the source was very much corrupted, because you apparently do something wrong when resolving merge conflicts. When such a conflict occurs, git writes <<<<<<, ===== and >>>>> markers in the conflicting file(s), to offer you an opportunity to select the competing outcomes of the merge on which git could not decide automatically which was the right one. The idea is that you then solve those conflicts by editing, in any case removing all markers, and leaving in only the content that should be there (which sometimes is neither or both the alternatives). Then you can continue the merge to finish the conflicting and the remaining commits. It seems you never do that, though, and just continue the merge with all the cruft in it. Which would of course make the project unbuildable. It is furthermore extremely confusing for someone trying to merge the branch later that he finds lots of conflict markers which are not a result of his own merge, but were already contained in the files. When he removes those as he normally should, git will keep nagging him with new conflicts, because it now thinks the conflict markers actually belong in the file, while you had removed them.

Anyway, in the past few hours I managed to do a new rebase of (a copy of) the trial branch, (without re-ordering anything yet) for each conflict consulting the commitdiff of the original commit. And this eventually produced a result that was pretty close to the head of trial; just 4 missing pieces in fairy-set-view.js, a corrupted terror.js and some whitespace differences in index.js. I added three commits to fix those, and now only some whitespace differences in index.js remain. (I don't know how to remove carriage returns that are apparently originating from editing on Windows...)

The good news is that when I now repeat the rebase (still without reordering) on this repaired branch, it succeeds fully automatically in a few seconds. And I don't think any of the intermediate states of this new branch contain conflict markers (which could cause problems after re-ordering).

When I had conflicts, I usually replaced them with the original source, as they were binary files most of the time, so as not to make you lose your changes, even if it meant deferring mine. I'm sorry if I've made any mistakes, I'm not a git expert. Anyway, we shouldn't have to modify the same files anymore. Concerning the carriage returns I don’t know where it comes from since I have edited on linux only. Note my trial branch should contain all what is published on your branch.

For the promotion box in shogi, It is possible to use the sprites associated to the selected 2d skin

ex : shogi with 2d western

we don't need to redefine cbCreatePromo in the views concerned, a modification in base-view.js is all that's needed                                            

I am still working on selecting what patches are ready for inclusion in a pull request, and which still need to much work. Unfortunately there turned out to be still some problems in fairy-move-model that surfaced when I refactored Elven Chess to use it, and debugging those took more time than I had hoped.

One of the remaing issues in your patches is that you included fr-rhino2 and fr-cobra in the cazaux/timurid series, and that I think these pieces (although improvements of what we had) are still not up to standard. How about the following Rhino:

Is this better? I now extended tube.c with the possibility to distort the rings you define in more ways than squeezing them to ellipses, and tried to use that for creating a more plausible cross section for the snout. What I do is modulate the radius of the ring as we go around it from phi = 0 to 360 degrees by multiplying it with (1 + a_n*cos(n*phi)) for n = 1 - 5, with a_n some constants specified per ring that by default are 0. In lowest order the n=1 factor does the same thing as displacing, and n=2 the same as the elliptical distortion, which we already had. (For large values of a_n there is a difference, though: a_1 gives you a 'banana distortion', and a_2 an 'hour glass'.) For n = 3 and 4 you get triangular and square distortions, which I used here to flatten the top of the snout (a_4 = -0.15) and broaden the lower jaw (a_3 = +0.05).

Yes, I find this rhino better. But this addition shouldn't be a blocker. We could ask Jérôme to remake a rhino1 with a 3d model of Jean-louis afterwards.

Note that 2 branches are availables

1-fairySet exactly the same as pullreq for the 1st pull request

2-shogivars to send the rest 2 weeks after 1 is merged.

For me branch pullreq miss only : migration to gulp 4, and minor changes on index.js : thumb on werewolf/minjiku-shogi/makromachy or path for credits in shogis.

And possibly more documentation on certain new variants or visual changes (team-mate) with new pieces.

And we could therefore send them a pull request soon.

I can send a mail to give them more context anyway.

I now also applied a quadrangular distortion to the Cobra, to make the body thicker and the 'wings' thinner. The old one really looked too flat to me, in side view.

Anyway, I think this one looks passable.

As to the gulp 4: I temporarily reverted that upgrade, so that I can still build Jocly. The idea is that when we are satisfied, we just remove the commit where I did the revert from the branch, just before sending the pull request.

Perfect

Hello

Yes this Rhino is better. However, it doesn't have the same quality than other pieces yet. I understand it is very difficult to design for this package, but I would explore a not-bending head (kept it horizontal), with a shorter length, and a sort of rounded profile at the head's back to avoid a neat cut.

OK, I have pushed a new pullreq branch, which is fit for pulling into master. Actually my commits after the Berolina Pawn are not so important, as the new pieces there are not yet used by anyone. They also still need some improvement. But the patch on the fairy sprites that follows them is important, and cannot be easily permuted with the new pieces, as these all touch fairy sprites.

I took out Chu Shogi; this still needs some work. Perhaps that appies to all Shogi variants.

Since I have also removed the gulp revert, I could not test whether the final version still builds and works.

I was a bit hasty, late yesterday night, and when I set up things again this morning so that I could build it turned out variants useing fairy-move-model.js did not run at all because I had written sqrt instead of Math.sqrt somewhere in it. I also discovered and fixed a bug in Werewolf Chess. (It is a trap that Jocly counts pieces starting at 0, and indicates in move.c either the number of the captured piece, or null if it was a non-capture. So you really have to be careful to distinguish 0 from null to know if the move was a capture. In the version of Werewolf Chess that I refactored to use fairy-move-model.js, it turned out that one of the Werewolfs became piece number 0, so that its capture, and hence its contageousness, went unnoticed...)

The version of pullreq that is now in my repository does build and run.

You probably have locally

chu-shogi-view.js

chu-shogi-model.js.

They are not yet added to the branch

Umm, I removed the Chu Shogi commit from pullreq, but it appears that its specification in the index.js was already added in the Makromachy commit (probably as a consequence of resolving a collission during rebasing in a wrong way). Since I clipped off the commits I did not want in the pull request with "git reset", the involved files were kicked out of git, but stayed on my machine. So I got no error when building.

I now amended the Makromachy commit, to not add Chu Shogi as well in index.js, and pushed the entire branch to my repository again.

Please note that this does not contain any of the commits you did after I started reordering and combining things. (Such as renaming fr-griffin and fr-squirrel.) You could 'cherry-pick' these into the pullreq branch.

All Shogi commits are a bit immature. (No credit, description or rules files.) Perhaps we should postpone release of all of those?

It builds ok for me too A few additional finishes :

I added 2 commits :

1/refactoring squirrel, griffon, axe + minor changes for documentation

2/replace aquila by falcon head

Do you think that we can make the pull request with this branch fairySet?

I can help if it is usefull : rules for mini-shogi for ex.

Are you OK to send a pull request with this branch fairySet ?

Well, Shogi docs might require a lot of effort, as we have no visuals of the kanji tiles, and there are a lot of different pieces in Shogi. But I think what we have now is worth a pull request.

Some of my recent experiments:

Cannot think of a way to fit them well on the pedestal, though...

When I'm facing this problem in Tinkercad, I follow one of two options:

1. Move the head forward until the back of the neck matches the back of the platform, then just deal with the overhang and nigh-guaranteed balance issue.
2. Shrink the head  (it looks like about 75-80% size would do for these) and devise some kind of shaft or pillar to fill in the veretical cap.

I recommend the second one.

If chess is a war, here is a way to put a ram on its pedestal :

The pull request is sent : FairySet

I've started a draft doc for shogi on this branch. Of course, it's just a proposal

It doesn't look so strange if the neck runs all the way to the bottom. But that only seems a solution for a Giraffe...

Perhaps if I make the pedestal elliptical? The piece has to be downsized a bit anyway.

[Edit] This doesn't look so bad:

This doesn't look so bad:

I'd want to see it from a 45-degree front angle to be sure, but I think it actually looks pretty good.

The head is OK. The neck and the way it's connected on its base is not.

https://www.thingiverse.com/thing:6413054

Well, apart from the head looking down it doesn't seem very different. The neck attaches in the same way to the pedestal, but has to be much longer, which seems unnatural. Unless you imagine it not to be a neck, but part of the body. In that case the rest of the body was chopped off. So I wonder how it looks from the back.

Tilting (or lifting) an entire upper structure is one of the features the Tube program already implements. The question remains how to handle the back side of the connection to the base.

Tilting the head the other way, like the image on the pillar below, would avoid such problems.

Having it look down would give me this:

Looking up this:

I think I like the latter better.

from Michel :

Great, there seems to be a lot of good stuff in this PR. Unfortunately, I won't have time to review before I leave, it'll have to wait 3 months. But in any case, you can use your branch to run these new games in a site.

Congratulations again!
/mig

OK, so be it. It will give us the opportunity to perfect what we have. Such as docs for the shogi variants. I would also like to use a real Stork and Goat in Scirocco, instead of the shrunken Eagle and Antilope. And perhaps refactor Makromachy to work with cbPiecesFromFEN.

I am also wondering if we should not combine nearly identical variants. For Metamachy there is a 'prelude', where the black player first has to choose one of 12 different setups for King, Queen, Lion and Eagle. That is a lot better than having 12 different versions of Metamachy in the index. Similarly, Musketeer Chess starts with a prelude where the players first have to pick the exotic pieces they want to participate. This also avoids the combinatorial explosion of variants one would otherwise have.

I am worried that in the long run we will get congestion in the 'Other Jocly Games' list; one-step selection has its limits, and by combining sub-variants that only differ in initial setup or in whether you already start with a promoted version of a piece would be a simple method for implementing two-step selection.

So wouldn't it be better to combine the 'wild' timurid variants into a single game? After all, Wild Tamerlane is hardly an independent game; virtually all positions in its game tree also occur in the game tree of Tamerlane II, after promotion of a non-Pawn. So an implementation of Tamerlane II must already be able to play Wild Tamerlane. We might as well use the same implentation for it, that first asks whether you want to play 'wild' or basic. And if we are at it, it might as well ask whether you want to replace the Queen by a Lion or Wolf, in addition to replaceing the Ship.

Btw, this is an up-looking Goat (The Tube tool can now also use a shear transform to spread out the ears!):

For anything but a Ram (such as that Goat, which looks nice) I'd agree that up is better. Isn't a Ram's usual thing for battering down, though, as an Advancer?

I wonder how the downward version would look if it was tilted down 15° less (or even 30°), with the neck tilted 5° forward.

Yes, we could complete the version : fairySet  even if he may be quicker than he says . There are also a few commits to pull.

We could change some visuals for scirocco and also maybe to team-mate?
The Addition with chu-shogi?
Documentation of shogi (draft here), do you want to add the western 2d skin to the pull request?

For timurid chess, It's a good idea, see how it could be done. Loading from a fen string following canvas selection?

Your goat look nice.

I agree with HG on Tamerlane II family.

And, very nice Goat!

We could change some visuals for scirocco and also maybe to team-mate?
The Addition with chu-shogi?

For Scirocco I would definitely want to put in Goat and Stork. And amongst the promoted pieces is a Squirrel, while the promoted King (Emperor) could be replaced by a Champion. (As this is how it moves). For the Lioness I now use a Lion, but perhaps a Leopard would be better. OTOH, it seems that most people now call the KNAD piece a Lion too, despite the difference with the Chu Shogi Lion. The Spider and the Octopus are subtly different Rhino and Griffon, and perhaps should use the improved versions we now have for those. But then again, Stork and Goat are just as subtly different from Phoenix and Kirin, and we would use different pieces for those. But for now we don't have a real Spider or Octopus anyway.

In Team-Mate Chess I could use the Phoenix. Difficult to decide what to do with the W-then-B piece, which is called Acromantula there (a mythical monster spider).

We certainly should add Chu Shogi

Documentation of shogi (draft here), do you want to add the western 2d skin to the pull request?

I'll have a look at it tomorrow.

For timurid chess, It's a good idea, see how it could be done. Loading from a fen string following canvas selection?

I suppose we could learn from Metamachy how it is done, and copy most of the code from there. I think it would be simplest to set up the board from a FEN without the variable pieces, but place those on a 13th rank to make sure their types are included in the list. Then 'Applying' the selection 'move' would simply place the selected pieces.

A subtle difference with Metamachy is that when the computer plays black the pieces are randomly shuffled, rather than having the user select the setup, as this is black's prerogative there. Here we always want the user to select, even in a Comp-vs-Comp game. I am not sure if this is going to be a problem. Normally you don't start in Comp-vs-Comp mode, but with the user set to play white, so that the computer will not immediately start thinking. We could make it such that when the computer plays black it uses the setup that was last selected, even if that was in a previous game, rather than randomly picking a new selection (as Metamachy does).

Perhaps we should create a new sub-model, 'prelude-model.js', which handles most of the stuff now in metamachy' model and view files, so that any variant with some sort of prelude can draw on it. Metamachy creates wrappers for many of the chessbase standard routines, sometimes only to do something very trivial (like copying an extra proprty in the game state). These tasks could probably be done in base-model.js always, without unduly burdening it in variants without prelude. In fact I don't think the game state needs a 'setupState' property at all; the 'lastMove' property it already has could conveniently be used to communicate which stages of the prelude have already been performed, e.g. by negative numbers in the lastMove.f field.

It should also be possible to provide a table-driven version of a routine that creates a popup showing a number of groups of piece icons, from which the user then can select one to cause calling of a custoSetup routine with the number of the selected setup as a parameter.

If a 'prelude-model.js' is created, I'll try to use it to set timurid parameters, which will allow the declinations to be merged.

@HG: I react to this about your ram: "Well, apart from the head looking down it doesn't seem very different."

I guess we were not looking at the same piece. I had seen a ram from you where the neck was a mere vertical thin cylinder put on the surface of a sort of token. Very different from what I was showing with my link.

Today, I see different designs from you, few being more in what I was thinking, so maybe it's a misunderstanding.

I guess we were not looking at the same piece. I had seen a ram from you where the neck was a mere vertical thin cylinder put on the surface of a sort of token. Very different from what I was showing with my link.

What you describe seems the Ram that François posted here. It was not mine. So yes, it seems there was a misunderstanding, as I was thinking you referred to this one, which I posted earlier. (And which also still had problems in fixing it to its base.)

If a 'prelude-model.js' is created, I'll try to use it to set timurid parameters, which will allow the declinations to be merged.

I wonder how I could best generalize the Metamachy prelude code. In Metamachy the various options are presented as a 4x3 matrix of clickable images, each image being a 2x2 composit of 4 icons in various relative positions. For Metamachy that makes sense, as the setups to be selected partain to an area of 2x2 squares.

In general the area could have any shape, e.g. a number of pieces on the back rank, and then another layout would be more natural. So it should be able to configure both the layout of the selection panel, and the layout of the individual clickable items in them. It could also be useful to allow accompanying texts, although the use of icons should be the principal method. (But in the Tamerid games it would be nice to have the name of the variant next to the icon-decorated buttons.)

So I am thinking in the direction of having the caller of a function that defines a prelude supply information on how the selection panel should look. A button in the selection panel could be defined by a character string as a mini-FEN. A numeric argument could indicate how many buttons should be displayed side by side.

Metamachy adapts the board-display routine to not show the configurable pieces, and then shuffles those according to the selection that was made. (Or by the AI: randomly.) This seems a round-about way of doing things; why not just leave the pieces away in the initial setup to begin with, and then just place them instead of shuffling them? That also saves you the work of taking them away! (And correcting the hash key for that...) Anyway, apart from how the icons must be painted on the buttons, it must also be specified to which square each position on the button corresponds, so that he piece can be moved there according to the selection. That can be an array of square numbers.

Because the selection might apply to both black and white, (as is the case in Metamachy) we might actually want to pass two such arrays. We should also account for the possibility that the prelude involves a number of selection events. And in whose turn these events must take place. E.g. white and black might be allowed to each chose their initial setup independently. I think Jocly enforces strict turn alteration, so it could be needed to skip some turns. (I think Metamachy already does this: black selects the setup, so the game must start with a dforced pass for white.) And it must be possible to provide a routine for the AI to make the selection, which would be run instead of showing the selection panel when the selection happens in the AI's turn.

Perhaps something like this:

Model.Board.Prelude = [ // sequence of panel descriptors in an array
  {
    who: 1, // show during white's next turn
    panelWidth: 4, // 4 buttons on a row
    setups: ["KQ/LE", "KQ/EL", "QK/EL", "QK/LE"], // the 4 options, and how their buttons look
    squares: { // where the 4 pieces go
      "1": [14,15,4,5], // for white
      "-1": [84,85,94,95] // and for black
    },
    ai: function() {  return Math.floor(Math.random()*4); } // how the AI would select
  }
];

clear syntax

I did it slightly differently: the prelude property in the game definition is now an array of objects like the one I proposed, except that I dropped the 'who' property. Each position in the array corrsponds to a turn, so it is already obvious who is on move for each prelude 'stage'.

If the array item is a zero, that turn will be passed; this is for allowing two different selections in a row by the same player, or black starting to make a selection.

I copied most of the code for the prelude model and view files from Metamachy, replacing the hard-coded locations and sizes of the selection panel and buttons by values calculated from the prelude definition. There is one thing I do differently, though: in Metamachy all pieces start on the board in a default location. (It appears this is important for them to show up later). The display function is intercepted to suppress the display of the pieces to displayed, and when a setup is selected, the pieces are first removed, and then placed back in another constellation.

As we want to be able to select from a wider range of pieces than actually has to be placed this same method could not be used anyway. So what I do is not shuffling the pieces, but 'promoting' them by altering their type. As I noticed that Jocly sorts the piece list by increasing value of the piece type (which does not seem to be essential, as on promotion during a game it doesn't resort it, but it could have efficiency ramifications for the AI), I resort the list afterwards. (This required a small change in base-model, to make the sorting available as a separate function.)

So you would typically start with pieces in all locations where you want to place any, it doesn't matter of which type. The prelude then assigns them the types that were selected for the square they are on.

If you would want a square to appear empty before the prelude (as is done in Metamachy) this could be achieved by initially placing a piece there of a type that has an invisible image. Or perhaps better, that shows up like a flat marker (a checker?) with a question mark on it. That way makes it clear which squares you are making the selection for, if there are more empty squares than pieces to place. (As is the case in Metamachy!) I will see if I can make the prelude-view automatically add such a piece to the set that is in use; in the piece-drops sub-model I do provide flat 'pieces' with a number on them, which can be put on the holdings squares to indicate how many pieces of that type you have in hand.

I tested the thing on Timorid, by adding to the game definition:

prelude: [0,{
  panelWidth: 1,
  setups: ["XQX","HQH","XHX","QHQ"],
  squares: { 1:[15,18,20], '-1':[123,126,128] }
}],

with some (nonsense) alternatives for the setup of Ships (X), Queens and Griffons (H). The 0 indicates that white passes his first turn, so that the selection is done by black (and randomly picked if the computer plays black). This give the following selection panel:

A complication is that asymmetric pieces must be defined as separate types for white and black in Jocly. This has always annoyed me, and perhaps we should fix this one day (by assigning every type two graphs, one for white and an (optionally different) one for black. Anyway, for now I solved it by allowing an optional property 'blackOffsets' in the prelude objects, which would be an object that for each relevant piece type optionally specifies how much should be added to the type number when it is black.

I kept the layout principles of the selection panel the same as was used for Metamachy: one icon size between the buttons, and half that between button and edge. This looks a bit spacey when the buttons are only a single icon high, like here. On the other hand, it would offer space to display a text under the button; perhaps I can manage that. (This would require a new optional property in the prelude object, e.g. 'subscripts', and array that contains a string for each setup.) The layout might need a larger margin at the bottom for that, though. (And perhaps there could also be a larger margin at the top, to allow you to display a message there over the full width of the panel, fiven by an optional property 'header'.)

It seems Jocly never draws any text anywhere. So I cannot find an example of how to do that.

It would be possible do copy an image to the selection panel that has the desired texts already drawn on it, and use that as background for the selection buttons. Perhaps I should make an optional property in the prelude objects for that.

[Edit] I finally managed to render an image in the background. It can be specified as a 'panelBackground' property in the prelude object.

That sounds very promising. This will make it possible to reduce timurid chess to a variant with

prelude: [0,{ panelWidth: 1, setups: ["XQX","XLX","HQH","HLH","HSH"], squares: { 1:[15,18,20], '-1':[123,126,128] } }],

Well done

The Timurid family is a simple case, because they all have the same promotion. Pawn keeps promoting to Queen, even for those variants where a Queen is not in the initial setup.

I suppose that in general you cannot be so lucky. The commonly employed rule is that you can promote to every non-royal in the initial setup. That makes it more difficult to combine variants that merely differ by replacement of a piece. It would be nice to make the prelude sub-model more useful by also building in a device to automatically adapt the promotion choice depending on the selected setup.

Perhaps the prelude routine could automatically create an array with all non-royal piece types that were selected for participation in it. A 'promote' routine that returns this array when a move is found to be a promotion would then fit the requirement. And variants that don't want that would just ignore that array, and return their own, fixed array of possible choices.

Or, with a slightly different approach: the 'promote' routine could get the array it returns from a variable outside itself, existing in thegame-definition object. (The routine returned by cbPiecesFromFEN already does that, in the form of the property promoChoice.) The prelude objects could refer to that array (as they are also instantiated inside the game-definition object), e.g. through a property 'participants', and then change its content As opposed to replacing it by a new array) based on the user's selection. So that the promotion routine will use that adapted content. If this is not desired you simply omit the participants property from the prelude object.

[Edit] Also here the color dichotomy is a pain in the neck. With asymmetric pieces you could not use the same set of promotion pieces for white and black. I guess it is really urgent to fix that problem once and for all.

[Edit2] I suppose we can do without an optional blackTypesOffset. The prelude routine knows whether it is placing black or white pieces, and when it looks up the type for a certain piece ID, it can use the convention that white uses the first such type it encounters in the pieceTypes list, and black the last one.

Let's do it like this

If this prelude is also used as a second-level variant selection, I suppose it would be annoying if you would have to make the selection again each time you press 'Restart game'. So I now added an optional property 'persistent' in the prelude objects. If it appears with value true, the dialog will only appear in the first game after the variant is freshly selected, and once the user has made the selection, it will automatically pick that same selection in subsequent games.

As to the asymmetry issue, I think that for now the best solution is to add an extra 'blackParticipants' property, and make the other 'participants' array only contain all the piece types that participate as white pieces. In games without asymmetric peieces (other than the Pawns, which would never be in the array) or unequal armies, that would also be the list for black. When blackParticipants is present, it will be updated to contain the present black pieces. So it is up to the implementor of an asymmetric game to decide how he will program the promotion routine, and has the option to have any prepared arrays he uses in the process automatically updated for the selection.

I am not sure if it would ever make sense to combine games with different castling rights into a single group. If I think of the 10x8 games Capablanca, Gothic and Bird could be easily combined, but Embassy has free castling, Janus extra-long castling on the Q side, and Carrera has no castling at all. I suppose it would be possible to let the prelude object also contain an array of castling definitions that would be picked together with the corresponding setup. I guess we should not overdo things. (But this is actually very easy to implement.)

If it's easy to implement, then it's probably worth doing...

Well, it is just a matter of including an extra optional array with as many members as there are setups, and copy the element corresponding to the selected setup to the game definition's castle property. The one who wants to use it must worry about supplying the castling specifications, which are rather lengthy in themselves. But many setups will likely share the same definition, so the array can just refer to that definition multiple times.

This same method could in fact be used for any game parameter, to make it dependent on the chosen setup. You could even add arrays of functions, and call the function for the selected variant as soon as it is selected. This user-supplied function then could make arbitrary changes to the game definition. Or you could allow an array of promote functions, for replacing the original 'promote' function in the definition. Or a function to be called by the AI when it must make the selection in its turn, to replace the default random selection.

I am now turning Capablanca Chess into a reference implementation for the use of the prelude module for combining a number of 10x8 variants. Some of the variants I would like to include have 'flexible castling', though. And at the moment such castling cannot be specified by the castle property of the game definition, (which only allows the specification of one castling per King/Rook pair), but must be implemented by supplying a 'customGen' function to extend the move generator. So that customGen function must then not always do the same thing, and in particular for variants without flexible castling must not do anything.

The question is how it should know that. It should somehow be visible for it what selection the user made. There could be some extra property in the castling definition that would tell it flexible castling is allowed. But actually the number of the selected setup is already stored in the prelude object in the case of a 'persistent' choice, so that it can make the same choice in every subsequent game. And I suppose these kind of large rule variations would only occur for persistent choices, where the prelude is used as a second-level selection method for the variant, rather than having a variant with flexible initial position. So I guess I can fix it that way.

It's a good idea to provide an example. It's the best way to ensure that the code is understood and used.

I pushed everything I have to the pullreq branch now. Capablanca Chess appears to work for 10 variants now, selectable through a prelude: Capablanca, Gothic, Bird, Carrera, Embassy, Ladorean, Grotesque, Schoolbook, Univers and Janus Chess. There is a large variety of castlings involved (2-step, 3-step, and since the initial King location also varies, which requires a different castling descriptor in Jocly, that already makes four). Carrera has no castling (at least that was easy), but there is no standard support for flexible castling, so I had to implement that myself.

Apart from the buttons with the icons indicating the pieces between the corner Rooks, I used a background image with the names of the variants:

A blemish on the implementation of flexible castling is that, after you select the King, it highlights the Rook for the 2-step castling, and the King destination for 3 or 4 steps. (This because the standard way for Jocly to enter a castling is highlighting the Rook, but obviously you have to use something else if more than one castling with the same Rook is possible.) This looks a bit unnatural. It would be better to let all castlings be indicated by the King destination. But for the tabulated castling in the castle field Jocly does it the way it always does it, highlighting the Rook. And since the extra castlings are defined relative to the tabulated castling, one of the castlings has to be tabulated, and then the Jocly standard code would offer that as a choice.

I suppose I could try to tabulate a 1-step castling, and prevent that Jocly tries it by removing the 'castle' properties from the Rooks. The standard code will then think there are no pieces to castle with, and ignore the tabulated 1-step castling!

Congratulations HG! This is nice.

10 variants in one, well done. I will try to draw inspiration from it for the variant timurids.

I updated the pull request with your contributions.

A suggestion for chu shogi would be to use the same representation for the side mover as in minjiku to facilitate learning (for example side mover: machine, reverse cart: mini tower, soaring eagle -> aigle, horned falcon -> hawk).
If we duplicate the sprites (wikipedia-fairy-sprites) in shogi/tenjiku-sprites.png we could even add the tiger and the wild boar, here is what that would give

Scirocco is working well, will you update the visuals? do you want me to do it?

Otherwise I played a lot of minjiku which I find very interesting, in the rules which are well done, it would be a useful addition to add an explanation on the "area move" that is mentionned.

I am still a bit shocked by how much trouble I had to make the free castling work. I think I am going to refactor the way castling is implemented in base-model.js; it currently is quite inefficient.

I will make the Scirocco visuals.

it's not surprising that castling takes a little time to refine

For my part, the integration of a prelude for a parameterized version of timourides went smoothly.

Thanks for everything, it's better this way.

For now I kept castling mostly as it is, but I made base-model support flexible castling as well. This required only a tiny modification. A castling spec can now also contain a property 'extra', which must be a number indicating how many more castlings that particular King/Rook pair can do besides the indicated one. These extra castlings make the King progressively take extra steps in the same direction (and the Rook fewer, so it ends in the same relative position to the King).  So you would put the castling with the shortest King move in the table, and to enter this castling you would have to click on the Rook as King destination.

This was already how Jocly did it if there was a single castling And it is convenient in case  the shortest allowed King castling move is 1 step, as it removes the ambiguity with the normal King move. The additional castlings must be entered by clicking on the King destination. This is a bit confusing if the shortest King move is not a single step, though. To cure that I have made it such that when you specify a negative number for 'extra', it interprets it as its absolute value, but suppresses the castling that was actually specified. So you can specify the 1-step castling in the table, which could then be entered through clicking the Rook, except that it will never be generated. But this forces all castlings that are generated to be entered through clicking on the King destination.

are we going to remove carrera, gothic and janus? or are we going to duplicate config_view_js_30, which is shared with capablanca in index.js?

Well, it seems impolite to delete work from others. Perhaps we should leave that decision to Michel. So I suppose we do have to duplicate the shared config array.

Which is sort of a pity, because it does not happen often that one can share config scripts. This seems a flaw in the building process. I suppose the reason to have these config scripts is that the actual game descriptions only have to refer to a few of those, which are shared by many. Otherwise they could just as well have been written inside the game descriptions themselves. But the fact that almost all games need dedicated model and view files sort of spoils that. If the building script would be clever enough to combine the game-specific files mentioned in the description with shared descriptions of all sub-models they are based on, it would be much more useful.

Now that cbMoveMidZ has a default that is almost always satisfactory, the view config scripts would need less 'personalization', so perhaps those could be shared on a larger scale now.

And for something completely different: this was an easy one. But it could still be useful:

That's a very nice Dolphin, H.G.! Can you make a Walrus to go with it?

you're efficient at making pieces quickly.

NB : index.js is modified

Well, it still takes about 1-2 hour, depending on how perfectionist you are. Pieces I still would like to have a Wildebeest, Spider and Octopus. The Spider I could probably do, but I haven't a clear idea for how to fit it on a base. The other two would require an enhancement of the Tube tool, as it now only can do structures that ly in the symmetry plane, and then duplicate those by a translation or shear (which both keep it planar).