Comments/Ratings for a Single Item

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