Comments by ChessShogi

GC preset legal move highlights work correctly now.

However, now you can't edit comments you are the author of.

Edit: it works now.

GC presets are not displaying at all now.

Edit: The presets will only load when an invitation to play a game has yet to be accepted. or when the preset was authored by Fergus Duniho.

It seems it's now impossible to delete a submission, even when said submission is completely empty (which is the normal requirement for using the deletion script). I temporarily revived Mitsugumi-Shogi to get an introduction for Mitsugumi Shogi's new page from one of the old page's revisions and then emptied the old page's contents. I then tried to delete it, but that didn't work.

If I could have an editor delete my Mitsugumi-Shogi submission that would be great. Note the hyphen in between "Mitsugumi" and "Shogi"!

Hope this game can be retrieved as it's the one I'm not losing in!

I think it's more a problem of the preset not loading at all rather than a problem of retrievability. The game should still be in the database.

I have a broken game (Modern Makruk).

The game isn't broken. The preset is not loading. I had the same problem when trying to update Mitsugumi Shogi's preset.

GC presets are working again.

The deletion script for submissions is still not working properly though.

I have fixed the GC preset's contagious promotions and clarified the rules for contagious promotions as well.

So perhaps I just need to put sub FD #0 #1 after the test (I tend to forget GC executes from right to left)?

Edit: That didn't work. I guess I'll just stick to the tried and true method of using the bpromote and wpromote subroutines for the actual rule enforcement.

I am curious though: if you use old in a function definition, does it return the value at the time of the function definition or the function call?

The problem was fixed when you fixed the piece promotion not showing. The extra satellite functionality for user defined functions is also quite nice.

That's perfect! Now that that's done, I can test a double-burning Suzumu Fire Demon.

Also, for some reason the Comments section is excessively narrow when viewed from the interactive diagram page.

Diagram parameters would be ideal, but there's one little problem. When rule enforcement require complex decision making (such as in Suzumu Shogi's current version, which forbids burning pieces from burning each other) the diagram parameters would be less than ideal. So there would likely still be a need for such functions even if the parameters eliminate the majority of cases where they would be needed.

I'm not sure how you intend to merge move rejection, game termination, mandatory promotion, and offering promotion choice, into a single function, unless JS allows you to return a value that could be one of many different types.

But I suppose it is better to stick to perfecting the new move generation system for now and focus on the functions later in development.

It seems that the holdings do not work correctly. Whenever holdingsType is set to anything other than 0, for each piece, it subtracts the amount on the board from the amount present at the start of the game rather than showing the actual amount in the hand. Also, setting holdingsType to -1 does not change the color for Shogi drops like it should.

It is now fixed.  However, I also noticed that promoted pieces are affecting the hand when they shouldn't, particularly for Shogi-style promotions (increments original, decrements promotion).

Nice.

I fixed most of the issues. Now the only problem that I can see is that the Heavenly Tetrarch's first burn is being rejected when it shouldn't be when the distance between the origin and destination of the first part of the move is at least 2. The problem is likely in the HT subroutine, since it controls the function definition for the second and third parts of the Tetrarch's move, but I could be wrong.

Here is the link for the preset's Edit form: Edit: Suzumu Shogi on the Chess Variants Game Courier

And here's the list of moves for which the error occured:

1. d 8k-8j 
1... D 9f-9g 
2. p 7l-7k 
2... P 10e-10f 
3. bg 6m-8k 
3... BG 11d-9f 
4. fd 7n-6k 
4... FD 10c-11f 
5. fd 6k-8i 
5... FD 11f-9h; pass 
6. fd 8i-5f; fd 5f-5e; fd 5e-4e 
6... FD 9h-12k; FD 12k-12l; FD 12l-13l 
7. fd 5f-7f; pass 
7... FD 12k-10k; pass 
8. fd 7f-7e; fd 7e-7f; fd 7f-8f 
8... FD 10k-10l; FD 10l-10k; FD 10k-9k 
9. bg 8k-15d; +bg-dest 
9... BG 9f-2m; +BG-dest 
10. dk 5n-5o 
10... DK 12c-12b 
11. cs 4o-14e; +cs-dest 
11... CS 13b-3l; +CS-dest 
12. +cs 14e-14d; +cs 14d-14e; +cs 14e-13d 
12... +CS 3l-3m; +CS 3m-3l; +CS 3l-4m 
13. +cs 14e-11b; +cs 11b-10a // <- ERROR: You may not move a +cs from 11b to 10a

That was what I was thinking as well, and given that the rest of the code is fine, we are probably right. Unfortunately, simply getting rid of that clause won't really solve the issue. The Heavenly Tetrarch has a unique mechanic that causes it to jump over the first square it travels over, so the preset needs to take that into account. It might be possible to get rid of it with clever use of the cond statemenet though.

