Ratings & Comments
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?
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.
It's good to know that you can use the bottom squares for that. Does it mean that we have to specify something like Model.Game.handLayout[1][{2:18,4:17}]; // eg : square 2, hand 18 for the white for each piecetype?
Note that it is possible to control the way the captured pieces are placed next to the board by defining arrays Model.Game.handLayout[color][handIndex]. This array should contain the square numbers where you want the first captured piece of the given color (1 or -1) and hand value to be placed. (A second piece will be placed at sqr+color, and after that counters will appear between the two shown pieces.)
Currently the default assignment is used, which places the white pieces on the first 'file' on the right of the board, the hand number equal to the rank number (which starts at 0). By defining a handLayout you could also use the ranks under or above the board to place pieces, thus requiring fewer extra ranks.
E.g. with a single extra rank (instead of the 4 you have now) you could place 6 white pieces below the board, and 14 white pieces to the right of the board.
Talking about background it doesn't seem to work on my device even though it used to work. Interactive Diagrams that use backgrounds like Eurasian Chess, Chak, VaoQi don't seem to have backgrounds on my device.
I beat you by 4 minutes! :-)
It is interesting how we both chose a different rectification of the board; mine spoils the coordinates, yours spoils the moves of the pieces. In your representation it would in principle be possible to use a whole-board image as background that has the original diamond-shaped cells.
I tried using the Atlantic SVG set through fen2.php, but this set is not suitable for use on a black-and-white board. (Alfaerie doesn't do so well either, on the dark squares...)
[Edit] Concerning Pawn: Ah yes, I had overlooked that detail in the description. Thanks!
Stairchess960
To BenR: Maybe this can be both?
To David mRcpR: Why is that a problem? What about Pawn on h-file which cannot move forward? Edit: I didn't see HGM's Interactive Diagram when I was creating an Interactive Diagram for this. To HGM: Shouldn't the pawn beiiflmnDflmWflceF
?Since this comment is for a page that has not been published yet, you must be signed in to read it.
Done!
This is an excellent concept. There's just one tweak I'd like to see. Pawns on the a-file cannot move any further to the left, so that could be a problem. One way to remedy that might be to divide the board vertically down the middle, giving pawns on files A-D a move to the RIGHT, and on files E-H to the LEFT, as you have currently done for all pawns.
How about switching Diamonds & Onyxes? or Onyxes with Lame Ducks?
I filled in the board size metadata as 8x8, but perhaps it would be better as 8x15 (still with 64 cells)?
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
You must also put
set opaque (EA FA BA SM AR ea fa ba sm ar);
there to make the flying pieces block each other.
I have pasted that at the end of the pregame section.
I suppose that would heve worked, if you did that as first thing in the Post-Move sections. But I have already changed the betza.txt to use different arrays for the capturer and the victim. So now you have to put in Pre-Game:
set protected (T t); set restricted (EA T ea t);
Thanks.
Looks like everything works properly.
Can you send me the updated files for Seireigi and Chu Seireigi (I have already taken care of Hectochess)?
I hope it's ok now
For the terror trading rule, would it work to have set protected (EA T t)
in pre-move 1 and set protected (ea T t)
in pre-move 2?
or maybe they should be in post-game 2 and 1?
Here are the errors I didn't find before or are new:
Incorrect 3d Kanji Readings (all should be colored red)
- Promoted Lance (should say 奔虎)
- Promoted Gold General (should say 大象)
- Promoted Kirin (should say 角行)
- Promoted Phoenix (should say 飛車)
You should add the western-style piece images for the rest of the pieces in the Pieces section (to align with the interactive diagram).
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
I have done it and it seems to be working fine!
I made some corrections.
ctrl+f5 : may help to reload scripts in case of cache issues
No Move Zero rule? I doubt this army is weak.
I saw you added the 3d Kanjis back to Chu Seireigi. I went through and tested everything, and here are the errors I found
Incorrect 3d Kanji Readings
- Unpromoted Great Leopard (should say 大豹)
- Promoted Knight (should say 天馬)
- Promoted Silver (should say 走狼)
Other
- Promoted Lance, Gold seem to crash/softlock the game
- Promoted Copper General (大豹), Promoted Running Wolf (奔猪) assets doesn't load
- Promoted Kirin (角行), Promoted Phoenix (飛車) indistinguishable from unpromoted counterparts (kanji should be colored red)
P.S.
I was surprised that they didn't have the same movements. I wondered whether a different adjective might be better to distinguish them: e.g. cunning fox and vigilant rabbit, Same for the whale with chu shogi.
That was because I found the Wa Running Rabbit to be too similar to the Lance, and knew that it would add too much defense after testing with the Old Kite. So I gave the Running Rabbit the ranging moves from its Taikyoku counterpart while omitting the stepping moves. The reason it has the same name as the Wa Running Rabbit is because it is one of only two Taikyoku pieces to be a rabbit, and I thought the running kanji fit better. As for the whale, its backward bias was a problem, so I replaced that move with the current one.
The 3d pieces are back. here the seireigis and hectochess updated.
I saw that the wa shogi was also a medium shogi with drops having a running rabbit (FfRbW) and a Treacherous fox(FAvWvD).
I was surprised that they didn't have the same movements. I wondered whether a different adjective might be better to distinguish them: e.g. cunning fox and vigilant rabbit, Same for the whale with chu shogi.
Did not knew that! Still in the evening, but thanks!
Oh, that seems a lot of work. But I'll do it in the evening!
Not really. You should just select the Completely Custom set, and then paste the set definition the PTA suggests into the preset.
Oh, that seems a lot of work. But I'll do it in the evening!
I have made an attempt to support fast castling in the betza.txt GAME-code include file. I could not test it in the context of your preset, though, because there seems to be a mismatch between the labels used in the I.D. that youconverted, and the piece set you use in the preset. So it still crashes because of an unknown piece 'E'. I suppose you would have to use the custom set as the PTA suggests it to make it work.
Anyway, to try the fast castling you should replace the lines
2 99 1 0 88 1 9 0 25 2 99 -1 0 88 1 -9 0 25
at the end of the legdefs array by
1 -3 1 0 FastCastle 1 -3 -1 0 FastCastle
This uses the existing mechanism for invoking dedicated routines for generating piece moves. But the routine FastCastle, which is invoked by this, is already supplied in the betza.txt include file.
I still have to adapt the PTA to generate these lines automatically, when encountering a fast castling.
I've updated the title and will try to update the svg a little later, I'll be a little less available.
Bringing back the kanjis would be interesting to give a Japanese aesthetic, but I feel that to play a mnemonic skin would be a better alternative from my point of view.
The correct query for opening the preset in Edit mode is &submit=Edit, not &edit=true.
The problem appears to be the fast castling, and now that I think about it, I believe I never implemented fast castling in the betza.txt GAME-code include file. So the entries in the legdefs table that would be interpreted by the JavaScript powering the Interactive Diagram as fast castling are mistaken for something that makes the GAME code crash.
For now I recommend commenting out the four lines that define the fast castling at the end of legdefs, like:
1 1 -1 1 3 //2 99 1 0 88 // 1 9 0 25 //2 99 -1 0 88 // 1 -9 0 25 0);
The King will then not be able to castle, but at least you can continue implementing the other aspects of the variant in the preset. In the mean time I will try to support fast castling in betza.txt. And when I have done that, you can uncomment the lines again.
Much better.
The only improvements I can think of are reintroducing the 3d pieces, naming the game Chu Seireigi instead of Chu Seireigi Shogi (for the same reasons as with normal Seireigi), and maybe having the hand spaces all colored solid brown. But for the latter the wood is colored similarly enough that it doesn't really matter whether you do it or not.
Also, could you update that SVG for the laser cutter? I might want to make a plywood set in the future. But for now, the cutouts I made will do.
Updated !
Is it Better now?
The forced promotion issue is fixed for White's forward-only pieces (Pawn, Lance, Ram's-Head Soldier, Running Rabbit, Knight, Flying Swallow) but not for Black's.
47 comments displayed
Permalink to the exact comments currently displayed.
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.