Comments/Ratings for a Single Item

A lot of the logs of some games return error messages:

For Ultima it says that a certain line contains a syntax error, e.g. Syntax Error on line 585

For shogi it says that a given move was done illegally, e.g.:

ILLEGAL: g 4i-5h on turn 6:

The move MOVE: g 4i-5h ain't well-formed. g is a coordinate. So 4i should be a hyphen.

There may be others I haven't noticed.

Please give me links to specific logs.

This is a small sample, if I did everything I'd be spending all day:

https://www.chessvariants.com/play/pbm/play.php?game=Shogi&log=dax00-cvgameroom-2020-304-184 https://www.chessvariants.com/play/pbm/play.php?game=Shogi&log=per31-cvgameroom-2019-145-205 https://www.chessvariants.com/play/pbm/play.php?game=Shogi&log=niccar-krinid-2004-167-366

https://www.chessvariants.com/play/pbm/play.php?game=Ultima&log=hambledon-sdc.stats-2008-361-709 https://www.chessvariants.com/play/pbm/play.php?game=Ultima&log=tamandua-cvgameroom-2015-24-775 https://www.chessvariants.com/play/pbm/play.php?game=Ultima&log=sissa-tamandua-2013-90-201

https://www.chessvariants.com/play/pbm/play.php?game=Skica&log=sissa-arx-2022-289-168

In this game I'm seeing the piece images change after I make a move and before I confirm the move. That makes it awkward verifying that the move I made is what I really want to do.

Okay, I fixed that. There was a namespace conflict with a new feature I added just a moment before you posted your bug report. I've now changed it to not conflict.

Okay, I fixed that. There was a namespace conflict with a new feature I added just a moment before you posted your bug report. I've now changed it to not conflict.

That didn't fix it. It looks like the image shown in the confirmation page is ignoring the changes made to piece labels and images in the pre-game code. I'm seeing the same problem in some other games too, such as this one.

https://www.chessvariants.com/play/pbm/play.php?game=Maasai+Chess&log=arx-cvgameroom-2022-323-205

When you made your last bug report, I did see a huge problem that I immediately fixed, and that problem is indeed gone now. But I now see that you were describing a different problem. Pieces identified as s/S change from the Chinese Pawn image to the Promoted Rook image. Checking the set, I see that s/S is assigned to the Promoted Rook image, though judging by the number of them, they should not be Promoted Rooks in this game. In the code, these lines are used to assign the Chinese Pawn image to s/S:

if == pieceset alfaerie-metamachy:
  set mypieces.s pieceimg cp;
  set mypieces.S pieceimg CP;
endif;

When I use the PNG or CSS rendering methods, the s/S pieces continue to use the Chinese Pawn image. But when I use the Table rendering method, they change to the Promoted Rook image. The problem may be that pieceset does not return the value of the variable, making the behavior of the conditional iffy. This should work instead:

if == $pieceset alfaerie-metamachy:
  set mypieces.s pieceimg cp;
  set mypieces.S pieceimg CP;
endif;

[Edit: pieceset is a function, not a variable. So, $pieceset should not be used.]

The same problem is happening in presets that don't check the value of pieceset. The Skica preset I mentioned at first has this

set mypieces assoc
  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"
  C "wcamel.png" c "bcamel.png"
  W "wwildebeest.png" w "bwildebeest.png"
  I "wbishopinv.png" i "bbishopinv.png"
  U "wqueeninv.png" u "bqueeninv.png"
  S "wrookinv.png" s "brookinv.png";
setsystem dir "/graphics.dir/alfaeriePNG/";
setsystem pieces #mypieces;

This is another example of reverting to the piece image originally assigned in the set file.

I do not see what could be causing the problem this time, and since this is an automatically-generated preset, it is beyond my usual expertise.

One thing I will note is that I no longer recommend editing the $pieces array. This is a bad practice, and I regret coming up with the idea. I now recommend the use of aliases as best practice.

I've mainly seen this in generated presets, but it doesn't look like it's doing anything very obscure so I thought it was worth asking anyway. Now I have a question about the use of aliases. Does aliasing only allow using images from the currently selected piece set?

One thing I will note is that I no longer recommend editing the $pieces array. This is a bad practice, and I regret coming up with the idea. I now recommend the use of aliases as best practice.

IIRC the possibility of the $pieces array was created because users wanted to combine piece images from different 'sets' (perhaps even standard sets supplemented by images uploaded by themselves to the /membergraphics/ sub-tree). Aliases don't do that for you; they just allow you to rename the pieces in a given set.

It is indeed inconvenient that expanding a set is done by execution of Pre-Game code. But the alternative, asking an editor to create a new set including the desired extension graphics was even more inconvenient.

It would be good if there was a way to assign arbitrary images (i.e. anywhere in the public_html subtree) to to piece labels without invoking GAME code. Just like you can specify a FEN for a preset, and the corresponding position will already be displayed on the preset's page even before you start running the preset.

This same problem is also in this preset, using this code:

set mypieces ();
set mypieces.k $pieces.k;
set mypieces.K $pieces.K;
set mypieces.q $pieces.q;
set mypieces.Q $pieces.Q;
set mypieces.r $pieces.r;
set mypieces.R $pieces.R;
set mypieces.b $pieces.b;
set mypieces.B $pieces.B;
set mypieces.n $pieces.n;
set mypieces.N $pieces.N;
set mypieces.p $pieces.p;
set mypieces.P $pieces.P;
if == pieceset alfaerie-allsvg:
  set mypieces.A pieceimg .W;
  set mypieces.a pieceimg .w;
  set mypieces.G pieceimg .P;
  set mypieces.g pieceimg .p;
  set mypieces.T $pieces.T;
  set mypieces.t $pieces.t;
  set mypieces.S $pieces.GG;
  set mypieces.s $pieces.gg;
  set mypieces.U $pieces.U;
  set mypieces.u $pieces.u;
  set mypieces.D pieceimg .D;
  set mypieces.d pieceimg .d;
endif;
setsystem pieces #mypieces;

I tried changing pieceset to $pieceset, but that just caused the pieces defined in the if condition to be replaced with black circles.

Okay, pieceset is a function, not a variable. So, ignore my advice to use $pieceset.

I have not been able to reproduce the problem in this game. Can you set up an example for me to look at?

It doesn't happen when I use the Play button, but when I use Move and try to move pieces the images change. Also, in this ongoing game I see it after each move, but before I move it all looks ok.

It's happening with A, S, G, and D. These are the four that are assigned to images that originally had different piece labels. Curiously, when I have it display a list of the pieces, it shows this, which I believe is correct, yet it still shows the wrong pieces.

Array
(
    [k] => bking.png
    [K] => wking.png
    [q] => bqueen.png
    [Q] => wqueen.png
    [r] => brook.png
    [R] => wrook.png
    [b] => bbishop.png
    [B] => wbishop.png
    [n] => bknight.png
    [N] => wknight.png
    [p] => bpawn.png
    [P] => wpawn.png
    [A] => wmage.png
    [a] => bmage.png
    [G] => wpegasus.png
    [g] => bpegasus.png
    [T] => wtiger.png
    [t] => btiger.png
    [S] => wslidinggeneral.png
    [s] => bslidinggeneral.png
    [U] => wunicorn.png
    [u] => bunicorn.png
    [D] => wdragon.png
    [d] => bdragon.png
)

But when I assign pieceset to a variable and have it say it, it gives me an empty string. However, it appears that the value of pieceset is not the problem. Despite having the correct images in $pieces, it is displaying the original images from the set.

I'm not sure what is going on. However, switching to the use of aliases should fix this. Using aliases will not change the labels used to display pieces. With aliases, there is a strict separation between your labels and your notation, and you should always see the correct images. The main catch is that you have to make sure all your functions, subroutines and other code properly handle aliases. The fairychess include file, which this preset is using, does properly handle aliases, and you just have to make sure that any additional code also handles aliases. Check the tutorial for this include file for more information.

I'm not sure what is going on. However, switching to the use of aliases should fix this.

Yeah, I can do that. I just wish it weren't necessary since it means modifying every preset that uses this method, which was working perfectly until just recently. It seems to only happen with HTML Table rendering, so it could be circumvented by settings affected presets to use a different method by default. That still means modifying a lot of broken presets to fix this.

Here is what was going on. I recently added the feature to recolor pieces across all rendering methods. For tables, it recolors pieces by linking the IMG tag to the showpiece.php script instead of directly to the image file, and it identifies a piece by its set and label. Although you were not recoloring your pieces, the color name began with a # sign for one variable but not for a variable it was being compared with. So, even though the colors were the same, the == comparison indicated that they were different, and it linked to the showpiece.php script instead of to the image. For the sake of more accurate color comparisons, I wrote a new function called samecolor, which puts each color string into a uniform format before comparing them. Using this function, the color of your pieces matched the original color, and the link used the image instead of the showpiece.php script.

I have now added some new parameters to showpiece.php. The image parameter is for the relative path to a file, and the originalcolor parameter is for the original color of a piece. With these, a piece can be specified and recolored without providing the set and piece label, and I have modified draw_square_table.php to use these new parameters when using showpiece.php.

Now the images are reverted still, but all the pieces also have black backgrounds

Okay, there was another section of code to update. How does it look now?

It appears to be fixed now

Here are a few things to keep in mind about reassigning the value of $pieces.

1. This does not give players the option of choosing different sets unless you explicitly build this in.
2. When you use the pc shortcode to display piece images in the description, they may not always be accurate. However, if you are providing only one set, you can get away with direct links to the piece images.
3. When you go to the Related menu and select Diagram Designer, it will usually display your diagram with the wrong images.

Now the default presets for Glinksi's and McCooey's Hexagonal Chesses are broken. Neither one shows any legal moves.

Separately, this preset just shows the board but the rest of the game interface is missing.

The problems with Hexagonal Chess and Napoleonic Chess are now fixed.