Edit: Turns out I was using the wrong variables to account for the distance of the first part of the move. The values of origin and dest were updated before the move was evaluated, so the distance would always be 1 and the move would thus get rejected. I fixed this by using ori and dst instead, which stay the same for all parts of the move.

I can make a revision with the BadZone code in it if you want.

Here is the BadZone function's code:

function badzoneZone(x2, y2, piece, color, x1, y1, ex, ey) {
  if(touched) return 0; // not during ShowMoves()
  if(piece == 35 || piece == 65 || piece == 66) // Fire Demons and Heavenly Tetrarches
  {
    evic = (ex >= 0) ? board[ey][ex] & 511:-1;  // intermediate square
    if(evic == 35 || evic == 65 || evic == 66) { // Problem area
      if((x1 == x2 && y1 == y2) || (ex == x2 && ey == y2)) return 0; // Allow direct capture or igui
        else return 1; // else reject
      }
    }
    return 0;
  }
}

Eventually I hope to make it so that burning pieces cannot burn each other at all.

You can view a diagram with this function implemented here.

Suzumu Shogi is ready

Thanks for fixing checkahop.

As for the rest of the RANGECAPTURE code, the not so compact cx and cy assignments were me trying to fix the bug before realizing it was a server-side issue. I can just use cmp there since the jumping Generals can only jump along the eight cardinal directions. Since they use #ori and #dst (the variables that store origin and dest), and the jumping Generals cannot change direction mid-move, there is no need to compare directions, as using cx and cy with checkaride and checkhop returns the same direction as that of the first part of the move. The if statement with the checkaride clause is there to enforce the two jump limit for these pieces. If that checkaride clause fails but the ismultimove subroutine succeeds, the moving pieces has jumped over a piece (and another piece which it just captured) already, and thus cannot jump any more pieces.

Fair enough.

It seems I had an extra parameter in the israngecapture subroutine from when I was trying to use a subroutine to determine whether a range capturing piece had any legal moves left mid-move. It is fixed now. The responsibility of determining whether a piece has any moves left mid-move has been moved to the Post-Game sections, making use of the legalmoves2 subroutine's return value. I also fixed Mitsugumi Shogi's GC preset, which had the same problem.

Edit: I also got rid of the from parameter in the israngecapture subroutine and the statements that call it. Since it wasn't being used within the subroutine itself, there was no need to include it in the parameter list.

BTW, I have played Tenjiku at high level according to 'modern' rules, where the King can be jump-captured. To my surprise this was very playable, and not too unbalanced. If you know the correct opening lines. Which my Tenjiku engine was able to determine.

In addition I came to realize that the King has highest rank does not necessarily have to refer to capture. Originally I thought that outlawing jumping over a King only would be pointless, as you would never be interested in doing that when you could also capture it. But it could also refer to your own King. So the evidence that historic rules did not allow King capture is starting to get flimsy.

