You are on the main site for The Chess Variant Pages. There were some technical difficulties for a while, but things should be working now.

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
This item is a game information page
It belongs to categories: Two dimensional, Large board
It was last modified on: 2021-03-29
 By Aurelian  Florea. Grand Apothecary Chess-Classic. Very large Board variant obtained trough tinkering with known games.[All Comments] [Add Comment or Rating]
Aurelian Florea wrote on 2021-09-25 UTC

HG, Have you seen my previous comment here?

Aurelian Florea wrote on 2021-09-23 UTC


The preset (here : does not apply the shuffle algorithm as the interactive diagram does. Normally the nightrider and warlock should shuffle on the left side and then mirror in the right side and then mirror for black. Initially they were not shuffling at all.

I have added this piece of code before calling the shuffling algorithm: (Y W) // shuffleset 0 0

And now sometimes it shuffles the pieces on the same side. Meaning 2 warlock on the right and two knighriders on the left. Probably this is because I do not undersand the meaning of the 2 zeros.

Fergus Duniho wrote on 2021-09-02 UTC

the idea behind the Play-Test Applet is that it would make things as easy as riding a bicycle, where otherwise they are as complex as assembling your own car from parts, and learning how to drive it.

That's not quite correct. The alternative to using the Play-Test Applet will often just involve copying a preset that already works, writing FEN code for the board, assigning piece labels and notation to the correct pieces, and saving. As long as a game uses pieces already programmed in the fairychess include file, has a fixed setup, and mainly follows the rules of Chess, it should be easy enough to create a programmed preset for it without knowing how to program.

Aurelian Florea wrote on 2021-09-02 UTC

I had tried that already and it did not work at the time. Now I saved it twice and it works. It seems that the saving twice necessity is still present.

H. G. Muller wrote on 2021-09-02 UTC

You wrote "graphics.dir/alfaerie/ " instead of "/graphics.dir/alfaerie/ " in the preset. Therefore it complains that the string does not start with a forward slash.

Aurelian Florea wrote on 2021-09-02 UTC


At the same link before I have the absolute value to the dir like that: setsystem dir "/graphics.dir/alfaerie/";

It seems it is wrong. Where is my mistake?

H. G. Muller wrote on 2021-09-02 UTC

It is true that every tool requires some new skills for using it. But the idea behind the Play-Test Applet is that it would make things as easy as riding a bicycle, where otherwise they are as complex as assembling your own car from parts, and learning how to drive it. Perhaps we are not completely there yet; the user still has to create th Game Courier page first, and the Applet only provides the program code to paste into it. But I have been considering the idea to also make it handle preset creation: equip it with yet another button and text entry, where you then specify the variant's names, and just have to press the button for creating the GC preset page, and opening it in play mode in a new browser tab.

Jean-Louis Cazaux wrote on 2021-09-02 UTC

Thank you HG. My problem is simplest than that. For a guy like me, every new tool needs some investment to get used with. I understood that the Play-test can do wonderful things and I see others using it, but I still have to devote some time to understand how to use it. It is certainly worth to do it for me but so far I have not used it yet.

My skills are limited. Even to create a simple Game Courier, it represents an effort for me to remember how to create a page that links to a GC, call the other page which presents the rule, make a diagram and link it, etc. For you, Fergus, and other editors, it is piece of cake. For me it is quite an effort to remember the "path".

For example, I simply want to make a GC for Devingt Chess, the page I made recently (btw, can someone publish it now?). Devingt Chess is almost structured like Bear Chess, so I can make code the GC easily, but I struggle how to make the page that will present it. Aargh.

Thanks for all.

H. G. Muller wrote on 2021-09-01 UTC

I feel like being a yellow or orange belt at judo and you guys being black belt. :=)

