Check out Symmetric Chess, our featured variant for March, 2024.


[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Latest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments/Ratings for a Single Item

Later Reverse Order EarlierEarliest
@ Gerd Degens[All Comments] [Add Comment or Rating]
H. G. Muller wrote on Tue, Mar 19 07:36 PM UTC in reply to Gerd Degens from 07:10 PM:

It depends on whether they would offer the same promotion choice or a different one. For the same choice all you would have to do is add the line

maxPromote=2

to the Diagram definition, and make sure the two promotiong pieces are the first two in the table. It doesn't matter what their ID is; only the IDs of the pieces they promote to must be used in promoChoice, never the ID of the promoting piece.

Offering a different choice is possible in the Diagram, by only have the first piece promote normally (the default situation), and defining a second promotion set, and letting the second piece morph to that. But this is not supported in the GAME code yet; only automatic morphing into a single type is supported there.


Gerd Degens wrote on Tue, Mar 19 07:10 PM UTC:

@H.G.: Is it possible to work with two different pawns (e.g. berolina pawn and asian pawn) that are both promoted on the opponent's base line? I think they should have different IDs (I'm thinking of GC), but how does the PTA recognize different IDs for promotion? 
And what if both pawns have the same ID, but they should be morphed differently.
Can't find the solution. Thanks for an answer.


H. G. Muller wrote on Wed, Mar 6 02:08 PM UTC in reply to Gerd Degens from 01:46 PM:

Looking at the Diagram definition in the Page Source I notice this:

  • It says royal=K , but it really should say royal=KJLMOT .
  • The non-royal Queen is defined twice, in the same way
  • The promoChoice parameter isn't useful without zone or morphing to *, and could have been omitted.

The morph parameters seem to do what you describe in the text.


Gerd Degens wrote on Wed, Mar 6 01:46 PM UTC:

@H.G.

Could you please take a look at my new idea.
I'm not sure if I've done it right because of the morph combinations. Thank you very much.


Gerd Degens wrote on Thu, Feb 29 07:23 PM UTC in reply to H. G. Muller from 06:32 PM:

That is because you still have the HTML text that is supposed to go into an article's Pieces section in the Custom Sets text entry of the preset, rather than the description of a custom set.

A completely new matter for me. Now I understand that - it works.


H. G. Muller wrote on Thu, Feb 29 07:14 PM UTC in reply to Fergus Duniho from 07:04 PM:

Great! That is just what I need to avoid auxiliary intermediate variables and testing those with if-statements.


🕸Fergus Duniho wrote on Thu, Feb 29 07:04 PM UTC in reply to H. G. Muller from 07:54 AM:

