Comments by HGMuller

Tenjiku Shogi is basically an extension of Chu Shogi. Some pieces that in Chu Shogi are only available as promoted pieces, already are present in the initial setup, and promote further. There are also many new pieces in the initial setup, most with their own, entirely new promotions. But all Chu Shogi pieces participate except the Go Between.

This is why I called the kanji piece set tenjiku-set-view rather than chu-set-view; the idea was that it would at some point be extended with all remaining Tenjiku pieces. The kanji tiles only differ in diffusemap anyway, and the diffusemaps for all Tenjiku kanji tiles already exist, used in the Jocly Tenjiku implementation here on CVP. (But under different names from how we would want them.) They would just have to be committed (in a directory chessbase/res/shogi/tenjiku-diffusemaps, using the naming system also used for the chu-diffusemaps).

I added the Duck as a quasi-mnemonic representation for a diagonal hook mover (Long-Nosed Goblin or Capricorn) from the large Shogi variants, and in particular my shrunken version Macadamia Shogi. But I also used in for the Half Duck in Chess with Different Armies.

I think the dotted circle is a new feature of CG, for highlighting locust captures. The question is why there was a locust capture.

Do you have a link to the preset? Never mind, I figured out how to use the log id.

@Fergus: Is there a way to see the result of print and printr statements in the GAME code when the move gets accepted? I only get to see those automatically when it executes die, which I can often trigger myself by playing an illegal move. But in this case I really want to know what happens on a specific move, and without any output from the prgarm debugging is hard.

While I was at it, I thought I might as well extend the tenjiku sprites with the the pieces for Tenjiku Shogi. My first attempt is here. The Wolf and Bull are good enough for Dog and Water Buffalo, the Griffon seems a logical choice for Lion Hawk. I used a Star for the Free Eagle, which moves as Queen with some close-range locust capture, in the hope that a star would cause the association with 'all directions'.

I am least happy with the various kinds of Soldiers. I represented the Chariot Soldier by a Cannon, because it is also associated with war, and has wheels. For the Vertical and Side Soldier I picked two warrior helmets, but there is no vertical or sideway aspect to those. Perhaps they should be represented by Bows in two different orientations? Then all Soldiers would be represented by shooting equipment.

I also included sprites for the not-yet-implemented Dai Shogi (the third shogi variant strongly related to Chu Shogi). The Wolf can be used there for Evil Wolf, (There is no Dog there), and I left in the Wazir, Ferz and small Bishop and Rook sprites for representing Angry Boar, Cat Sword, Flying Dragon, and Violent Ox (since the latter two are B2 and R2); it seems better to represent these by move than by name. That only leaves the Stone, General, for which there unfortunally is no logical continuation of the Generals series. So I took the Scout symbol for that. We can worry about this more when we would actually implement Dai Shogi.

[Edit] Strange thing: when I was trying it out it appeared to have lost its opening book, and I got error messages in the console about requesting Zobrist keys for invalid board squares. This turned out to be associated with this strange mode Jocly sometimes gets in, where white is at the far end of the board despite "View as player A" having been selected, but the white pieces still all look away from you, and thus have the wrong orientation w.r.t. the board. I usually solve that by firest viewing as player B, and then again as A. This then also granted it access to its book again.

Something very fishy is going on. I discovered that what GAME code prints is hidden in the header of the preset page, so I could see it by looking at the Page Source. (A bit inconvenient, as it is buried in an insane number of empty <P> tags, but I managed.)

I experimented a bit in Play mode, and the fastest way to reproduce the disappearence was 1. j3-j5 i10-i8 2. j5-j6 i18-i7 3. Nk2-j4 and i7 would disappear. In particular, the problem occurred when a Pawn was moved a single step to attack another Pawn; that Pawn would then disappear.

So I put statements in the GAME code to see what move was offered to GC for playing. This was simply "N k2-j4", no instructions to remove anything else. So I printed the board just before that move would be executed. The Pawn was already gone. So I tried printing the board earlier in the process of verifying the legality of the move, to see at which point the Pawn would disappear. But after that the Pawn on i7 did not disappear anymore!

That was weird. Printing something should not alter what the code does to the board. I commented out that extra printr statement, and later removed it alltogether, to go back to the situation where I last saw the problem, only printing the board just before the move was made. The Pawn did not disappear anymore. So I removed all print statements I had added for debugging: the Pawn stays. I played to the game position: also there no Pawns disappear.

So it seems the problem has cured itself, without making any changes to the preset. Please try again to make a move in the game, to see if you have the same experience.

I get the impression it has something to do with the state Jocly had when you left it in the previous session. But I still have not figured out what.

I decided to go for the Bows. I pushed the lot to pullreq; tenjiku-set-view should now contain all the 3d pieces for Chu and Tenjiku Shogi; only 6 pieces for Dai Shogi are still missing. The 2d sprites should already be able to handle all three shogi variants.

I saw your improved Whale, but I decided to remake it anyway in SVG, to get a properly anti-aliased image  The fact that the sprites are 100x100, and usually rendered at smaller size already mimics some antialiasing, but for certain demagnifications it can still come out poorly. So I decided to take no risks.

