Comments/Ratings for a Single Item

Respected Mr. muller,

Question: How to express Non-crossable board positions such as D, H, WX, DX, HX, WXX, etc.?

Huge benefits with non-crossable board positions. could create thousands of fun chess variants, suitable for brain exercise mental computation.

Thank you so much!

It seems I need @Fergus for this.

The loop in the move generator of the betza.txt include file for generating slider moves looks like this:

      set k 1;
      do while < #k #r and not #hit: // for non-final (and thus empty) squares
        set to elem dec #k #tosqrs;
        if #togo:
          set newindex + 4 #legindex;     // another leg follows
          gosub NextLeg #togo #newindex #startsqr #to #locustsqr #dropsqr #k;
        else:
          gosub GotMove #startsqr #to #locustsqr #dropsqr 0 0;
        endif;
        if & << 1 23 #mode:
          push eps #to;
        endif;
        inc k;
if == 4 #task:
print . L_ #hit;
endif;
      loop;

where #tosqrs is an array of all the empty squares on the slider path. The variable #hit, initialized to false, serves for flagging if the sought move (e.g. the entered one, a legal one or capture of a royal) has been found, so that move generation should be aborted.

In the mate test (where #task equals 4) for the position given by Carlos below, the move Qe3-h6 is correctly found to be a legal one, which sets #hit, as is confirmed by the printing of L_1 by the print statement I inserted for debugging. As far as I understand this should have terminated the do-while loop, as not #hit is then no longer true. But the loop happily continues with the move Qe3-i7 (the next empty square in that direction), and subsequently generates all other pseudo-legal moves for the position. The last one being illegal because it does not evade the Sissa check, so that the verdict 'checkmate' results.

What is going on here that makes the loop continue?

The function 'Paste an existing diagram:' in your 'Play-test applet for chess variants' can't be realized via the indirect way of 'Notepad' - thanks for the tip, would have been nice if!

Well, it works for me, also when copying the ID in the Conquer article through NotePad into the Play-Test Applet. Are you sure you did not try to copy any of the enclosing HTML tags together with it?

This is a moot point, however, since the GAME code generated would not work as desired. Conquer is not a variant that is supported by the standard functionality of the Diagram. It needed custom scripting to alter the generated capture moves such that they would place a color-reversed version of the victim on the square of origin. The XBetza notation does support 'unloading' the captured piece there with the aid of the u modifier, but there is no provision for flipping its color. So additional JavaScript embedded in the page was needed for that, and this cannot be converted to GAME code by the Applet (even if it would have been pasted into it, which it is not).

I suppose we could decide to make uu mean color-flipped unload in XBetza. But that would then have to be implemented in the ID, as well as in the GAME-code include file. It is unlikely this will be done any time soon.

I don't think it would be possible to implement the function performed by the additional JavaScript in the generated GAME code by post-editing the latter.

I set up a simple loop similar to your own to see if I encountered the same problem:

set k 1;
set r 5;
set hit false;
do while < #k #r and not #hit:
  echo #k #r #hit;
  dec r;
  set hit true;
loop;

This looped only once. I changed what hit is set to to "e1" and got the same result. So, the problem does not seem to be with the logic of the looping condition. Has any of the subroutines you called changed the value of k or r?

Has any of the subroutines you called changed the value of k or r?

Thanks for the suggestion, printing #k and #r as wel as #hit solved it. Not that these were changed, but #r was one less than I had expected, because the loop was not supposed to go over the entire slider path, but only over the 'internal' squares (which are always empty). And it left the final step to code after it (that also has to test the occupant to determine whether the move would be valid). That it continued with Qe3-i7 was thus the fault of this other code, and not of an extra loop iteration, as i7 was the last square on the ray. This code should have tested whether #hit was set in the loop as well.

The problem of the false mate claim should be solved now; instead of testing #hit in the condition for the do-while loop, I put a

verify not #hit;

at the end of this loop. This aborts the subroutine immediately when #hit gets set in the loop, thus also suppressing the code after the loop.

I have confirmed that the problem has been resolved. Thank you very much HG and Fergus.

@HG:

I'm sorry. Bothering you again. In the Symmetric Sissa preset (which was edited using the Play-test applet) the software does not properly declare checkmate for either side (white or blue); instead it warns on a new page:

Please report any bugs or errors to H.G. Muller

blue wins

Use your browser's BACK button to go back to the previous page, then reload if necessary.

For general reference, here is the complete list of moves:

1. P h2-h3
1...n h8-i6
2. A g1-h2
2...n i6-h8
3. A h2-c7

If this is your settings file, you may edit it at https://www.chessvariants.com/play/pbm/play.php?game=Symmetric+Sissa&settings=9x8-enforced&submit=Edit

Apart from this problem, the preset works perfectly fine. I don't think I made any mistakes when applying the Play-test applet.

Argh! I left in a 'die' statement that I had added for debugging, to make sure it would show the page with all the stuff I had it print when it thought it had a checkmate, rather than just terminating the game. I forgot to remove that after the problem was fixed.

I removed it now, so things should work again.

Indeed it works fine again. Thanks!

I suppose we could decide to make uu mean color-flipped unload in XBetza. But that would then have to be implemented in the ID, as well as in the GAME-code include file. It is unlikely this will be done any time soon.

I don't think it would be possible to implement the function performed by the additional JavaScript in the generated GAME code by post-editing the latter.

I think it's a pity that a however 'new' structure (Conquer) can't be played on Game Curier.

Of course, everything can be realized if the special programming skills exist. But they do not in my case.

Then so it shall be. Too bad.

I suppose we could decide to make uu mean color-flipped unload in XBetza. But that would then have to be implemented in the ID, as well as in the GAME-code include file. It is unlikely this will be done any time soon.

FWIW, I support this idea in general (I've seen more than one case where this is done), though I certainly agree that there are more important priorities right now.

Well, people without programming skills have been making Game Courier presets for their variants for ages. By making a preset that does not check the rules, but leave that to the players.

I've been setting about making an ID for Short Sliders using the new (WIP) version of the applet, and running into some roadblocks. Alot of it, I think, is my lack of understanding, though some may be weaknesses in the system. (And some of it pertains more to information on the Interactive Diagrams page; I'm just putting everyting here.)

1. Are morph variables limited to one character? When I set (for example) the Jackal's promotion to the Bongo, the system changes the Bo to B. (replaces the o with a period). I'd really rather not have to rework all the symbols.
2. After a long period of selecting all the pieces, I saved the setup to come back and build the Capture Matrix later. It won't let me do that! I can load it, but I can't do anything with the Capture Matrix. (I'd build the Capture Matrix manually, but there's no demonstration of what that should look like.)
3. Possibly more something for Fergus: Using the Showpiece tool, some of the pieces don't recolor for black, none of the compound images render, and (oddest of all) the Hospitaller comes up as a blank.
4. Not really a problem, but in the end does it matter what order the pieces are (discounting Pawns at the beginning and Royals at the end)? I'm trying to arrange the pieces into something more intuitive to the game (Starters, then First Promotions, then Second Promotions), and so far it hasn't complained.

I'll wait for another time for things like limitations on promotions to Thaumaturge, Pawn selections between Starters and First Promotions, and complicated stuff like that.

Are morph variables limited to one character?

Currently they are. But it is my intention to allow comma separation of multi-character piece IDs. In that case, if a row of the matrix contains a comma, it would split the row by comma, and take the n-th string of the split rather than the n-th character of the row as the piece ID.

After a long period of selecting all the pieces, I saved the setup to come back and build the Capture Matrix later. It won't let me do that! I can load it, but I can't do anything with the Capture Matrix. (I'd build the Capture Matrix manually, but there's no demonstration of what that should look like.)

I suppose you are referring to the submission page with a provision for diagrams? I have not really considered what would be needed to edit an existing submission that contains a Diagram. I suppose this would be hard, as the final product of this is the HTML code for the diagram in the Setup section. I suppose I could peel that out (in case other text was added to that section), and treat it like it was pasted in the Play-Test Applet. This would limit the piece table to the pieces in the diagram, though, so you could not add additional pieces. So it would not provide full editing capability.

Anyway, the captureMatrix is not hard to add manually. Basically you just write all rows separated by slashes. There are many shortcuts for saving on typing, (which are not used by the applet on the submission page that generates it), all explained in the Interactive Diagrams article.

Not really a problem, but in the end does it matter what order the pieces are (discounting Pawns at the beginning and Royals at the end)?

The Diagram's AI searches captures sorted by value of the victim (high to low), and then in ascending table order of the attacker. Since it is usually most best to capture with the least-valuable piece (e.g. imagine a protected Rook attacked by a Knight and a Queen), it would slow down the search if the table order differs significantly from low value to high value. But in the end it would find the same move (unless two moves really have exactly the same score).

I suppose you are referring to the submission page with a provision for diagrams? I have not really considered what would be needed to edit an existing submission that contains a Diagram. I suppose this would be hard, as the final product of this is the HTML code for the diagram in the Setup section. I suppose I could peel that out (in case other text was added to that section), and treat it like it was pasted in the Play-Test Applet. This would limit the piece table to the pieces in the diagram, though, so you could not add additional pieces. So it would not provide full editing capability.

Actually, no; I was referring to pasting a diagram's definitions on the new-version Applet page, and then editing it to include a Capture Matrix.I have all the pieces in place, so that's not an issue.

As to writing out the captureMatrix manually, I'll give it a shot. (The explanation in the article is OK, but I'd prefer an example so I can feel confident in getting it right.) Because of the single-letter issue, I'll write it out with the comma-delimited feature you mentioned and wait for you to implement that before giving Short Sliders its Diagram.

