Comments/Ratings for a Single Item

On my Kindle Scribe, which displays red as white, all the spaces are white, making the board appear completely uncheckered. I do see the pieces on it, though, even though I don't see them on my desktop.

I switched around to another color option (which is also easier on my eye). Hopefully it doesn't make it worse on your other devices.

On my Likebook Mars, which displays red as black, the shades, while distinguishable, are close together, particularly in A2 mode. So, I would recommend another color for the light squares.

I'll also mention for H. G. that the text with a red background appears all black on my Likebook Mars, making it unreadable.

Thanks, Fergus! It turns out that I'll have to wait until some of my waiting variants are approved, but now at least I know how to do it.

You make a page with a link to it. When you're signed in, goto the menu with your name at the top and select the menu item "Post Your Own Game". It will give you an option for submitting a Game Courier Preset. Choose that, fill in information about, and on the next form, enter the content of your page.

I think the Game Courier Preset for this game is ready to go. I'm not clear on how to get it listed on the Index or anything, though.

As for availability, not yet, but they will be once I upload them and Dealer's Chess gets approved.

As for SVG, sorry, no. I wish I could, but I'm stretching myself enough already making them as PNGs.

Are those Alfaerie icons you have created available for other people? Have you drawn them as .SVG?

I've already downloaded the entire Alfaerie set from the applet, plus a few dozen icons from the "Alfaerie Expansion Sets" mass-converted from gif to png, and put them into the same network drive directory along with all of the pieces I've created, using names I'm satisfied with (almost two dozen of them, including a few that I'm not using right away but think should be available).

(And looking at the original crocodile, gryphon, and dragon from that set does make me feel a little better about my dolphin and turtle.)

That sounds right; in principle this method for assigning images in Game Courier needs all images in one directory, and it doesn't matter which. It doesn't have a special facility like the ID to look for images in other directories.

I am not sure the following trick would work, though. Path names can be absolute (when they start with slash) or relative, and it is possible to specify a path to another directory that is not a sub-directory of the current one by using .. for indicating the parent directory. So if the specified piece directory is /graphics.dir/alfaeriePNG, and you specify an image filename as ../../membergraphics/MSdealers-chess/mypiece.png it could indicate a piece elsewhere. I am not sure whether the browser or server would not block the use of .. for security reasons, though.

(In the ID this trick would not work, because the image names must be specified without the color prefix, which would no longer be prefixes, but have to go somewhere in the middle if you would try to use a path name, so I had to make a special provision there for the use of 'guest piece'.)

A couple of considerably improved Spy icons:

I think I'll keep the other one, though, in case I ever need a Courier.

OK, then, so if everything else is OK (as I mentioned before), it's mainly just a matter of getting the graphics set to match the ID, which I think is just a matter of putting them all in one place. (If nothing else, I can collect all the "official" graphics and the usable ones of my own creation/modification into the Dealer's Chess graphics directory, and direct everything there.)

Is it all good, as far as you can tell from your vantage?

Two captures per turn is OK, as long as one of those is the normal replacement capture. The restriction is on the number of locust captures; there can only be one of those. This because the GAME code in the betza.txt include file represents a move as 3 squares plus one piece type to drop; the 3rd square specifies where to drop it, and if the dropped type is an empty square the piece that was sitting on it would be locust captured.

I just realized that the Berserker, being merely a renaming of the Japanese Lion from Chu Shogi, is another piece here that can make more than one capture per turn. Argh....

I've edited in the text portion (as well as fixed some of the text on this page), so if the Post-Move sections are OK, all that's left is getting the graphics to match those used in the Interactive Diagram.

I had the wrong ones capitalized before; this is that section now in Post-Move 2:

In Post-Move 1, the h at the top is capitalized, and the K and Q at the bottom are not.