The first thing that comes to mind on reading this is: "why then program at all, and not just let the Play-Test Applet generate the code for you?". But perhaps this is less easy than usual because many of your variants don't have a fixed initial position, but start with some piece placement (by black). This is not a standard feature of the Play-Test Applet, because the Interactive Diagram doesn't support it: the naturan way to implement it there is just let the computer shuffle the pieces randomly, accept the Diagram's choice when you want to play black against it, and prest 'Start Game' until you get the position you wanted to pick when you want to play black.

But thet means the GAME code generated by the Applet also shuffles randomly, instead of allowing black to pick the setup. Perhapssuch placement should be supported by the library routine for shuffling, in a way that is asy to activate by post-editing the automatically generated code. But I don't know what is the common way to enter the black choices in this case. Is that as a number of free drops in a single move?

H. G. Muller wrote on 2021-09-01 UTC

OK, there are three problems:

  1. The last two lines of the Pre-Game code have no semicolon at the end.
  2. The .. at the start of the string assigned to dir in the forelast line should be deleted, to make it an absolute path.
  3. The definition of the W image got totally messed up; it should be:
  W "../alfaeriemisc/compounds/wzebrawazir.gif" w "../alfaeriemisc/compounds/bzebrawazir.gif"

For this piece you made use of the % convention in the Interactive Diagram, for indicating where the white or blackPrefix should go. The script for flushing the game code does not support that convention yet, so it put the color prefixes (w or b for this set) in front of the path name as usual. I could probably automate this, but in the preset the path name has to be relative to the path assigned to $dir, and it might be difficult to deduce that from the full path name that the Diagram expects with the % convention. So I guess the best solution is to let the user, when he wants to incorporate pieces from a different folder, just post-edit the Pre-Game code generated by the Play-Test Applet for such 'guest' pieces (like W in this case).

Fergus Duniho wrote on 2021-09-01 UTC

The labels w and W are using paths that do not exist. The value for $dir should be an absolute relative path, not one whose value depends on another path value already being set. The value "/graphics.dir/alfaerie/" specifies a specific directory, but "../graphics.dir/alfaerie/" does not, or it specifies the wrong one, such as "/play/graphics.dir/alfaerie/". While "../" should not be used in $dir, it may be used in the location of a specific piece, because this will be relative to the absolute value in $dir. For example, w may be "../alfaeriemisc/compounds/%zebrawazir.gif".

H. G. Muller wrote on 2021-09-01 UTC

Does the link work in the Interactive Diagram? Can you give the link to the preset where you tried this?

Aurelian Florea wrote on 2021-09-01 UTC

It does not work. I'm using whole paths becuase I need those images. They are not in the default directory!

H. G. Muller wrote on 2021-08-31 UTC

But that is not where the Play-Test Applet would take the piece images from. Does the old Diagram Wizard use that URL as graphicsDir when you select Alfaerie? I guess I should update that anyway to use the anti-aliased set. But using relative path names (not stating with slash) is not necessary, and not recommended. Because they might not work when the pieces are used from another directory.

Try deleting the leading .. (but not the /), then it should find the piece directory from anywhere.

Aurelian Florea wrote on 2021-08-31 UTC

It seems to still be a problem given by the fact that some images are not in : "../graphics.dir/alfaerie/"

H. G. Muller wrote on 2021-08-31 UTC

I think it should. When you replace the non-alphabetic IDs by normal capitals, and also paste the GAME code it generates for defining the piece set into the Pre-Game section.

Aurelian Florea wrote on 2021-08-31 UTC

Hello HG,

So now rewriting the preset with the applet works?

Jean-Louis Cazaux wrote on 2021-08-30 UTC

Thank you Fergus. I think I've understood the idea, also for your other answer. Not sure I'll be able to handle this right now, but I will try if I need. I feel like being a yellow or orange belt at judo and you guys being black belt. :=) Thanks also for your patience.

Fergus Duniho wrote on 2021-08-30 UTC

I'm quite interested by this possibility as I understand that this is a way to get rid of the creation of new sets.

It doesn't get rid of the creation of new sets. It just changes how you make them. Instead of writing a PHP file and having it put in the /play/pbm/sets/ directory, you can create a set using the GAME Code language.