I suppose you are referring to the submission page with a provision for diagrams?

Wouldn't you know, but that I've lost track of the link to that.

http://chessvariants.com/index/hgmsubmission.php

Thanks yet again! :)

Since Kevin Pacey was having problems with a preset he generated with this applet, and I have never tried to generate a preset with it before, I generated one as a test to see what I would get, and I saw this in the generated code:

set mypieces assoc
  P "wpawn.png" p "bpawn.png"
  K "wking.png" k "bking.png"
  G "wwildebeest.png" g "bwildebeest.png"
  H "wbird.png" h "bbird.png"
  S "wsquirrel.png" s "bsquirrel.png"
  C "wchampion.png" c "bchampion.png";
setsystem dir "/graphics.dir/alfaeriePNG35/";
setsystem pieces #mypieces;

I strongly recommend against including code like this. Instead of this, I would recommend using one of the auto sets or a complete enough set, then adding aliases for any piece whose notation does not match the label provided by the set. The auto sets would be useful for this, because the auto labels, being based on piece names, are easy enough to calculate. In this case, you would want to use the auto-alfaeriePNG35 set with code like this:

alias 
P PAWN p pawn 
K KING k king 
G WILDEBEEST g wildebeest 
H BIRD h bird 
S SQUIRREL s squirrel
C CHAMPION c champion;