If that's correct, then all that's really left (except for the text part, which I'm pretty sure I have a handle on) is getting the four piece graphics I made for this game (for Berserker, Bowman, Soldier, and Spy) to appear in the GCP as they do in the ID. For that, unless I'm misunderstanding something, I can just upload the existing graphics for the Alfaerie set that are used in this to /membergraphics/MSvanguardchess/ (where the new ones are already located) and change setsystem dir "/graphics.dir/alfaeriePNG/" to look there.

Yes, you can remove all of those, since I now made the default of promotables the empty array. If no piece can ever be found in promotables, it would not use supply or promotab.

You are right; in dec k and set k ... k is a variable.

But you capitalized the wrong ones: when the white Helepolis moves, you have to test for capture of black K and Q, or vice versa.

Run button: Ah, OK, so it wasn't my fault this time. That's a relief.

Capitalizing K & Q: I capitalized them in the Pre-Move 1, instead of the Pre-Move 2. I'm not sure whether I need to capitalize the K other than in the "if" section; I left it lower-case, because it looks like the k in the preceding lines is a variable..

Promotables: Should I just remove the promotables, supply, and promotab parts then? (And yes, that was while I had maxPromote=0.)

when I press the Run button, I get a text list of legal moves for White, one per line, before the board.

Ah, sorry about that. I had been debugging the other day, and had accidentally left in one of the print statements I had added for that purpose in the betza.txt file. In the mode where I tested it ('Move' from the menu) this output does not show up at the start of the game, but only after the GAME code crashes (which after debugging it did not do anymore). So I had not noticed this. I removed that print statement now.

You forgot to capitalize K and Q in the h part.

I don't think the 'promotables' belong in the Pre-Game code. This would indicate which pieces promote with the choice that is specified in the promotab (which is N, H or L on last rank). But you don't want any choice; you just want them to promote automatically as specified in the morphers/morphs arrays. Did the Play-Test Applet generate that 'set promotables' line? And was that while you had maxPromote=0 in the ID?

OK, so currently Post-Move 1:

And Post-Move 2:

Hopefully I have all of the capitalizations and instruction order correct.

I do think I have something screwy in the Pre-Game, though; when I press the Run button, I get a text list of legal moves for White, one per line, before the board. The Pre-Game looks like this:

Once this is sorted, I can start in on the text, and probably working with you and/or Fergus on getting the graphics icons I created for this game into the preset.

OK, I'll work on replacing all of those 16's with 4194306, and then insert that code. But there's a possible snag: the Helepolis's juggernaut move should be stopped by the presence of a friendly piece. Is this accounted for there?

Edit: Never mind the question. Upon re-reading, I see that it's accounted for.

The moves with mode 4198464 are not juggernaut moves. After converting that number to hexadecimal (401040) I can see that they are marked as initial moves.

I think (unless my brain is glitching something) all that's left is getting the code in to clear out the juggernaut's path, and mark whether the victims include the King and/or Queen.

Sort of. The 2 -> 16 replacment changed the c mode of these legs to p mode. But that would allow enemy as well as friendly hopping, and this is not what you want; firendly pieces in the path should not be destroyed or jumped over. This would have been achieved by (cafu)14R, not (paf)14R, using the capture+unload kludge. So I am afraid we realy should have needed to replace by 4194306 instead of 16. Which is hexadecimal for 400002, the 2 standing for capture, and the 400000 for 'but unload on the next leg'. Sorry about that.

For clearing the Helepolis juggernaut path you can use something like this:

if == H #mover:
  set p path #ori #desti;
  set k count #p;
  do while #k:
    dec k;
    set sqr elem #k #p;
    set v space #sqr;
    if isupper #v:
      break;
    endif;
    empty #sqr;
    if == k #v:
      set victim k;
    elsif == q #v;
      set vic2 q;
    endif;
  loop;
endif;

The conditional break is needed to prevent removal of the friendly piece when the initial moves hops over one; the way the table now defines the Helepolis other moves can only have hopped over a number of enemies

I adjusted the ID to include the graphics below, and I think it looks good.

Testing some more icons:

• Berserker (take 2)
• Soldier
• Spy

I may want to workshop the Spy a little, but on the whole I think they look satisfactory.

OK, I got all of those 2's converted into 16's.

I assume I don't need to worry about the ones that end in 4198464, and that the Post-Move codes that I posted earlier are OK.

I think (unless my brain is glitching something) all that's left is getting the code in to clear out the juggernaut's path, and mark whether the victims include the King and/or Queen.

After that, it's mostly just text and graphics (the latter consisting of redoing the Berserker with 2-pixel lines, and trying to figure out a Soldier and a Spy that don't look pathetic.)

Yeah, I did notice that. It's not quite up to asking Fergus to add it to the official set, but it'll do for now (and I'll probably fix that outline before all is done).

And congratulations on the Nobel thing. :)

Nice, but the Berserker needs thicker outline.

Berserker

Off-topic fun fact: my name appears three times in the announcement of this year's Physics Nobel prize (reference 18, 23 & 36). Nobel laureate Pierre Agostini was a close colleague of mine, and I spent a year in Paris in his group as a post-doc.

So now I have the Post-Move 1 looking like:

And Post-Move 2:

I'll get on that Helepolis move in a wee bit....