How come a problem like this can cure itself is a real mystery for me.

To me as well; it should not be possible. Unless there was some hardware error, where a faulty memory bit was causing the program not to behave as it should, and that after some time it ended up in another area of the memory. The problem should not have existed in the first place; if the last-moved Pawn would disappear after every piece move it should have been discovered much earlier.

It is a very nice trident, which allows a good distinction between the white and the black piece. A very good mnemonic for the White Horse and Whale move. With the image of a Whale I can live (and in XBoard I tried to draw a Dolphin in a shape that resembled the move), but the use of a horse image for a piece that moves so very differently from an orthodox Knight has always bugged me. Currently I use the Nightrider, but I thinkt this trident would be much better.

In the promoChoice the pieces must optionally be separated by commas. That is, if there is a comma anywhere in the string, the string is split at the commas to get the piece IDs. If not, strange things could happen if the piece IDs are not single letters. (It then just looks if the ID occurs as a substring, while otherwise it looks whether the ID sandwidched between commas is occurs as a substring of promoOffset sandwidched between commas.)

It is on the to-do list to use the same system in individual rows of the morph and captureMatrix. So that you would not have to use commas throughout the entire matrix if you need it in just a few rows. (Usually these matrices are pretty sparse.) If you really need this I could give implementation of this priority.

A * refers to the first set in promoChoice, a 1 to the second. (Or one could imagine counting of the sets starts at 0.) This is partly historic accident, as a 0 in the captureMatrix was already defined as kamikaze capture before alternate sets were introduced and the the promotion zone was indicated by *.

There is a subtlety here that I did not foresee, and yet has to be resolved: would you promote on entering the zone, or in every case where you end the move in it. This becomes important when you can defer promotion, (which is standard in shogi variants), or in a more general case whenever you can promote to pieces that themselves can promote. It seems undesirable to have different behavior here on promotions specified by morph=* and those controlled by promoZone/maxPromote, as the main reason for introducing * in the morph boards was to handle irregular promotion zones (e.g. on diamond-shaped boards, or in diagonal variants). But I don't think this is currently the case. (The current rules for the normal zone are complex anyway, and depend on promoOffset and holdingsType, to get the desired behavior in regular Shogi, Chu Shogi and Grand Chess.)

Since 0 has no meaning yet in the morph boards (defining squares where pieces would disappear seemed pointless; no one would move there, and you might as well make them inaccessible), it could be made to refer to the first promoChoice set, but with alternative rules w.r.t. where you came from.

[Edit] It appears the comma notation was already implemented for morph. I now also implemented it in captureMatrix. (All untested, though, and only in betzaNew.js.)

I am not sure the trident should be used for both the Whale and White Horse. It would suggest that it points in the direction in which it moves, but for black this would just be the opposit. And if you pair the flipped versions for the same type, it would look all wrong when viewed from player B. I am not unhappy with the diving-Whale image; it also suggests something that goes down, without suggesting too much that 'down' would be a direction relative to the symbol. An upside-down symbol would strongly suggest the reason for displaying it in an unnatural way is that you want to indicate a direction with it.

I 'parked' the dot near the Axe for copy-pasting it onto pieces that needed it; the Axe is not used in the set. But the idea was indeed to remove it from the final set. I had not noticed the stray pixels near the Fire Demon.

Yes, another Diagram in the Comments listing it spoiling it, as it uses betza.js instead of the needed betzaNew.js. Click the 'View' link to see the Comment in isolation, then the Diagram should work.

The rightmost chariot mightbe good for the Reverse Chariot. I admit it is more remaniscent of the name than of the move, but in this case that is not so important. Lance and Reverse Chariot are practically useless people, and players will quickly learn to simply ignore what is in the edge files, without paying much attention to how it looks. It is mostly the location on the board that identifies it.

I don't think the Slip sliders are lame. The page where this term was defined said that their partners, the Skip sliders, where the same as riders. (E.g. Slip Rook = Panda = Dabbabarider.) So the conventional Slip sliders would be [F?AA], [W?DD] and [K?SS]. (Hurrah for the new Alibaba symbol!)

The Interactive Diagram can enforce a limit of one Tsarevna at the time by initially puting one Tsarevna in hand, letting captured pieces go to the hand of the owner, and specifying the Tsarevna must come from the hand in promoChoice. It could enforce maximally three times promotion to Tsarevna by having it come from the hand, and putting three of them initially there, without returning them on capture. But it cannot enforce both at once.

The thee times rule seems completely pointless, though. I understand you want to create a possibility that one has to checkmate with two Frogs, but this rule is very unlikely to do it. The Tsarevna is a strong piece, and promotion to it will have a large probability of being decisive. The probability that a game would not yet been decided after three such promotions is vanishingly small. To have any effect, the limit on promotion to Tsarevna should be lowered to one. Otherwise you might as well not have any limit at all.

You can move pieces from the table to occupied squares, to replace what was there. If there are too many pieces in total, you could capture the surplus. But only through legal moves on the board.

I have alo seen that message, but only in the state where the view is upside-down. It then also couldn't read its book. Fixing the view made the problem disappear.