The site has moved to a new server, and there are now some issues to fix. Please report anything needing fixing with a comment to the homepage.



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
About Game Courier. Web-based system for playing many different variants by email or in real-time.[All Comments] [Add Comment or Rating]
Fergus Duniho wrote on 2023-01-12 UTC

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


Daniel Zacharias wrote on 2023-01-12 UTC

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.


Fergus Duniho wrote on 2023-01-04 UTC

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.

Daniel Zacharias wrote on 2023-01-04 UTC

It appears to be fixed now


Fergus Duniho wrote on 2023-01-04 UTC

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


Daniel Zacharias wrote on 2023-01-04 UTC

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


Fergus Duniho wrote on 2023-01-04 UTC

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.


Fergus Duniho wrote on 2023-01-04 UTC

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.


Daniel Zacharias wrote on 2023-01-04 UTC

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.


Fergus Duniho wrote on 2023-01-04 UTC

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.


Daniel Zacharias wrote on 2023-01-04 UTC

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.


Fergus Duniho wrote on 2023-01-04 UTC

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?


Daniel Zacharias wrote on 2023-01-03 UTC

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.


H. G. Muller wrote on 2023-01-01 UTC

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.


Daniel Zacharias wrote on 2023-01-01 UTC

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?


Fergus Duniho wrote on 2023-01-01 UTC

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.


Daniel Zacharias wrote on 2023-01-01 UTC

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;

Fergus Duniho wrote on 2022-12-31 UTC

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.]


Daniel Zacharias wrote on 2022-12-31 UTC

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


Fergus Duniho wrote on 2022-12-29 UTC

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.


Daniel Zacharias wrote on 2022-12-29 UTC

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.


Fergus Duniho wrote on 2022-11-26 UTC

Please give me links to specific logs.


Jenard Cabilao wrote on 2022-11-26 UTC

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.


Fergus Duniho wrote on 2022-11-08 UTC

For games using a Rank label of 0, the 0 rank is not displayed and any pieces starting there are shown as captured.

That's now fixed.


25 comments displayed

Later Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.