Comments/Ratings for a Single Item
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.
H. G. Muller wrote on Fri, Jan 12 10:37 AM UTC: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.
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.
H. G. Muller wrote on Fri, Jan 12 10:11 PM UTC: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.
H. G. Muller wrote on Sat, Jan 13 08:07 AM UTC in reply to H. G. Muller from Fri Jan 12 10:11 PM: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
H. G. Muller wrote on Sat, Jan 13 09:16 AM UTC in reply to François Houdebert from 08:59 AM: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 ?
H. G. Muller wrote on Sat, Jan 13 06:22 PM UTC in reply to François Houdebert from 10:41 AM: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:
- 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.
- 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
H. G. Muller wrote on Sat, Jan 13 10:31 PM UTC: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.
H. G. Muller wrote on Sun, Jan 14 07:08 AM UTC in reply to Jean-Louis Cazaux from 06:26 AM: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.
H. G. Muller wrote on Sun, Jan 14 11:28 AM UTC: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
H. G. Muller wrote on Sun, Jan 14 03:53 PM UTC in reply to François Houdebert from 12:45 PM: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!
H. G. Muller wrote on Sun, Jan 14 10:28 PM UTC in reply to François Houdebert from 05:19 PM: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).
25 comments displayed
Permalink to the exact comments currently displayed.
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).