You should make sure vic2 has a value; that of victim is set in the HandleMove code. Immediately after that you can copy it to vic2 by

set vic2 #victim

There then is no need to use #victim for succession of the Queen; it would do exactly the same as the code that used #vic2.

That reminds me of a flaw in the code; Prince, Princess need not be present. (And certainly would not be the second time, when you attempt it twice!) The search command would then return an invalid location, which would probably crash the following add command. So the add should only be executed if search found the piece, by replacing it with

if #p:
  add k #p;
endif;

The Helepolis moves are described in the Pre-Game section like this (but very many more):

4 99 -1  0     2
  99 -1  0     2
  99 -1  0     2
  99 -1  0     3
5 99  1  0     2
  99  1  0     2
  99  1  0     2
  99  1  0     2
  99  1  0     3

where the number in the first 'column' indicates the number of legs, and the last number the allowed occupancy of the final square of each leg. The 2 there means it has to end in a capture, but since the generic code can handle only one such leg (and here they would run up to 14), you would have to replace the 2 everywhere by 16 (which means that it should end on the mount of a hop). The 3 in the final leg you can leave (it means capture or move to empty).

Actually, I had a little time before going on to something else, so I fiddled around and found better pics already in the array for the Prince, Princess, and Chancellor (these are already updated both here and in the GCP), and tentatively generated pieces for:

• Berserker
• Bowman

If these are deemed good, then I can see what I can figure out for the Soldier (the current Soldier can become the new Sergeant) and the Spy.

Addendum: Well, they at least appear to be working OK on the Interactive Diagram.

OK, fine, then. Now Post-Move 1 is:

While Post-Move 2 is:

If I got that part right (I felt that vic2 was a better mnemonic than v2; in any event, I feel like I misread something), all that's left to worry about right now is the really hard part: the Helepolis.

I still had the Helepolis on the old RcamfRidaufmRsb(caf)14R move code when I built the initial GAME code; I hope I don't need to fix that and regenerate the code when I turn to that part (though it's probably not a huge problem if I do). If there's a simpler way to go about it, I'll take it!

Then I can start poking around with Inkscape, Paint, and/or GIMP to see if anything decent comes out, in between developing text.

I presume that the capitalized counterpart would go into the Post-Move 2 section, and both would also need the q/pc (Q/PC) conversion as well.

Correct, but note that I was still doing an edit of my earlier posting that crossed your latest message.

BTW, 'buldozer move' is not a standard term, it is just what came to mind when I saw this kind of move. 'Juggernaut move' also excellently covers it.

I presume that the capitalized counterpart would go into the Post-Move 2 section, and both would also need the q/pc (Q/PC) conversion as well.

I guess you would need something like:

if == k #victim:
  set p search pr $space;
  add k #p;
endif;

at the end of the Post-Move 1 section, to take care of black's Prince promoting to King when white captures the black King.

[Edit] This did not work; apparently the search operator cannot operate on a system variable like $space. So you have to copy that first:

if == k #victim:
  set brd $space;
  set p search pr #brd;
  add k #p;
endif;

When I do get into the heavy editing: Do you think it'd matter whether the #victim test or the Helepolis test is done first?

