Ratings & Comments
thanks for the advice.
I have modified accordingly
An army with your pieces. What'd you call this army?
If it's a CwDA set, probably "Mad Movers."
By the way, Chinoise Rose in problemist language is called Rao.
I should've suspected that it would be something that rhymed with the others.
Should I add : Should I add " ##############" before and after?
Indeed, you should, because you want the extra hand ranks to be colored black as well.
Random Pocket Omega Chess
19 is the size of handLayout
boardLayout :
0: "##............##"
1: "##............##"
2: "##............##"
3: "##............##"
4: "##............##"
5: "##............##"
6: "##............##"
7: "##............##"
8: "##............##"
9: "##............##"
10: "##............##"
11: "##............##"
length: 12
Should I add : Should I add " ##############" before and after?
Strange. 13 should be a valid index for an array of length 19. That means the array should have some internal elements that are undefined. What happens if you print
console.log(
)?Since this comment is for a page that has not been published yet, you must be signed in to read it.
the array length is 19
NBROWS-row-1,row: 13, 0
This sounds like an out-of-bounds access on boardLayout. Are you sure you defined that array with sufficiently many ranks? To further diagnose the problem you could add console.log(NBROWS-row-1); just before the access to boardLayout in paintCells; then you could see in the console what the offending value is.
If you'd like to make an implementation of wa shogi, here are some unused jocly-compatible sprites that might come in handy.
To be seen if useful
In that case : I get in 2d with pictos
Would this come from using the draw function wrongly in my view : chu-seireigi-view.js ?
Note that I have the impression that with the modified version the result is satisfactory with or without extra hand ranks.
That's why I'd like your opinion on grid-board-view.js, because I thought it would be useful to transfer this modification to the pullreq branch for jocly.
I think that all that is needed is to make the 'row' loop run from 0 to NBROWS, and remove the -NBVHND from
this.cbView.boardLayout[NBROWS-NBVHND-row-1][col]
And then putting the extra hand ranks in the boardLayout defined in the game's view file. I don't think there are any other games yet that use extra hand ranks. I implemented that feature with Wa Shogi in mind.
The paintCells function is not involved in drawing the grid.
I had already looked at the sources, by looking at the chu-seireigi-view.js of the compiled version. Since you build Jocly without uglification all used source files are in there unmodified.
Your current setup for this game looks way better, but I did notice a few errors were made while making the new version. I also noticed a bug in the Hectochess implementation.
---------------------
Chu Seireigi Setup Errors
---------------------
White Kirin and Phoenix are swapped from where they should be in the initial setup
Black King and Great Elephant are swapped from where they should be in the initial setup
---------------------
Chu Seireigi Promotion/Drop Errors
---------------------
Pawn, Lance, Running Rabbit, Knight, Gold General, and Great Elephant are currently allowed to promote immediately if they are dropped into the promotion zone (this should not be the case)
White Copper General is put in same place as Black Lion in hand spaces, resulting in the hand space setup looking asymmetrical (White Copper General should be placed between the Great Elephant and Running Wolf)
(Also, because of this bug, a "King" may sometimes appear in current hand space of extra White Copper Generals/Black Lions for some reason...though this thankfully doesn't affect anything)
---------------------
Hectochess Castling Error
---------------------
When attempting to castle, the Champion's starting squares (b2/b9 and i2/i9) and queenside Knight starting squares (c2/c9) are not checked to see whether a piece is occupying them or not.
The change in paintCells was necessary because the grid wouldn’t display. May be that a better modification is possible, but I don't think I'm in a position to make it.
After a few modifications, current result
I don't know if you'd like to have a look at sources : latest to check grid-board-view.js
I guess the drop model still needs some tweeking. The square painting on the hand ranks should be the same as that of the other hand squares. Now there seems to be no coloring at all, so that the rim texture shines through. I suppose the logical way to do this is that the square-painting array that has to be defined in the game's view file should include the extra ranks.
It is also not clear to me why the 'counter piece' in the lower-right corner is larger than the others.
[Edit] The array boardLayout defined in the view file is accessed in two places in grid-board-view.js, inside nested loops over rows and columns. The loop over rows was modified to skip the extra hand ranks. I suppose this was a bad idea; especially in the 'paintCells' function it should have run over all ranks, requiring the boardLayout to also specify how the cells in these extra hand ranks should be colored. There is a second routine 'paintInCoordinates' that also loops over all cells, which does more complex things and might need more subtle modification than just changing the loop limits. But it seems this function is not normally used.
The handLayout[-1] in the view file appears to have a 16 where there should be a 17, which causes misplacement of the 'counter piece' on 15 rather than 16.
An army with your pieces. What'd you call this army?
By the way, Chinoise Rose in problemist language is called Rao.
I gave it a try here. I think It looks better this way.
@Adam: apart from the adjustments linked to the changes, what do you think?
I still have Astra (Rosetta) on your queue, but also I’ve recently created Astromech (even squares diagonally or odd ones orthogonally, AA[W?DD]). Try to guess who is Astromech)
No, you have to write something like
Model.Game.handLayout[1] = [0,2,4,6,8,10,12,14,30,46,62,...];
if you want the first 8 'hand squares' for white to be at the bottom, and the rest along the right edge.
The issues that the Tinkercad website is having recently may lead me to take a break after this weekend. Since the problem mainly affects new uploads, I may continue for a short while, but otherwise I'll just wait for the problem to be fixed.
I had already planned on only going to #366 (I'm running out of possible pieces to post), posting only occasionally afterward for extensions of sets, missed rotary counterparts, special requests, new discoveries, and so forth. I also had planned, if I hadn't done this already by then, to take the time to create an index of sorts that I could post as an article.
281. Mei (Chinese Rose / Rao). If a Nao is a Chinese Nightrider, then could there be a Chinese Rose? Well, of course there could! Like the Nao, the Mei (the best translation into Chinese for the word "rose" that I could find*) moves without capture normally, but must jump over a hurdle to capture. It's just that the Mei moves like a Rose. (mqNcqpN)
I don't think a move diagram is needed in this case, since most of us here knows how the Rose moves. I can vouch that the above XBetza does work; I tried it out in the XBetza Sandbox, and it behaves just as intended.
As I was informed in a later reply, this piece is called a Rao by chess problemists.
Creating this led me to discover some serious design flaws with my original Rose piece, which I've now corrected on my own system and will upload some time soon (Thingiverse is still having problems.)
*I have no doubt -- and, in fact, much hope -- that someone well-versed in the language will correct me if I got it wrong.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
25 comments displayed
Permalink to the exact comments currently displayed.
Since this comment is for a page that has not been published yet, you must be signed in to read it.