Comments by ChessShogi

When using the allow command, am I correct that the word in the word/number argument pair does not have to be a command or keyword?

Example:

allow ... one 2 two 2 onetwo 2 ...; // I was planning on using this to get around a very annoying bug I found in a future version of Suzumu Shogi's GC preset (with multi-capturing versions of the jumping Generals).

Edit: I answered my own question. You can use custom commands in allow, provided that for each custom command you include a subroutine in your Pre-Game code like the one shown below.

sub <cmdname>:
  return true;
endsub;

And I'm not sure exactly what the 'table' you are talking about is

When I say tables, I am referring to HTML tables. Speaking of which, it wouldn't hurt to get to know the basics of HTML, if you haven't done so already.

The editor also allows you to insert tables without needing to write HTML.

But I don't know how to apply interactive diagram inside the page.

All you need to do is paste the diagram definition into the page. The Interactive Diagram script doesn't care where you put it - the result is the same. Depending on whether there are multiple diagrams on the page, you may need to set the satellite parameter (satellite=xxx) within the definition to get it to work.

IMPORTANT: When inserting or editing an interactive diagram, make sure you keep the editor in HTML format, otherwise the editor will mess up the definition!

After some testing, I have managed to implement an algorithm to implement the Tenjiku ranking system in the interactive diagram. I've also changed the Heavenly Tetrarch's move so that instead of burning, it freezes (immobilizes) all adjacent enemy pieces except other Heavenly Tetrarches. Because of this, the Fire Demon's burning move restriction now only applies to other Fire Demons.

The GC Preset has already been updated, and the Mitsugumi Shogi preset will be updated soon.

Is that instead of burning? That's an interesting addition

Yep. It creates a nice duality between the the Fire Demon and the Heavenly Tetrarch. And it was really easy to implement for the interactive diagrams and GC presets thanks to this comment and GC's Ultima include file. The diagram now understands the new restrictions for the jumping Generals as well (same as Tenjiku, but with no restrictions on the final capture), though it still isn't yet capable of understanding the burning restriction. The GC presets are also up to date. But the best part is that I am finally done developing this game (for real this time). It took 4 years, but it was worth it.

The new freezing ability for the Suzumu Heavenly Tetrarch came from a suggestion by Eric Silverman somewhere about a certain version of the Tenjiku Heavenly Tetrarch having a similar ability instead of the igui ability, immobilizing adjacent pieces, and stopping an adjacent Tenjiku Fire Demon's burn (for all pieces adjacent to the Fire Demon) as well. I can't seem to find it anymore though...

Edit: I also cropped the Shogi images so that they are the same size as the Mnemonic images.

Edit: It seems I left out the double igui part of the Tetrarch's description. I'll fix that right away.

Edit: I also changed the turn skipping restrictions to be more in line with those of other LSVs (specifically, you cannot skip two consecutive turns, making skipping a turn useless if your opponent can skip their turn too)

I think I have an idea of how to implement the burning restriction in the interactive diagram using the clicks array, which stores the values for each move made using the the new move system. It's going to take a while to perfect it though.

Edit: I managed to implement the burn restriction for Fire Demons that burn once in a prototype file. Now for the hard part...Fire Demons that burn twice.

Edit: Turns out the code from the first prototype covered a lot of the cases for the twice-burning Fire Demon. Now, the second prototype covers most cases. The only thing left is to allow a direct capture of a Fire Demon where the Fire Demon burns exactly twice.

Edit: After some struggling, I managed to cover all the cases for the twice-burning Fire Demon, which means the Diagram now properly forbids a Fire Demon from burning another Fire Demon. The Rules pages for Suzumu Shogi and Mitsugumi Shogi will be updated soon.

Edit: I've updated both pages. No more worrying about having the AI make an illegal move.

Edit: It turns out the AI's move generation doesn't use the clicks array, so the AI will exit with an error whenever you try to run it.

Edit: With some help from H. G. Muller, I was able to fix the burning restriction for the AI.

Very useful information. Unfortunately it requires me to go back to the drawing board...

Unfortunately, I wasn't able to find a solution for implementing the burning restriction for the AI other than disabling the AI. It mainly has to do with the fact that the move generator will auto-complete the move if it thinks only one move is left if I try to use the killX and killY arrays instead of the clicks array.

I think it is better to just show you the difference. You can find the demonstration diagrams here.

I did notice that the kills variable wasn't being updated upon selection of a locust victim when I did some debugging of my own. The killX and killY arrays would update, but kills would always be zero. That would explain why when I tried recreating the clicks array using the visits array (using kills to regulate the length of the killX and killY arrays), it always ended up failing.

Some other remarks: You use (af)0 to force a slide on a K atom, but this is not recommended. Because (af)0K is expanded by pre-processing to KafKafafKafafafK..., as if every distance is a separate move, which would be attempted independently. So if the slide is blocked at the second square (so that afK would fail to produce a move) it would still keep trying afafK etc. And when afafafK was a valid non-capture, it would still again check the first four squares for emptiness when attempting afafafafK and longer paths. The equivalent plain Q would do much more efficiently, and probe each square on the path only once, and stop after it finds an occupied one. You can turn the Q into K for the burning by using ya to specify a range toggle. E.g. mpyacabQ would describe a Queen burning one enemy adjacent to her destination.