However, I'm not very skilled in coding, I mean less than you all, and I don't understand everything. Is there any example in some files?

The only example is in comment 42275 on the Developer's Guide page. But this is an example of creating five different sets that each have only the standard Chess pieces in them. If you understand how it works, then you may be able to adapt it to create a set for a specific game. However, I might need to add some details to it to handle pieces that do not match up with pieces already in the set it is loading before running GAME Code.

Instead of creating a new set from scratch, you may prefer to work with an existing set that happens to include everything you need, then use the update-piece-set subroutine to define a new set in terms of it.

H. G. Muller wrote on 2021-08-30 UTC

I now made the Play-Test Applet also generate Pre-Game code for defining a custom piece set, from the pieces that were used in the Interactive Diagram, when you press the GAME-code button to convert the Diagram to an automated preset. When a standard piece set was used (with the piece labels from the set used as piece IDs in the Diagram), there is no need to copy this to the Pre-Game section of the preset. But for non-standard sets it can be added to the mandatory Pre-Game code for defining the set.

The idea is that you should use purely alphabetic upper-case piece IDs in the Interactive Diagram that you will be converting. The newly generated GAME code then assocites these with the piece images that the Diagram was using.

This is as yet untested in a real preset. But the generated code looks like the example in the comment 42275. E.g. for a Diagram with just King and Pawns on the board I get:

set mypieces assoc
  P "wpawn.png" p "bpawn.png"
  K "wking.png" k "bking.png";
setsystem dir "/graphics.dir/alfaeriePNG35/"
setsystem pieces #mypieces

Fergus Duniho wrote on 2021-08-30 UTC

I don't understand what means "the available includes files" ?

An include file is a file containing programming code that is available for including in larger programs. The purpose behind this is to avoid rewriting code for different programs. Instead of writing each program from scratch, you can include include files to handle things that someone has already written code for. When writing GAME Code, you can use the include command to include the code in a particular include file. These are written as text files and have the .txt extension, which is the default extension for text files. But they are normally included without including the extension in the file name. The include files I have written are all in the /play/pbm/includes/ directory. To include one with the include command, just give its base name, which is the part before the .txt extension. H. G. Muller has written some include files in a different location, and these, I believe, are included by giving its full path and file name.

Jean-Louis Cazaux wrote on 2021-08-30 UTC

@Greg Strong What is this list of files.txt, do they have something special ? I don't understand what means "the available includes files" ?

Sorry, I'm lost.

Jean-Louis Cazaux wrote on 2021-08-30 UTC

I'm quite interested by this possibility as I understand that this is a way to get rid of the creation of new sets. However, I'm not very skilled in coding, I mean less than you all, and I don't understand everything. Is there any example in some files?

Fergus Duniho wrote on 2021-08-29 UTC

Where can I find this include file?

It's in the includes directory. So, you just include it by name.

BTW, I did stumble on the method for defining a piece set through assigning to $pieces. Perhaps this is the best method to convert Interactive Diagrams to GAME code, as these Diagrams do specify the filenames of the piece images, the directory where these images are to be found, and the piece IDs (which can be used as labels). So it would just be a matter of dumping this internally held info in the form of a GAME-code associative array, in the code generated for the Pre-Game section.

Yes, that could work, though there is one caveat. When Game Courier is in Edit mode, it does not run any code unless someone clicks Run. This is a safety precaution to allow someone to edit buggy code that would otherwise disable the preset. Consequently, the board may not look right in Edit mode until someone clicks Run. If you use a set file in conjunction with the update-piece-set subroutine, though, it will avoid that problem. However, there could be a discrepancy between the labels used for the FEN code and the notation used in the preset.

To avoid that discrepancy, I was thinking of letting custom piece sets be stored as constants. However, constants are stored in logs, not in settings files. So, I'm not sure I have a good solution for this yet.

25 comments displayed

Later Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.