Comments/Ratings for a Single Item

@Aurelian: I haven't had time to visit CVP since it came back on line. I will have a look at the shuffling problem you mentioned.

@Jean-Louis: there is an explanation of y and a here. Indeed a means 'again', and y can be used only in combinaton with it, where ya then means 'again with range toggle', i.e. when the move started as a leaper (as is the case with F) the next leg will move as a rider of the same stride. fs means 'forward sideways', but the convention is that this should be interpreted in an orientation where the previous leg defines the forward direction (think of the controversy for the move of the Grant Acedrex Unicorn!). So fs deflects the path by 45 degrees, pure s would deflect by 90 degrees, bs would deflect by 135 degrees. So the ya would turn the F into B (range toggle), but a 45-degree rotated B is an R. So yafsF is an F step followed by an outward R. Without the y (i.e. afsF) there would be no range toggle, and the second leg would be an outward W step. Which would give you a Moa.

Apparently I forgot to add the link to the XBetza page in my previous comment; I've now added it there.

yafsF is indeed the sliding part. a is as you've found, ‘again’; fs for w's and F's is interpreted as for a king, so for an F it changes to a W direction — and ‘forward’ for anything but the first part of the move is interpreted as ‘outward’ (like Alfonso about the rhinoceros); y is a ‘range toggle’ i.e. it switches from being a leaper/stepper to being a slider. Thus, yafsF is one step diagonally followed by a 45° turn and sliding orthogonally.

Complexity is in the eye of the beholder. It's not immediately obvious (especially compared to t[FR]) but it's apperntly easier to describe to a computer (and easier to generalise), which for the interactive diagrams is a definite plus

The extended betza notation is explained here. The "fs" is understood as specifying a direction relative to the initial step, so it indicates that the gryphon moves, after the first step, forward and sideways relative to the direction it first moves. It is a more complex notation, but it allows for more possibilities.

I notice here that the knight's move in the rules is different from that in the interactive diagram. Which one is correct?

I have difficulties to see FyafsF. OK for the 1st F, then yafsF is therefore describing the "rook" sliding part of the move? I understand "fs" in the case of a N. In the case of a F, I don't see what "fs" mean.

And this can really code when the Gryphon is sliding backward?

Finally, I don't know what the modifiers y and a are. I don't see the explanation on our page on CVP. I see on WP, I understand "a" as again, but it is quite difficult what "y" means.

All this is really too complex

The dragon is indeed a t[FR], in Betza's original notation. However, that part of it was never documented on the Betza Notation page (instead languishing on the Chess on a Really Big Board page, though it turns up elsewhere too), and is arguably a little underspecified, so H. G.'s XBetza (which is what the interactive diagram uses) specifies such multi‐leg moves in its own way. In this extension, FyafsF is indeed equivalent to the original t[FR]

The vulture afaict is mainly a longer‐range relative of George Duke's (and more recently Uli Schwekendiek's) Falcon, whose advantage over the bison (from a game design perspective) is its blockability — presumably the same is sought here. Unfortunately, due to the multiple paths to a given destination, it is quite complex to describe. Idk about the extra knight move though, that's perhaps a little gratuitous (presumably to make up for the basic vutlre's lack of maneuverability?)

I agree the birds are quite complex, if potentially interesting to play with? And whether the knight/elephant enhancements are truly necessary may be worth a playtest as well

May I ask few questions:

• why is the board checkered with 4 colors instead of 2?

• is the Betza's notation for the Dragon correct? According to the textual description I would say t[FR] and not FyafsF. (I understood the Dragon is a Murray's Gryphon)

• Why is the Vulture so complex? Why not a mere compound jumper Giraffe + Zebra?

It is a matter of taste of course, but to my taste I wonder why making more complex several piece which are basically simple such as Knight (N is not enough?), Elephant (FA not enough?). Thurderbird and Firebird are very complex. I would like to play this game but with simpler rules.

HG, Are you here?

HG, If you are here please check my previous comments on this post!

@HG, In the context of my before the previous example I think the ":" symbol does not influence the preset although it works fine in the interactive diagram!

HG, Have you seen my previous comment here?

HG,

The preset (here : https://www.chessvariants.com/play/pbm/play.php?game%3DGrand+Apothecary+Chess+1%26settings%3DApplet) 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.

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.

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.

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.

HG,

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?

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.

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.

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?

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

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

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

This is the one!

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

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

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.