Sure, (af)0mpacabK is inefficient, but under the current implementation, it's the only Betza string that gives all options for the Fire Demon's burn. Using ympacabQ omits some of these options for some reason.

I suppose I should put the code that moves the destination click earlier inside a loop, so that it is able to pass locust vctims as lon as the preceding two legs have a cab structure. Then the double burnings could be entered by first clicking the destination, and then picking off the burn victims until you run out of victims, or click the destination again to terminate the move. That would be a much more intuitive way for entering multiple burns.

It would also make implementing the burning restriction much simpler, as then I don't have to worry about branching cases nearly as much, as it would usually be the same check every time (usually, not always, because shooting an adjacent Fire Demon without moving (double igui) is still allowed).

Right now I am supressing the new Highlight function with the old one, since the current code in Suzumu Shogi's interactive diagram relies on the call from the Highlight function. Once the pass for cab locust captures is implemented, I should be able to use the new function without any problems.

The extensive testing you do in BadZone() slows things down enormously. It is questionable whether this variant can ever be played by the Diagram's AI, (it outlasted my patience even at 2 ply), but this extra processing certainly doesn't help. If you need this amount of programming to make it work, it might be simpler to just replace some functions of the original script by slightly modified ones of your own. JavaScript allows you to redefine a function.

The amount of testing required for the Fire Demon was mainly because of the branching cases. With the new version, not only was I able to use the code from your comment to make the check much shorter, I was even able to remove three of the supporting functions because of this. As for code in general, sure, it will slow things down a lot, but that is to be expected from a complex game like Suzumu Shogi. You could treat it like a correspondence game in GC, though, so I was never too worried about it being too slow. I could probably do some optimization (I've saved this comment in my favorites), but right now I am just happy that everything is working properly.

OK, I think I fixed it. The Betza compiler now refrains from inserting these 'loop directives' in the legs sequence when the NewClick move-entry method is used. I had to change some tests in the assignment of click sequences (which already relied on the presence of these directives) too. Distant or sliding rifle captures do not require the click to the final destination. This might be a folly, though, as it causes ambiguity when both the rifle and normal capture are allowed on the piece. Perhaps I should make this subject to a Diagram parameter autoComplete, and in general require all clicks, but consider the move entered when there is only one matching move left in the list, and at least two clicks have been given.

I am not even sure that swapping the order of locust victim and destination is always harmless, or whether it could lead to ambiguities too.

There does seem to be a problem when using the Lion Dog (XBetza: KADGHcavKabKmpafcavKcafcmpavK) with the newClick generation. When doing a double capture of the first two pieces in a straight line, and you click the second piece again, it always selects the two out one in option. This is probably due to the ambiguity caused when rifle captures and normal captures are allowed. I am planning on reviving Hook Shogi, and I intend to include the Lion Dog in it, so any help would be greatly appreciated.

I think the best solution would be some directive specifically for this kind of ambiguity, or to only skip a locust victim after cab if that locust victim's square is the only one that can be visited, so as to not destroy the directives that allow the Suzumu Fire Demon's burning restriction to work properly.

Thanks for fixing that. To be honest, I was a bit worried that the Suzumu Fire Demon might get messed up, but it turns out I was overreacting. And now that the Lion Dog works properly as well, I can include it and the Suzumu Fire Demon in the same game without needing to use any special code (apart from BadZone for the burning restriction, of course).

As for the paralyze parameter, I'm not sure whether it would actually increase efficiency or not. If paralyze doesn't suspend the BadZone call after move generation you would end up calling it twice instead of once, so it could slow things down even more if I am not careful with it. So for now, I am just going to keep Suzumu Shogi's BadZone code as it is.

I did encounter another minor bug. The highlights for the ShowMoves() function seem to be a bit bugged when using the new move generation. For example, when showing the possible moves of a piece after clicking its name, the Suzumu Fire Demon doesn't show the burn for its ranging moves, and hook moving pieces only show the hook moves for the first square in each direction. It appears to only be affecting atom such as R, B, and Q. It doesn't affect the diagram when clicking pieces on the actual board, but it can be a bit misleading. Thankfully, this shouldn't be too difficult to fix.

Speaking of XBetza (or rather, IBetza), you should really consider adding a link to your page on Extended Betza Notation to this page. Even if it is not strictly identical to the one used in the interactive diagrams it would be a very helpful edition. I did check for a link to that page before writing this, and I couldn't find one.

The new definition for t could be quite interesting. It also helps that kc covers the old function of t (excluding capture of royals).

Sounds awesome. Only problem is that returning 512 for the promomtion it doesn't work like it should. Instead of burning adjacent pieces it simply burns the moving piece as if you returned 251 for the promotion.

It works now.