The Chess Variant Pages




[ 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
Home page of The Chess Variant Pages. Homepage of The Chess Variant Pages.[All Comments] [Add Comment or Rating]
Máté Csarmasz wrote on 2022-05-13 UTC

Hello, Is there a way to verify my email address? csarmi


Fergus Duniho wrote on 2022-02-07 UTC

Isn't it possible to do some syntax checking on the GAME code (e.g. when it gets submitted) to prevent such erratic behavior?

I have added some error messages to make it easier to spot this kind of error in the future. See comment 43913 on the Game Courier History page.


H. G. Muller wrote on 2022-02-07 UTC

Initially I did not implement it because the Play-Test Applet is not suitable for specifying a variant with Shogi promotion: the order of the piece definitions is critical in that case, while the Applet inherits the order from the table of available pieces, without any interface for re-ordering them. But now that Diagram specifications can be pasted back into the Applet, this has changed. I guess I should make the textbox in which the HTML for the Diagram appears when you press the button editable. Then users could re-order the piece definitions there, and paste it back. Or perhaps there should even be a button for reloading what is in that textbox.


Daniel Zacharias wrote on 2022-02-07 UTC

@H.G.Muller

Yeah, I couldn't think of an easier way to do it. It would make sense to have that supported more directly; especially since the interactive diagram can do that already.


Fergus Duniho wrote on 2022-02-07 UTC

Are these the correct instructions at the end of the presets?

setsystem pieces #mypieces; setsystem flipped #mypieces;

Since the first one worked, the second should too. I think using var instead of the # prefix would be a bit quicker for an array, but it is probably negligible.


Aurelian Florea wrote on 2022-02-07 UTC

@Fergus

Are these the correct instructions at the end of the presets?

setsystem pieces #mypieces; setsystem flipped #mypieces;


H. G. Muller wrote on 2022-02-07 UTC

It sounds like something in your code is producing an unwanted goto to the beginning of the program when the E piece is moved.

That is totally unexpected behavior, and makes it virtually impossile to figure out what the error is. Isn't it possible to do some syntax checking on the GAME code (e.g. when it gest submitted) to prevent such erratic behavior?

@Daniel: You redefined the Promote routine just to implement Shogi-style promotion? Perhaps the betza.txt include should already provide a standard way to do that. E.g. triggered by the presence of an associative array #shogiprom, which would provide the promoted type when indexed with the basic type, and then set #choice to an array containing that promoted type and the piece itself. This could still be intersected with the possible choices for each rank (e.g. to suppress deferral for Pawns on the last rank, or Shogi Knights on the last two ranks). But it could probably bypass intersection with the captured pieces plus supply, as promotion to captured pieces only seem to make no sense with Shogi promotions.

 


Aurelian Florea wrote on 2022-02-07 UTC

@HG

I have done what you have said and now things work properly. Thank you!


Aurelian Florea wrote on 2022-02-07 UTC

You need to set $flipped to the same value as $pieces, because Alfaerie:Many includes some flipped pieces, but your game does not.

I don't see the error you see. To me the preset works fine. I see the error though in edit mode.

Daniel Zacharias wrote on 2022-02-06 UTC

It looks like that missing colon was the problem. That was my fault


Fergus Duniho wrote on 2022-02-06 UTC

It sounds like something in your code is producing an unwanted goto to the beginning of the program when the E piece is moved.

This bit of code in the pregame section might be the problem:

        case I E 
          set choice intersection #choice (O #piece);
          break;

Notice that there is no colon after the E in the case statement.


H. G. Muller wrote on 2022-02-06 UTC

You are right, moving E appears to trigger the problem. Which is strange, because all pieces use the same code for generating their moves; it is just that the data stored for describing E and e is in a different section of the array with move descriptions. Functions E and e are supposed to tell where exactly. Perhaps something disastrous happens in GAME code when using functions called E or e?

The shorter game causes the same problem: I put print statements at the start of the Pre-Game and Post-Move sections to see when they are called, and a printr $space; at the end of the Pre-Game section. This shows the same behavior also for the short game: Game Courier attempts to play the game twice for deducing the current position, but when it plays it the second time the Pre-Game section doesn't seem to be executed properly, because it sticks with the position resulting from applying the moves the first time instead of producing the initial position. So that the the fist halfmove cannot be applied to it the second time, and aborts the loading with an error message (see below).

I think the key to this is still understanding why Game Courier goes through the movelist twice. I see no need for it to do that.



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

pregame

Array
(
    [a12] => d
    [b12] => l
    [c12] => u
    [d12] => z
    [e12] => o
    [f12] => q
    [g12] => k
    [h12] => o
    [i12] => z
    [j12] => u
    [k12] => l
    [l12] => d
    [a11] => r
    [b11] => m
    [c11] => n
    [d11] => b
    [e11] => a
    [f11] => y
    [g11] => y
    [h11] => a
    [i11] => b
    [j11] => n
    [k11] => m
    [l11] => r
    [a10] => x
    [b10] => i
    [c10] => e
    [d10] => g
    [e10] => s
    [f10] => c
    [g10] => c
    [h10] => s
    [i10] => g
    [j10] => e
    [k10] => i
    [l10] => x
    [a9] => p
    [b9] => p
    [c9] => p
    [d9] => p
    [e9] => p
    [f9] => p
    [g9] => p
    [h9] => p
    [i9] => p
    [j9] => p
    [k9] => p
    [l9] => p
    [a8] => @
    [b8] => @
    [c8] => @
    [d8] => @
    [e8] => @
    [f8] => @
    [g8] => @
    [h8] => @
    [i8] => @
    [j8] => @
    [k8] => @
    [l8] => @
    [a7] => @
    [b7] => @
    [c7] => @
    [d7] => @
    [e7] => @
    [f7] => @
    [g7] => @
    [h7] => @
    [i7] => @
    [j7] => @
    [k7] => @
    [l7] => @
    [a6] => @
    [b6] => @
    [c6] => @
    [d6] => @
    [e6] => @
    [f6] => @
    [g6] => @
    [h6] => @
    [i6] => @
    [j6] => @
    [k6] => @
    [l6] => @
    [a5] => @
    [b5] => @
    [c5] => @
    [d5] => @
    [e5] => @
    [f5] => @
    [g5] => @
    [h5] => @
    [i5] => @
    [j5] => @
    [k5] => @
    [l5] => @
    [a4] => P
    [b4] => P
    [c4] => P
    [d4] => P
    [e4] => P
    [f4] => P
    [g4] => P
    [h4] => P
    [i4] => P
    [j4] => P
    [k4] => P
    [l4] => P
    [a3] => X
    [b3] => I
    [c3] => E
    [d3] => G
    [e3] => S
    [f3] => C
    [g3] => C
    [h3] => S
    [i3] => G
    [j3] => E
    [k3] => I
    [l3] => X
    [a2] => R
    [b2] => M
    [c2] => N
    [d2] => B
    [e2] => A
    [f2] => Y
    [g2] => Y
    [h2] => A
    [i2] => B
    [j2] => N
    [k2] => M
    [l2] => R
    [a1] => D
    [b1] => L
    [c1] => U
    [d1] => Z
    [e1] => O
    [f1] => Q
    [g1] => K
    [h1] => O
    [i1] => Z
    [j1] => U
    [k1] => L
    [l1] => D
)

postmove1

postmove2

postmove1

pregame

Array
(
    [a12] => d
    [b12] => l
    [c12] => u
    [d12] => z
    [e12] => o
    [f12] => q
    [g12] => k
    [h12] => o
    [i12] => z
    [j12] => u
    [k12] => l
    [l12] => d
    [a11] => r
    [b11] => m
    [c11] => n
    [d11] => b
    [e11] => a
    [f11] => y
    [g11] => y
    [h11] => a
    [i11] => b
    [j11] => n
    [k11] => m
    [l11] => r
    [a10] => x
    [b10] => i
    [c10] => e
    [d10] => g
    [e10] => s
    [f10] => c
    [g10] => c
    [h10] => s
    [i10] => g
    [j10] => e
    [k10] => i
    [l10] => x
    [a9] => p
    [b9] => p
    [c9] => p
    [d9] => @
    [e9] => p
    [f9] => p
    [g9] => p
    [h9] => p
    [i9] => p
    [j9] => p
    [k9] => p
    [l9] => p
    [a8] => @
    [b8] => @
    [c8] => @
    [d8] => p
    [e8] => @
    [f8] => @
    [g8] => @
    [h8] => @
    [i8] => @
    [j8] => @
    [k8] => @
    [l8] => @
    [a7] => @
    [b7] => @
    [c7] => @
    [d7] => @
    [e7] => @
    [f7] => @
    [g7] => @
    [h7] => @
    [i7] => @
    [j7] => @
    [k7] => @
    [l7] => @
    [a6] => @
    [b6] => @
    [c6] => @
    [d6] => @
    [e6] => @
    [f6] => @
    [g6] => @
    [h6] => @
    [i6] => @
    [j6] => @
    [k6] => @
    [l6] => @
    [a5] => @
    [b5] => @
    [c5] => @
    [d5] => @
    [e5] => @
    [f5] => @
    [g5] => @
    [h5] => @
    [i5] => P
    [j5] => @
    [k5] => @
    [l5] => @
    [a4] => P
    [b4] => P
    [c4] => P
    [d4] => P
    [e4] => P
    [f4] => P
    [g4] => P
    [h4] => P
    [i4] => E
    [j4] => P
    [k4] => P
    [l4] => P
    [a3] => X
    [b3] => I
    [c3] => E
    [d3] => G
    [e3] => S
    [f3] => C
    [g3] => C
    [h3] => S
    [i3] => G
    [j3] => E
    [k3] => I
    [l3] => X
    [a2] => R
    [b2] => M
    [c2] => N
    [d2] => B
    [e2] => A
    [f2] => Y
    [g2] => Y
    [h2] => A
    [i2] => B
    [j2] => N
    [k2] => M
    [l2] => R
    [a1] => D
    [b1] => L
    [c1] => U
    [d1] => Z
    [e1] => O
    [f1] => Q
    [g1] => K
    [h1] => O
    [i1] => Z
    [j1] => U
    [k1] => L
    [l1] => D
)

postmove1

ILLEGAL: P i4-i5 on turn 1:

There was no P on i4. The piece on i4 is a E.

Go back with your browser's BACK button, reload the page, and try again.

For diagnostic purposes, here is the full movelist:

1. P i4-i5 
1... p d9-d8 
2. E j3-i4

Fergus Duniho wrote on 2022-02-06 UTC

In a short game in which I was moving Pawns out of the way to move the E piece, I tried each E piece, and it gave the error "g4 is empty" each time. Since g4 was in fact empty, I did a quicker game in which I just moved Pawns near the E and e piece before moving the E piece. This gave the error:

ILLEGAL: P i4-i5 on turn 1:

There was no P on i4. The piece on i4 is a E.

Go back with your browser's BACK button, reload the page, and try again.

For diagnostic purposes, here is the full movelist:

1. P i4-i5 
1... p i9-i8 
2. E j3-i4

I then took back the last move, cleared a space for the other E piece to move, moved an e piece, then moved the other E piece. This time, I got the error "i4 is empty".

So, it's looking like there is something wrong with the E piece.


H. G. Muller wrote on 2022-02-06 UTC

I tried to debug it some time ago, and the error message was provoked by the first halfmove of the game being applied to the position resembling the one that occurs after all moves have already been applied once. So the question is: why would Game Courier try to apply the set of moves twice? And, as I said, it also appears to execute the Pre-Game code twice. (But not fully, otherwise the first loading of the game would be fully erased, and undetectable.) I had the impression it was due to the previous move being a check, but this could be a coincidence.


Fergus Duniho wrote on 2022-02-06 UTC

When I entered that sequence of moves all at once, I got the same error. Then I entered each move separately and still got the same error. So, I took back the last move and found another legal move, which worked out. A little later, I tested other moves by the E and e pieces, and when I moved the other E piece, though not an e piece, I got the same error. Taking back that move and trying E again later, I got the error "g4 is empty". There seems to be something wrong with the E piece, but I am too unfamiliar with the workings of this generated code to debug it.


Daniel Zacharias wrote on 2022-02-06 UTC

There was this error.

ILLEGAL: P g4-g6 on turn 1:

There was no P on g4. The piece on g4 is a Z.

Go back with your browser's BACK button, reload the page, and try again.

For diagnostic purposes, here is the full movelist:

1. P g4-g6 
1... p g9-g7 
2. Z i1-g4 
2... a e11-i7 
3. P f4-f5 
3... a i7-d2; q-dest 
4. A h2-e5 
4... q d2-i7 
5. P c4-c6 
5... q i7-i3 // - check! -
6. E j3-i3

Fergus Duniho wrote on 2022-02-06 UTC

What was that problem, specifically? What doesn't work?


Daniel Zacharias wrote on 2022-02-06 UTC

There was another problem with the same game. I know it's not related to the piece image thing because I just tried it again and it still doesn't work.


Fergus Duniho wrote on 2022-02-06 UTC

@Fergus: please also have a look at the problem reported here.

Do you mean the problem reported by Daniel Zacharias, which I just gave the solution to? Or were you describing an independent problem? If so, I would need a link.


H. G. Muller wrote on 2022-02-06 UTC

The array shufflespecs needs an extra 0 at the end (in addition to the triples describing the individual shuffle steps) to symmetrize the position, and the preset's Pre-Game code doesn't seem to have that. If this is code generated through the Play-Test Applet it could be that it got confused about the symmetry of the diagram. When symmetry=none it would shuffle white and black independently.

@Fergus: please also have a look at the problem reported here. I really think there must be something wrong other than the GAME-code, because when I put a printr $spaces; at the end of the Pre-Game section it prints the array twice. I don't think that should ever be possible, no matter how buggy the GAME code might be, if the underlying software functions properly.


Fergus Duniho wrote on 2022-02-06 UTC

These 3 presets work fine but the shuffling algorithm produces different initial setups for white and black.

I'm testing with this clone:

https://www.chessvariants.com/play/pbm/play.php?game=Grand+Apothecary+Chess+1&settings=Applet-Test

I see that Black and White have different opening positions. Is that what you mean?

If you want them to be the same, then you need to create a random opening position for only one side and copy it to the other side. This might be an issue for H. G. to deal with, as the buggy code might be his.


Fergus Duniho wrote on 2022-02-06 UTC

It will be easier to look into this if you first fix the display of pieces on Black's turn. You need to set $flipped to the same value as $pieces, because Alfaerie:Many includes some flipped pieces, but your game does not.


Fergus Duniho wrote on 2022-02-06 UTC

I introduced a general problem last night regarding the parsing of $_POST values, and I have now fixed it.


Aurelian Florea wrote on 2022-02-06 UTC

It seems to me that there is something that does not work. I cannot mve in my games here:https://www.chessvariants.com/play/pbm/play.php?game=Chu+Shogi&log=dax00-cvgameroom-2022-20-382&userid=catugo and here: https://www.chessvariants.com/play/pbm/play.php?game=Maces%2C+Shields%2C+and+Horse-apults&log=arx-catugo-2022-22-073&userid=catugo .

Also when I access my presets they reverse to the default regular chess.


25 comments displayed

Later Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.