In the code it would probably be easier to do the Helepolis move before the succession test, because the succession then can also take care of the case where the Helepolis did overrun the King. If you encounter a King in thr process of removing the locust victims you could set victim to k, so that the succession code is later triggered. Unfortunately you have to prepare for the case that K and Q can be captured on the same move, and you cannot set victim to K and Q at the same time. This could be solved by making a copy of victim (set v2 #victim;), and use that for testing the Queen succession; the Helepolis code can then set victim to K and v2 to Q when it encounters any of those, without spoiling succession of the other.

OK, I have the pawn promotions fixed on both diagrams.

I'll start looking at the other two things (probably royal promotions) later today.

Thanks for the help!

You should add a parameter maxPromote=0 ; then it doesn't matter what the zone depth and promoChoice are, as they would never be looked at. Your Pawns promote per morph instructions.

Yeah, the ID has a lot of screwy stuff, and needs a good bit of fixing. Whatever has Pawns morphing to Queens should be edited out. (Should that line be just "promoChoice=" with nothing?)

I'll see what happens when I convert the ID with the new applet before I go about doing a lot of editing.

When I do get into the heavy editing: Do you think it'd matter whether the #victim test or the Helepolis test is done first?

(Personally, I like to call that a "juggernaut capture," but I can switch to "bulldozer capture" if that's an established term.)

Oh, and my apologies for not including the link. (D'oh! once again!)

If you expect help it might be an idea to post a link to the preset, so that people can see how you are doing...

Did you use the Play-Test Applet to convert your Interactive Diagram? If you would have used the new version of that, the morph parameters in the Diagram would have been converted to GAME code too, and the promotions should work. Except that your Diagram seems to contain contradictory instructions: on the one hand you define a promotion zone, where Pawns should promote to Queen that had been captured before, but at the same time you specify they should morph to Knight there. No idea what the GAME code would do in that case.

For K and Q replacement you could append code to the Post-Move sections to figure out whether the piece captured in that move (available as the variable #victim) was a K or Q (of the applicable color). And if it was search the board for the Prince or Princess (there is a GAME-code instruction for that), and promote it. SHould not be terribly complicated, except that the Helepolis could have captured K or Q too on other squares as its destination (so that this would not show up in #victim). So the code to handle Helepolis buldozer captures should also test for this, and relay the result of that test somehow to the code that performs the succession.

OK, I have the basics of the GC preset in place. I was able to figure out the worst problems on my own (all it took was making sure the two-letter piece codes were in all caps). Things I still need to figure out how to do (that I can identify right away) and/or get help with:

• Fix the Helepolis move.
• Require promotions of Pawn -> Knight, Soldier -> Helepolis, and Sergeant -> Lancer upon reaching the back row.
• Arrange for Prince and Princess to promote to immediately replace a captured King or Queen (respectively).

Once those are done, I can:

• Decide whether to make new graphics for the Berserker, Bowman, Chancellor, Prince, Princess, Sargeant, Soldier, and/or Spy; and, if I decide in favor, actually do it and send the work to Fergus (unless, of course, someone beats me to it).
• Write out piece move text (using the [pc] shortcode). (Side note: Where does this go?)
• Put text of other rules into the Rules section.
• Take care of anything else I've forgotten.

Have you thought about adding this to game courier?

I finally got a start on this this evening, and so far it's had more wrinkles than my Jedi Elvis costume when it's straight out of the suitcase. I'll have so many questions for H.G. (and probably Fergus) when I go back to it Monday....

OK, that's definitely good to know. Thanks for the note on that, H.G.

Addendum: I have it now looking like I think it should. Now to work on the Game Courier code....

Unfortunately the betza.txt GAME-code include file does not support more than a single locust victim per move. (Which is the same limitation that the betza.js script imposed on the ID, end was only relieved in the betzaNew.js that is under development.) It is not even possible to use the option of defining Custom Pieces, as the problem is not only in generating the move, but that the employed move encoding and code that finally applies the generated move to the board has no provisions for more than a single locust victim.

A work-around for when you still would want to use the Play-Test Applet system for automation would be to define the Helepolis 'buldozer moves' as multi-hopping, rather than multi-capturing in the Diagram you are going to convert, and then append some GAME code to the Post-Move sections to remove all pieces that were hopped over.

Just a thought: What if this could be done with i^pfmR? Would that confuse things too much?

I don't see the logic of that; considering that ^ in the captureMatrix means "cannot hop" combining it with p seems more confusing than helpful. And if there is to be a special XBetza modifier for friendly hopping, there should also be one for hopping only over enemy pieces.  It is true that allowing non-alphanumeric caracters as modifiers solves the shortage-of-lower-case problem, but ^ seems a bad choice. I once did consider using p' and p" for friendly and enemy hopping, or using general 'limiters' in the form {...} behind modifiers to restrict their action to the enclosed piece types. But it seemed bad to have piece ids, which are very variant specific, appear in the XBetza notation, where capitals already mean something completely different. The capture matrix seems a much cleaner solution for all type-specific interactions. And color is just one aspect of type, so it can also be used to resolve the color-blindness of some of the XBetza modifiers.

I hope to get rid of this kludge, one day. Perhaps this is already achieved, but the price is that you then have to define a captureMatrix. A ^ in that matrix outlaws hopping in a type-specific way, so that you could keep specifying the universal hop ipfmR, and then outlaw doing it over all enemy piece types, but not with friendly piece types, by writing as many ^ as there are piece types (shorthand ^N) in the row for the Helepolis, after a dot . (which would apply to hopping over an empty square, which is nonsense and so doesn't have to be outlawed).

Just a thought: What if this could be done with i^pfmR? Would that confuse things too much?

And, after evaluating the Teutonic Knight (from Teutonic Knight's Chess), I've decided to use its WNC move as a more appropriate expansion for the Knight in this game than the Aurochs. (Plus, it's still a Knight by name.)