Jumping Generals are not allowed to jump over a King or Prince (or other higher-ranking pieces) of either side, regardless of which ruleset you use, so the fact that the rankings could refer to friendly pieces is a rather dubious piece of evidence for allowing jump-captures of royals. Besides, even if the evidence for forbidding jump-captures of royals is indeed flimsy, it still improves the gameplay, as allowing jump-capturing of the King creates a critical weaknesses in the opening after 1. 7k (2. VG 2g#) which is only solvable via 1... SE3f. Furthermore, this weakness persists throughout much of the game, as the King remains boxed in throughout the opening and (early) middlegame, the Soaring Eagle on 3f (and other pieces defending 2g and 1h) can easily be threatened with capture, and one wrong move can result in a smothered mate. The point is, you should not need to use an AI to find a good opening.

Unfortunately this is not so easy, because BadZone only gets the locust squares passed. Not the pieces jumped over. The non-destructive intermediate squares are not part of the internal move representation. But I suppose BadZone could be made such that it scans the board for high-rank blockers along the path from origin to destination itself.

You can just use board[y][x] & 511 for the piece type, and a call to a recursive function that scans the in-between squares to handle the rest.

Ok, fair enough.

Ok. Thanks.

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.

That's a really nice feature. For example, it saves a huge amount of time in the diagrams for Suzumu Shogi and Mitsugumi Shogi from not having to check nearly as many locations for Heavenly Tetrarches (which which immobilize non-Tetrarch pieces) during move vetting. I've now implemented the new code in the Rules pages for these games.

Also, can you approve the Rules pages for Suzumu Shogi and Mitsugumi Shogi? I've been waiting rather patiently, and their corresponding GC Preset pages have been approved, but the editors haven't seemed to notice the Rules pages, possibly due to the new sorting method for the Review New Submissions page.

I don't know how to approve articles; I limit my activities as editor to inserting Interactive Diagrams in existing articles, and improving the infra-structure for doing this. I am the only editor working on this task, and it doesn't seem a good idea to reduce the time I can spend on it by also taking up tasks that other editors can do.

That's OK. I assume you passed that along to another editor, and they approved it themselves.

It would be a misconception to think editors communicate amongst each other by any other means than the comments you can read here...

Well, whatever the case, the issue is settled. I'll let you get back to working on the Interactive Diagram code.

BTW, the tracking, and thus the marking the spell zone of the indicated piece, currently only works correctly if there are not more than two pieces of that type in play. Otherwise it will loose track of some of the pieces. The current way I use for tracking just keeps two locations (in loc[coloredType] and loc[coloredType+512]), of the last two pieces of that type that were moved during the search. (And it then only marks the spell zones around those.) Now this is fine for Mitsugumu Shogi, but in Suzumu Shogi there can potentially be 4 Tetrarchs. This is of course unlikely to happen in a real game, so perhaps we should not worry about it at all.

I can switch to a more robust way of tracking, able of handling an arbitrary number of pieces of the same type. This would cause a slight slowdown, though. Which is a pity, as almost no game would use it. An cheaper alternative would be to allow requesting spell zones around more than one piece type, so that piece types of which there can be more than two instances can be artificially split into two identical types. The location of each piece is tracked anyway, it is just a matter of marking the squares around the designated types before every move generation, and pieces where only a single type cause spells would not experience a delay by this.

It would even be possible to mark the spell zones of different types differently, e.g. as nodes | (1<<(24+K)) for the Kth spell zone. This would allow, say, freezing and burning in the same Diagram. The test for being in the zone would than have to be (neighbors[sqrNr] & 0xFFFFFF) == nodes. I wonder if all that complexity would be worth it, though. I am not even aware of any variants that would need it.

You could increase the cap of instances of one type for trackPieces to four without much trouble. This would take care of the 3+ Tetrarches problem in Suzumu Shogi while leaving plenty of room to handle the vast majority of cases. However, the more robust tracking method would be preferred for games using Chess-style promotion (you could have up to (#startingSpellPieces)+(#piecesPromotableToSpellPieces) pieces with spell effects).

As for multiple spells, I agree would not worry about that right now, as I can't see any variants that will be using that either. Besides, there is also the frozen variable, the 251 kamikaze promotion, and the 512(+[bits]) promotion methods, which can be used to implement spells in the xxZone, xxxPromotion, and xxxTinker scripts withouts using the spell parameters.

@Adam: I see that you are using your own markers. Beware that I have added a new marker (markerFFF000.png), which the betzaNew.js script uses for indicating moves of a piece that has active burning defined for it through the captureMatrix in the move diagrams. It then also indicates the blastZone on hovering, by making the background of the burned squares around the indicated target grey.

Thankfully that's very easy to do, as my markers are all simple circles.

Would it be possible to implement a system to allow the inclusion of pieces with multiple-character IDs in the Diagram parameters that use them? If you need suggestions for how to implement something like this, Fergus uses a system in his FEN parser for Game Courier that surrounds multi-character piece IDs in {} curly brackets (e.g. {+P} for promoted Shogi pawn).

P.S. Those empty comments were me trying to insert this comment while I was not logged in, which may be the result of a bug.

I guess I don't really need the curly bracket enclosures.

However, I do need help with captureMatrix. I'm trying to use it to replace the modified NextLeg Function in Suzumu Shogi and Mitsugumi Shogi, and it works, but it seems to exclude certain cases where hops should be allowed (such as hopping over a lower-ranking friendly piece). Strangely, Minjiku Shogi does not have this problem. The captureMatrix value I have so far is this:

captureMatrix=//////////////////////////27^27,27^60,27^28,27^61,27^34,27^64,27^35,27^65,27^37,27^46/28^27,28^60,28^28,28^61,28^34,28^64,28^35,28^65,28^37,28^46//////34^34,34^64,34^35,34^65,34^37,34^46/35^35,35^65,35^37,35^46/////////////////////////60^27,60^60,60^28,60^61,60^34,60^64,60^35,60^65,60^37,60^46/61^27,61^60,61^28,61^61,61^34,61^64,61^35,61^65,61^37,61^46/././64^34,64^64,64^35,64^65,64^37,64^46/65^35,65^65,65^37,65^46
 

Now I've got it figured out. Thanks to this, I no longer need the modified NextLeg function (jumpClass is still needed to for the multi-captures though).

Now I have it figured out. Thanks. I'll also redo the Tenjiku Diagram so it uses captureMatrix instead.