Comments/Ratings for a Single Item

Both sentences are true.

Thanks Kevin for mentioning as I forgot :(!

@ Fergus:

Another bug with this preset seems to have surfaced. I tried having a Black pawn at d4 early on in a hypothetical 'game' in Move Mode, and moved a White pawn to e5 (i.e. with an initial step of 3 squares). At that point the preset does not show Black being allowed to capture en passant (i.e. to move the pawn on d4 to e3).

I was working on a possibly unrelated preset of my own ('enforced' 12x12 'Brawl Chess', a game which allows a similar initial triple pawn step), and I have used the include chess2 file, and have had a similar possible 'bug'. Your Omega Chess preset currently uses the include chess file, which is why I checked the Omega Chess preset, to see if it had a similar issue.

It's possible both include files, in allowing fps (initial pawn step indicator) to be set to 3 (instead of 2), do not take into account Omega Chess' en passant pawn rules as fully as they might.

@ Fergus:

This relates only to my previous post (re: your Omega Chess preset) in that besides the en passant issue with triple stepping pawns I mentioned, I am having trouble with castling enforcement, in my 12x12 Brawl Chess rules enforced preset, too. In Brawl Chess a K castles by it moving 3 steps sideways left or right, and the settings file/preset linked to below gives me an error message when I try to castle in the Move Mode (using the include capablanca file gets an immediately fatal error for me, if I do so instead of using chess2 include file).

Not sure if I'm omitting to do something short and simple, or if I need to add a whole bunch of code, if that will work either (it may be preferable to use the Play-Test Applet for me to generate rules enforcement sooner or later, instead, except RNF and BNW piece types are not in the Applet's piece-table currently, and I'm not sure there are 2 suitable substitute figurines available that are currently in the table, if I were to add Betza code to use them, within any interactive diagram I may make). The Brawl Chess enforced preset uses the Sac Chess piece set that is also used for Jean-Louis' Very Heavy Chess invention's preset that I modified:

https://www.chessvariants.com/play/pbm/play.php?game=Brawl+Chess&settings=enforced

Note that if you want to use the PTA to generate GAME code and custom piece set for a preset, you have the opportunity to still alter the suggested code after pasting it into the preset. In particular, when you want to use piece images that were not available in the PTA's table, you can pick some other image for them, and then change the filename of those in the custom set to that of the images you do want. You are not even obliged to use the custom set that is suggested by the PTA; it is just an optional service. If a piece set exists that has all pieces you need, you can simply use that in the preset, and you don't have to copy anything to the custom-set area. But you must make sure in that case that the pieces you did use in the PTA for generating the GAME code have the same ID as those in the selected piece set. This should not be a problem, as the PTA allows you to alter ID as well as move of the pieces.

Another bug with this preset seems to have surfaced. I tried having a Black pawn at d4 early on in a hypothetical 'game' in Move Mode, and moved a White pawn to e5 (i.e. with an initial step of 3 squares). At that point the preset does not show Black being allowed to capture en passant (i.e. to move the pawn on d4 to e3).

It did for me. But when the Pawn was on e3, and I moved another White Pawn to f4, it would not show me that the en passant capture was legal even though it did accept it as a legal move when I tried it.

I have noticed an issue with the board. It is showing the correct board for Black, but not for White. For White, the rank and file markings on the board are rotated 180 degrees to the actual coordinates. I am going to look into this first.

I have noticed an issue with the board. It is showing the correct board for Black, but not for White. For White, the rank and file markings on the board are rotated 180 degrees to the actual coordinates.

That's now fixed. The problem was local to the Omega Chess board, because I had switched the key and value for the two Omega Chess boards in $imagepairs2.

I may not have the right understanding of en passant in Omega Chess, but I think a Black pawn on e3 should not be able to capture en passant (that is move to f2) after White takes a double step from f2 to f4. En passant for a double step does not work like that in chess after a double step there, and I looked at the Pawn Rules diagrams for Omega Chess' rules page, and nothing exactly like that type of attempted en passant capture is shown there either.

In my 12x12 Brawl Chess, I am allowed to make the analogue of taking a pawn moving by triple step to e5 with a Black pawn on d4 (it is not shown as legal, but it is allowed by the preset). But when I try capturing a pawn making a double step to f4 with a Black pawn on e3, the preset not only does not show the option, but also does not allow it. However, my current enforced version of Brawl Chess may be lacking some sort of code that the current enforced Omega Chess preset has.

Another bug with this preset seems to have surfaced. I tried having a Black pawn at d4 early on in a hypothetical 'game' in Move Mode, and moved a White pawn to e5 (i.e. with an initial step of 3 squares). At that point the preset does not show Black being allowed to capture en passant (i.e. to move the pawn on d4 to e3).

I have fixed this by writing a new preset that uses the fairychess include file.

I was working on a possibly unrelated preset of my own ('enforced' 12x12 'Brawl Chess', a game which allows a similar initial triple pawn step), and I have used the include chess2 file, and have had a similar possible 'bug'.

The chess2 include file is out-of-date and unsupported. You should not use it for new games. Use the fairychess include file instead. I have put a link to the tutorial on this page.

@ Fergus:

Sorry, I overlooked the notation of the Omega Chess preset is different from what I imagined the Omega Chess rules page diagrams were (i.e. White first rank, not counting wizard initial cells, labelled with a 1). Anyway, even with the latest version of the preset, with a Black pawn on d3, if a White pawn triple steps to e4, the preset does not show that taking en passant by the Black pawn (i.e. moving to e2) is allowed, but the preset allows it if I try it for Black (in Move Mode).

The preset does correctly not allow a Black pawn on e2 to take a White pawn that double steps f1 to f3 (i.e. ...p e2-f1 is not shown as a legal option, nor allowed at all, by preset).

@ Fergus

I just tried the new Omega Chess preset in Move Mode, and found that while castling kingside is done correctly (with king moving just two steps), the preset has queenside castling incorrectly handled, with the king moving three steps (to c-file, not two steps, to d-file, as per the Omega Chess rules page).

Okay, I have corrected castling.

Well, the chess2 include file seems to have worked well enough that my 'Officer Chess enforced' preset maybe has only one minor quirk - if someone 'tries to castle' by moving the K just one square and then clicks on rook move as one of two options given (the way Greg coded a part of a preset which I edited), then an error message happens. The 'Very Heavy Chess' rules enforced preset by Greg, which uses chess2 include file, also has this quirk. [edit: I eliminated the quirk from 'Officer Chess enforced' by changing what Greg had for wcastle and bcastle, deleting a couple of extra squares represented, in each case - seemed to do no harm]

I just tried substituting the fairychess include file for the chess2 include file without making any other changes to Brawl Chess enforced preset, and I immediately had a fatal error. The tutorial for the fairychess include file looks very involved and I worry I might have to change/add a lot of code (never mind that I cannot seem to figure out yet how fairychess file might be able to handle K-3-step-castling in either direction as in Capablanca Chess, if it can), a process I don't understand much for Game Courier, being very rusty at programming. Thus it might just be easier for me to try making a rules enforcing preset for Brawl Chess with the Play-Test Applet, if and when I get around to it.

From what I see this preset does not do e.p. correctly for both sides. Black pawn on d3, white going c1-c4, e.p. should be allowed on c2 but it is not with this preset. Same situation on the other side.

The rule is clear on https://omegachess.com/rules#OmegaPawns

Anyway, even with the latest version of the preset, with a Black pawn on d3, if a White pawn triple steps to e4, the preset does not show that taking en passant by the Black pawn (i.e. moving to e2) is allowed, but the preset allows it if I try it for Black (in Move Mode).

It did show the en passant move to e2 as legal for me. Note that I made a new preset and did not overwrite the old one. So make sure you're testing the new one:

https://www.chessvariants.com/play/pbm/play.php?game=Omega+Chess&settings=fairychess

That link shows a preset with abstract piece set, unlike the one linked to on the 'What's New' page.

Yes, the one that's abstract does show that en passant possibility to e2.

edit: I refreshed my 'What's New' page and now the new preset page, including abstract set preset, is showing.

I just tried substituting the fairychess include file for the chess2 include file without making any other changes to Brawl Chess enforced preset, and I immediately had a fatal error.

That's not how to do it. It introduces a new programming paradigm that earlier include files do not use. It mainly involves copying some code, naming your pieces, and setting some parameters. Since the fairychess include file already includes definitions of many pieces, it cuts down on how many pieces you have to program yourself.

The tutorial for the fairychess include file looks very involved and I worry I might have to change/add a lot of code (never mind that I cannot seem to figure out yet how fairychess file might be able to handle K-3-step-castling in either direction as in Capablanca Chess, if it can), a process I don't understand much for Game Courier, being very rusty at programming.

How castling is defined has not changed. It involves storing the spaces each King may move to when castling into its own variable, either wcastle or bcastle. I found I had already begun work on a preset for Capablanca's Chess using the fairychess include file, and I just completed it and made it the new one. Here's a link:

https://www.chessvariants.com/play/pbm/play.php?game%3DCapablanca+Chess%26settings%3Dfairychess

@ H.G.:

I made a rules enforcing preset for 12x12 Brawl Chess generated by the Play-Test Applet, apparently not needing to use the custom set, as I followed your advice about altering IDs and/or moves of pieces (in my case to match the labels of the Sac Chess group, Sac Chess: Standard piece set, which uses labels of one character per the 14 piece types).

When I tested the preset (see link below), in Move Mode, the (Omega) Pawns were allowed to move initially up to 3 squares. However, I tested a case where early on in a 'game' I played vs. myself I moved a Black pawn up to d5, then made White pawn do triple step e3-e6. At that point the preset indicated taking en passant to e4 by the Black pawn was allowed - but when I played the move I got a fatal error message.

[edit: I had some other bugs with the preset, but then I realized I fouled up a couple of table entries for the Applet, so I went back and re-did them, and re-did the possibly affected parts of the Applet's 12x12 setup diagram for Brawl Chess, and then generated Game Code for my preset again. After that only the preset's bug with Omega Pawns seems to have remained. edit2: it seems any form of en passant is recognized by the preset as a legal possibility, but then a fatal error message results when it is actually attempted to be played.]:

https://www.chessvariants.com/play/pbm/play.php?game=Brawl+Chess&settings=enf02

I've edited my previous post, in case anyone missed it.

You hit on a major bug in the PTA here. The GAME code generated by the PTA, for efficiency reasons, tries to perform all moves of the game except the last as the game notation specifies them, without any computation. Based on the idea that these moves were already checked for legality earlier, when these were the last move so far. But this does not work for moves with implied side effects, such as castling, e.p. capture and creating e.p. rights. So these moves are considered special, and a computation for them is done even when they are not last, to determine their side effect (like moving a Rook, or removing a Pawn).

The problem was that the Play-Test Applet, when generating GAME code, did not group the ifmW* initial push of the Omega (or Wildebeest) Pawn with these special moves. So their side effect of creating e.p. rights was computed only when they were the last move so far (enabling the highlighting of the e.p. capture in the move to come), but when the e.p. capture was actually played, that became the last move, and the e.p. rights the multi-push should generate were no longer computed, making the e.p. capture illegal.

I now fixed the PTA to also group the W* moves with the special moves. If you want to fix your preset, it might be easier to just modify the code you pasted in the Pre-Game section. Near the end this says:

def P cond #0 1 21;
def p cond #0 32 52;

The 21 here should have been 16, the 52 should have been 47. If you make these changes e.p. capture should work in the preset. I would have done it myself, but it appears that even editors cannot modify other people's presets.

Thanks H.G.! Those slight changes you wrote I should make to my preset seem to have fixed it.

Well, I have to thank you for spotting and reporting this bug!

[Edit] I have now also made the Play-Test Applet itself aware that the first 6 pieces in the piece table should be treated as Pawns, and should thus be e.p. capturable when they slide up to the enemy half with their W* move. So the e.p. capture there should also work again.