If not, it seems to be useful to have an operator (let's call it number) that would evaluate to the numerical value of its operand, but to zero if the operand was not numeric, or undefined. So that I could write something like number elem #key piececount, which would give me the expected 0 if #key was not a valid key in the piececount table.

The int operator, which already exists, should do what you want. It uses the PHP function intval to convert its input to an integer, and for input that is not numeric, it will return 0.


H. G. Muller wrote on Thu, Feb 29 06:32 PM UTC in reply to Gerd Degens from 06:26 PM:

That is because you still have the HTML text that is supposed to go into an article's Pieces section in the Custom Sets text entry of the preset, rather than the description of a custom set.


Gerd Degens wrote on Thu, Feb 29 06:26 PM UTC in reply to H. G. Muller from 05:58 PM:

I am not sure what you mean here. A 'transfer' is something you do, so how can it be 'missing'?

Of course, it is me who transfers the script from the piece table to the preset to create a custom piece set. But the point is that it doesn't work - at least not for me. I still get the error message 'Your Custom Set description failed to decode properly. Make sure it has no errors in it.'


H. G. Muller wrote on Thu, Feb 29 05:58 PM UTC in reply to Gerd Degens from 05:09 PM:

In my opinion, however, move diagrams provide a more rapid overview, both for the description of the variation and for the presentation of the rules in Game Courier.

This is apparently a matter of taste, because I hate articles with many move diagrams. Especially of large games. The diagrams dillute the information density by about a factor 20, and you have to scroll like mad to find the information you want. Awful. A simple sentence like "moves 1-4 squares orthogonally" tells me all I need to know, seeing a move diagram with a piece centered on an 8x8 board tells me hardly anything (as the leaps reach the board edge). And for complex pieces a static diagram often cannot really illustrate what the move does (e.g. Chu-Shogi Lion).

For those who want to see move diagrams the I.D. offers plenty of opportunity. You can summon a diagram for every piece without scrolling, either by clicking on the name of the piece (which I usually display to the right of the Diagrams), right-clicking the piece in the Diagram, or clicking in the pieceTable after you opened that.

If I see it correctly, the correct transfer of the piece table when creating a custom piece set in the preset is still missing. Or have I overlooked something. Anyway, I am grateful  for your doing.

I am not sure what you mean here. A 'transfer' is something you do, so how can it be 'missing'?


Gerd Degens wrote on Thu, Feb 29 05:09 PM UTC in reply to H. G. Muller from 03:39 PM:

The piece table and the automatically generated piece description for presenting the variant is a nice feature. A very useful tool for a quick approach. In my opinion, however, move diagrams provide a more rapid overview, both for the description of the variation and for the presentation of the rules in Game Courier. After all, you want to play a variant in Game Courier and that's where move diagrams pay off in my opinion. Perhaps also a matter of taste.

The solution to the highlighting problem in the preset is also great.

If I see it correctly, the correct transfer of the piece table when creating a custom piece set in the preset is still missing. Or have I overlooked something. Anyway, I am grateful  for your doing.


H. G. Muller wrote on Thu, Feb 29 03:39 PM UTC in reply to Gerd Degens from 01:44 PM:

But what does this HTML sequence have to do with the Pieces section of my description of the variant?

The Piece Table button in the PTA is an aid for those writing an article about a new variant, to save them the work of writing a description of the pieces by hand. If they use the PTA for creating an Interactive Diagram they can copy-paste to the Setup section (after using the Show HTML button), they can use the Piece Table button to get the Pieces section as a free side effect, as a nice table showing the images of the pieces. The Pieces section in my Makromachy article was made that way.

The highlighting problem in the preset should now be solved too. The preset was using the "accelerated legality test" (by default), and this was testing only for attacks on the first royal type in the wroyals/broyals arrays (i.e. K or k in this case). I now changed that to the first royal type that is actually on board.


Gerd Degens wrote on Thu, Feb 29 01:44 PM UTC in reply to H. G. Muller from 11:53 AM:

I don't understand anything at the moment.

HTML according to 'custom sets (only needed for non-standard piece set)' which shows the old PTA under GAME code okay. But what does this HTML sequence have to do with the Pieces section of my description of the variant? Does it fit together? When I enter the HTML sequence in the pieces section and save it, the output only shows the HTML sequence.

I must have misunderstood this completely, right?


H. G. Muller wrote on Thu, Feb 29 11:53 AM UTC in reply to Gerd Degens from 09:25 AM:

This is not code; it is HTML text for pasting in the Pieces section of your article about the variant, if you want to present that as an auto-generated table (e.g. such as I used for Makromachy.)

For defining a custom piece set you need what the (old) PTA prints in the section "Custom sets (only needed with non-standard piece set):" after you press the GAME code button. Something like this:

{
"custom": {
  "dir": "/graphics.dir/alfaeriePNG35/",
  "pieces": {
    "P": "wpawn.png", "p": "bpawn.png",
    "N": "wknight.png", "n": "bknight.png",
    "B": "wbishop.png", "b": "bbishop.png",
    "R": "wrook.png", "r": "brook.png",
    "Q": "wqueen.png", "q": "bqueen.png",
    "K": "wking.png", "k": "bking.png"
  }
}
}

 


Gerd Degens wrote on Thu, Feb 29 09:25 AM UTC in reply to H. G. Muller from Wed Feb 28 09:45 PM:

When a Diagram is pasted in the (old) PTA, and you generate GAME code from it, piece types that are not on the board won't be mentioned in the custom set that is generated.

If I see it correctly, this seems to be the case. Here is an excerpt of the generated code, which concerns the part of the pieces that are not on the board (royal pieces - markings in the text are mine):

<tr><td width="35"><img src="/graphics.dir/alfaeriePNG/wking.png"></td><td>royal pawn</td><td>slides orthogonally, slides to the 2nd square straight ahead for capturing only, or steps one square straight ahead</td></tr>
<tr><td width="35"><img src="/graphics.dir/alfaeriePNG/wking.png"></td><td>royal amazon</td><td>slides in all 8 directions, slides in all 8 directions, or makes a knight's jump</td></tr>
<tr><td width="35"><img src="/graphics.dir/alfaeriePNG/wking.png"></td><td>royal chancellor</td><td>steps one square in all 8 directions, castles by stepping 2 squares towards the king (fast castle), makes a knight's jump, or slides orthogonally</td></tr>
<tr><td width="35"><img src="/graphics.dir/alfaeriePNG/wking.png"></td><td>royal archbishop</td><td>steps one square in all 8 directions, castles by stepping 6 squares towards the king (fast castle), makes a knight's jump, or slides diagonally</td></tr>


Gerd Degens wrote on Thu, Feb 29 08:37 AM UTC in reply to H. G. Muller from Wed Feb 28 09:45 PM:

The suggested lines [set wroyal (K J L M O);
set broyal (k j l m o);] I have tried several times before - and just now again. The following happens: as soon as a white piece is clicked, the game stops immediately and the message 'White lost by absence of royalty!' appears.

It appears I have now solved this.

I have just tested this with the following result:
When the king enters the morph zone, the previous error message 'White lost by absence of royalty!' no longer appears. Instead, the king is shown in the table of captured pieces, which was the case before. The game can be continued, whereby the new king appears to be recognized as such and the king also receives the upgraded or downgraded move options. The only strange thing is that whenever the new king comes into check, this is not shown as a 'check'. The move options displayed for the new king also include those that put him back in check, which should not actually happen. If he makes such a move, an error message 'GameEnd This exposes your royal piece to capture' appears. Moves that free the king from check are possible.


Gerd Degens wrote on Thu, Feb 29 08:32 AM UTC in reply to H. G. Muller from 08:19 AM:

Did you move the King to a5 through an illegal move? 

Yes, I did. To test it, I moved the king from e1 to a5. I understood that it can't work like that.


H. G. Muller wrote on Thu, Feb 29 08:19 AM UTC in reply to Gerd Degens from 07:28 AM:

I just wonder how it can be that the game ends with 'I win' when a king on a5 is captured with a move from a9.

I am not sure what exactly you tried here, in particular, what you mean by 'king'. It should not be possible to have a King on a5; it should have morphed to a Royal Pawn when it got there.

Did you move the King to a5 through an illegal move? The I.D. allows you to play illegal moves, (if these are non-captures), but these are considered part of a position setup, and would never be subjected to promotion rules. They just move a piece from one square to another. So if you play Ke1-a5, it would not morph into a Royal Pawn, and stay a King. (But due to your choice of images, you cannot see that!) As a consequence you have not lost yet, and if it can the AI would capture your King and claim the win.

If I play, from the start position, Ke1-a4, switch on the AI, and then play Ka4-a5, it does claim the win. (A bit strange here is that the King appears to promote to an enemy non-royal piece; I still have to figure out what causes that.)


H. G. Muller wrote on Thu, Feb 29 07:54 AM UTC in reply to Fergus Duniho from 03:07 AM:

@Fergus: OK, so it is what I thought. But it only contains values for pieces that are present; labels of pieces that are not on the board do not get value 0 associated. This makes it tricky to use.

What is the best way to test whether an associative array contains a given key? In JavaScript I would just copy array[key] to a variable, and then test if that variable is undefined.

But testing for an undefined value seems to be difficult in GAME code. In seems that variables to which you assign an undefined value disappear, and that #name for nonexisting variables evaluates to the string literal "#name". Is this guaranteed behavior? I.e., would it make sense to write

if != #name "#name":

to only process a variable when it does exist / was not assigned an undefined value?

Or can the problem be avoided by reading the value of the variable using var rather than #? Is there any guaranteed behavior for using var on a non-existing / undefined variable?

If not, it seems to be useful to have an operator (let's call it number) that would evaluate to the numerical value of its operand, but to zero if the operand was not numeric, or undefined. So that I could write something like number elem #key piececount, which would give me the expected 0 if #key was not a valid key in the piececount table.


Gerd Degens wrote on Thu, Feb 29 07:28 AM UTC in reply to H. G. Muller from Wed Feb 28 09:45 PM:

As should be expected, as otherwise only the last piece in the table is royal.

You are certainly right, in the piece table only the king is marked as the last in the table with 'c00'.

I just wonder how it can be that the game ends with 'I win' when a king on a5 is captured with a move from a9. Consequently, the king on a5 must have been recognized as royal. The same applies to any other square in the morph zone.
 


🕸Fergus Duniho wrote on Thu, Feb 29 03:07 AM UTC in reply to H. G. Muller from Wed Feb 28 07:30 PM:
                    case "piececount":
                        $temp = array();
                        foreach ($space as $p) {
                            if (($p != "@") && ($p != "-"))
                                $temp[$p] = isset($temp[$p]) ? $temp[$p] + 1 : 1;
                        }
                        array_push ($output,  $temp);
                        break;

H. G. Muller wrote on Wed, Feb 28 09:45 PM UTC in reply to Gerd Degens from 02:26 PM:

That seems to be the case, because the I.D. works as intended.

Not when I tried it. When I morph my King the AI claims victory. It really needs a royal=... specification. As should be expected, as otherwise only the last piece in the table is royal. When you look at the piece table and click the header of the 'move' column, the royal pieces should have '(c00)' behind their piece value, and J,L,M,O do not have that.

The suggested lines [set wroyal (K J L M O);
set broyal (k j l m o);] I have tried several times before - and just now again. The following happens: as soon as a white piece is clicked, the game stops immediately and the message 'White lost by absence of royalty!' appears.

It appears I have now solved this.

The matter with the custom set is new to me - I'll have a look at it. Many thanks in the meantime.

There is a problem here: When a Diagram is pasted in the (old) PTA, and you generate GAME code from it, piece types that are not on the board won't be mentioned in the custom set that is generated. I won't manage to fix that today. But it is not very difficult to fix it directly in the preset: just copy the suggested code, and then duplicate the line that defines the Kings 4 times, altering the K/k in these copies into J/j, L/l, M/m and O/o respectively. Then all these labels should get a King image. (Well, beware of commas. Each line should end in a comma, except the last!)


H. G. Muller wrote on Wed, Feb 28 07:30 PM UTC in reply to Gerd Degens from 03:57 PM:

@Fergus: I ran into something strange. The include file for automation with the PTA uses an identifier piececount, like it is an associative array that tells for each piece label how many there are on the board. It is used like

set nr + #nr elem #type piececount;

I cannot find a desciption of it in the GAME-code tutorial, though. Did it ever exist, and is it deprecated? Or has it been a figment of my imagination all the time? I cannot print it either; printr piececount; just prints the word 'piececount'.

The strange thing is that elem #type piececount evaluates to 1 if type has the value K or k. (Which is usually the only value it gets, as it is in a loop that has the purpose of counting the number of royals left, and K is usually the only royal type.) I would not expect that from an undefined variable, and indeed there is one King on the board. If type has the value of a piece label that is not on the board, the value does seem undefined. And apparently 1 + undefined equals 0, which is also strange. But nr ends at 0 because of this, leading to a win claim...

[Edit] For piece types that are on the board, piececount indeed appears to work as one should guess from the name. But for piece types not on the board elem #type piececount appears to evaluate to something strange, rather than 0. I now assigned it to a variable a, and print #a then produces output '#a'. Now I have seen this before for undefined variables, so I expected if not #a: set a 0; endif; to solve the problem, assuming 'undefined' would be interpreted as false. (Or is this a JavaScript expectation?) But not so; the if-statement does not trigger, and adding the undefined variable to a variable nr that already has a non-zero value appears to reset it to 0.

[Edit2] It does work as intended when I do this:

    set a elem #type piececount;
    set b 0;
    if var a:
      set b var a;
    endif;
    set nr + #nr #b;             // count them

Using #a instead of var a it just keeps interpreting that as a literal. Can this be simplified to set nr + #nr var a; ? I am afraid to try it, because I already spoiled one GC game by experimenting...


Gerd Degens wrote on Wed, Feb 28 03:57 PM UTC in reply to H. G. Muller from 01:45 PM:

@H.G.

Select a Set Group 'Custom', and then a Set 'Completely Custom' in the preset Edit page, and paste the text the PTA suggests for this section.

I have tried it, both with the old PTA (.../MSplay-test-applet-for-chess-variants) and with the new PTA (.../playtest.html). 

The result is the same in both cases and the error message appears 'Your Custom Set description failed to decode properly. Make sure it has no errors in it'. 

A very nice feature and would help a lot.


Gerd Degens wrote on Wed, Feb 28 02:26 PM UTC in reply to Gerd Degens from 02:15 PM:

So the I.D. doesn't understand these morphed Kings are royal, and as a consequence also has not passed that info to the GAME code.

That seems to be the case, because the I.D. works as intended. I.e. the morphed kings are recognized, they get new moves (pawn, archbishop, chancellor, amazon) and the game is over when they are captured. So in the I.D. everything works as expected.
 


25 comments displayed

Later Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.