Also, the FEN was inaccurate. It gave me this: 4k55K3.

As you can see, it omitted every piece except the King. Using an auto set, you could correctly calculate the FEN. In this case, it would be something like this:

{bird}{wildebeest}{squirrel}{champion}{king}{squirrel}{wildebeest}{bird}{pawn}{pawn}{pawn}{pawn}{pawn}{pawn}{pawn}32{PAWN}{PAWN}{PAWN}{PAWN}{PAWN}{PAWN}{PAWN}{BIRD}{WILDEBEEST}{SQUIRREL}{CHAMPION}{KING}{SQUIRREL}{WILDEBEEST}{BIRD}

Also, the FEN was inaccurate. It gave me this: 4k55K3.

As you can see, it omitted every piece except the King.

You might have forgotten to press the 'Start Position' button after seting up the pieces. The Applet allows you to put more pieces on the board after fixing the initial position, which will then be available as promotion choice in the Diagram / GAME code you produce from it without being included in the initial setup. If you don't press the button, the initial position stays what it was when you opened the page, i.e. just the Kings.

You might have forgotten to press the 'Start Position' button after seting up the pieces.

I surely wouldn't forget to do something I never knew to do in the first place. But now I've done this, and it produced this fen code:

hgscksghpppppppp32PPPPPPPPHGSCKSGH.

I put this in this preset here:

https://www.chessvariants.com/play/pbm/play.php?game%3DExperiment%26settings%3Dfpd-experiment1

The board looks accurate when you click on the link, but if you click on Edit, the board will look very different. Here, without running the GAME Code, it has some question marks, and the only pieces it gets right are the Kings and the Pawns.

It would be less confusing for someone creating a preset if there was no discrepancy between how the board displays in Edit mode and how it displays while playing the game. This can be done by relying on a set instead of defining the pieces in the Pre-Game section without reference to a set. You could use an auto set, which makes it easy to calculate the label from the file name, or you could make your play-test applet more integrated with Game Courier sets, though that would require writing some PHP to find out what is in the set. So, using an auto set is probably the easier way to go. The general rule for an auto set is that each label is the piece name extracted from a file name after removing the side prefix and the image format extension, all in uppercase for White, and all in lowercase for Black.

It would be less confusing for someone creating a preset if there was no discrepancy between how the board displays in Edit mode and how it displays while playing the game. ...

Well, the logical problem here is that the Applet does not know the association of piece labels and images used by the set, and doesn't know what set is going to be used in the preset. It only knows the piece IDs and image names used in the Diagram that is being converted, or coming from the ID assignment in the piece table if the user has been setting up the position from scratch. This is all a legacy from the time there were hardly any automatic sets, so people were mostly using sets with 1-letter piece labels, which, to cram as many images as possible in a single set, were often very unnatural, and not at all what the converted Diagram had been using. And the assignment would differ from set to set.

What we need is a set that contains all piece images an Interactive Diagram could possibly contain, and then require that the presets to be automated this way use this set and none other. Currently the GAME code generated by the Applet uses the piece IDs defined in the Diagram as piece labels. But it could just as easily be made to use the 'root name' of the image files as labels, converting to upper/lower case as necessary. Since the Applet's piece table uses the alfaeriePNG directory as a basis for what pieces to offer, the auto alfaeriePNG set would be suitable.

This approach relies on automatic sets being available for every theme that could have been used in the Diagram to be converted. It would not be a problem that we have no unity in image naming between themes, as long as people would use the auto set for the theme that was used in the Diagram they were converting.

A minor flaw is that the Diagram now allows the use of 'extraneous' pieces, i.e. with images from another directory than graphicsDir, and possibly of anothe image type, which are specified as an arbitrary filename / URL. The auto sets would not provide these pieces, which would drive people to using other sets, nagging editors to create those for them. Which then often would use names for the other pieces different from the full name in the auto set where most of the pieces were coming from.

One way around this would be to stop creating such dedicated piece sets, but instead service the request for a set with pieces not provided in the automatic set for that theme by expanding that automatic set with the requested 'non-automatic' piece.

I still think this is all a consequence of Game Courier not being able to directly associate piece labels with arbitrary image filenames (other than through GAME code, which causes the problems we are now dealing with), but uses this cumbersome indirect method of a (by now huge) number of package deals in the form of the sets.

If piece labels could be arbitrary URLs we could have a 'direct set', which is sort of a universal automatic set, which would not be limited to fetching the images from a fixed directory, but would derive the directory from the label on a piece-by-piece basis. But I suppose URLs contain characters not acceptable in piece labels. We could nevertheless define an escape convention for those. So that the set could serve any piece image on the website, without editor intervention.

If I set things up so that constants of @pieces and @dir automatically replace $pieces and $dir, then this would let the correct pieces show up even in Edit mode. However, this would break the ability to switch piece sets. I’m also concerned about making these special cases. Maybe I could create a new variable type of super constants, or I could use a @superconstants constant to designate constants that override system variables.

Another possibility is to accept json-encoded arrays as values for $set. One thing I don’t want to do is let users add arbitrary PHP code, because that would create a security hole. Even the json array might allow someone to change arbitrary variable assignments without some restrictions in place.

One more possibility is to have a section of GAME Code that runs all the time. However, this could make a game uneditable without a back door.

What we need is a set that contains all piece images an Interactive Diagram could possibly contain....

But where would we ever find such a collection? ;)