Comments/Ratings for a Single Item

Further investigation pinpoints the problem in the underscore.  I've tested pieces with underscores at the beginning, end, and middle of the designator - other pieces with multi characters but no underscore seem to work.  Is there a way around this without having to rename pieces?

The Alfaerie: Many set is one I have never used and do not recommend the use of. Consequently, I have never tried to program around its limitations. I recommend creating your own set, but if you don't want to do that, then you might try using one of the automatic sets, which name pieces after file names.

It has occured to me since writing this that you could name your functions after aliases instead of the actual piece labels and be sure to use the aliases and not the actual labels when calling the functions.

def G checkride #0 #1 1 0 or checkleap #0 #1 1 1;
def GL merge rays #0 1 0 leaps #0 1 1;

I understand that the #0 and #1 stand for the initial square moved and final square moved, but I don't understand how the 1's and 0's after those work exactly, though I have been able to fudge the results I want with those.

The other ones and zeros are actual ones and zeros, not variables. They are arguments to the function. Your definition of G checks whether the piece moves as a Dragon King. "checkleap #0 #1 1 1" checks whether a piece can make a one-space diagonal move. This can also be done by calling checkaleap up to four times, like so:

checkaleap #0 #1 1 1 or checkaleap #0 #1 1 -1 or checkaleap #0 #1 -1 1 or checkaleap #0 #1 -1 -1

In checkaleap, the first number is how many files a piece moves in its leap, and the second number is how many ranks. In checkleap, the order and signs of the numbers do not matter. Instead, the two values are used in whichever order and whichever positive or negatives values are most applicable to the actual move. This allows the values of 1 and 1 to describe any one-space diagonal move.

For the leaps function, the order of the numbers and their signs also do not matter. From a single pair of values, all possible combinations of orders and negative or positive values are calculated. Up to eight combinations are possible. For example, "leaps #0 1 2" would return up to eight legal moves for a Knight. But when the values are the same, or when one is zero, this cuts the number in half.

"checkride #0 #1 1 0" checks whether it moves as a Rook, which makes a riding move through a series of steps in a direction that moves one space at a time along a single rank or file. The same thing could be checked with four checkaride functions, like so:

checkaride #0 #1 1 0 or checkaride #0 #1 -1 0 or checkaride #0 #1 0 1 or checkaride #0 #1 0 -1

In checkaride, the first number is how many files the piece moves on each leap, and the second is how many ranks it moves on each leap. In checkride, the order of the numbers do not matter, and their signs do not matter. It will use them in whichever order and arrangement of negative and positives values best fits the actual move. This allows "1 0" or "0 1" to be used to describe movement along a single dimension of the board.

For the rays function, the order of the numbers and their signs also do not matter. From a single pair of values, all possible combinations of orders and negative or positive values are calculated.

Fergus,

I finally finished my first presets that enforce rules.  The game was for one that I created presets for before, so modifying that page with the updated presets wasn't a problem for me.  If I wanted to, though, code a rule enforcing preset for a game that I did not do the preset page for, what is the process for that?  Do I have to submit a brand new preset page, notify the person who did the preset originally, notify an editor, or obtain permissions to edit the page?  

I was thinking about upping the challenge to "Chess on a Really Big Board" since I am playing a game of it already.  Jeremy Good originally did the first preset and settings file and is no longer active on the site.  Are you wanting the original settings file altered or a new one created?  Thanks!

-Nick

Ok, so I've been on a good venture trying to figure out how to code a Rose.  With the help of Fergus, I have learned about the logride function and after lots of experimenting on format, I discovered how to do it!  I successfully did one leg (out of 16) of the Rose's pathways, but when I tried to add a second leg, the code stops functioning as if the piece had no moves at all.  I'll copy the partial code used.

def RO logride #0 #1 (ro1 ro5 ro7 ro3 ro4 ro8 ro6) or logride #0 #1 (ro1 ro2 ro6 ro8 ro4 ro3 ro7);
def ROL merge lograys #0 (ro1 ro5 ro7 ro3 ro4 ro8 ro6 stop) lograys #0 (ro1 ro2 ro6 ro8 ro4 ro3 ro7 stop);

The ro#'s are previously defined and mapped to each individual knight moves so I can use the logride command.  I believe the problem lies in the ROL function, but I can't find any mispellings, errors in the merge command, etc.  It all worked fine until I added the second logride and logray.  Any assistance would be appreciated!

Also, any suggestions on code condensing on this point?  Am I able to create a function for each leg without having a piece on the board to name the function after?

Solved.

Hi Nick,

I am not aware of any established policy, but it is a good question.  As far as my personal feelings, I have no problem whatsoever with you improving the existing presets if the original author is no longer active.  And simply adding rule enforcement to an existing preset should constitute an improvement.

I was wondering if there was any further answer on the below question, as well as I have a new question.

Though I enjoy the ease of having the include files to program presets with, is there a way to pick and choose what code is being used?  For example, if I want to include chess3, but the game does not have castling, as in Courier Chess or Cetran Chess 2, is there something I can tack on in the code to disable the castling code within the include file or do I have to omit the include file and copy and paste the code I want from said include file into the preset separately?  Thanks!

Whenever you write a function or a subroutine with the same name as a previous one, it replaces it. So, you could include chess3, then after including it, write new k, K, and stalemated subroutines that do not include castling. But with regard to castling, things are even simpler than this. Since chess3 relies on the variables wcastle and bcastle to know which spaces a King may castle to, just set them to empty arrays, and castling is disabled. Do this after including chess3, so that these new values overwrite the ones set in chess3.

In regards to programming, how do moves that can end in 2 different board positions work?  I'm specifically addressing Wildebeest Chess - a King can castle 1-4 spaces away from the start square.  With my code, I can castle to any of those squares except the one right next to the King.  Moving there does not result in a castle that should be legal, just a King move.  Is that a matter of programming or is that a matter of game notation?  

I used the allow command to grant an additional move and tried to even type a movement out for the rook to move, but it deemed the move illegal.

Is GC able to handle moves (aside from promotions) that can have different outcomes on the board?  If so, how would it be done?

Look at how castling is handled for Fisher Random Chess. There castling moves that would map onto normal King mvoes or even non-moves are handled as Rook moves. The trick is to make each possible move a different move on the board, then handle each of those moves differently in your code.

Thats a great idea.  I'll look into that today after our errands are finished.

Note that the standard way used by GUIs to handle Chess960 castlings is by dragging the King on top of the Rook you want to castle with. Or, in text form, write it as if the King captures its own Rook.

This works fine to distinguish King solo moves from castlings where the King moves to the same square. But it loses the possibility to select between castlings that differ in the location where the King ends, (as you have in Wildebeest Chess). In XBoard I excpanded on the idea by entering such flexible castlings as a multi-leg move including a friendly capture of the Rook. So you start capturing the relevant Rook with the King as firrst leg of the move. But because the move was defined as two-leg, this does not conclude the move entry, but you have indicate the King destination square after that. This still assumes that the Rook destination is fully implied from the other three squares.

Note that the standard way used by GUIs to handle Chess960 castlings is by dragging the King on top of the Rook you want to castle with.

If the GUI is for a program that plays the game, that makes sense, because it is important to keep the game logic as simple as possible. But Game Courier doesn't play games. It just facilitates the play of games. Since simplifying the game logic wasn't a concern, I favored handling castling as a move whose notation will coincide with one of the two pieces going to the position that it will end up in.

Typically, the GUI and the engine of modern chess programs are well separated, so the way the castling move is inputted really has no impact on the efficiency of the engine.  Modern chess GUIs handling castling in FRC this way only because someone thought it made sense.  And, purely in the context of FRC, maybe it does.  But in the larger sense of supporting chess variants in a unified, intuitive way, I don't think it makes sense at all.  For a game like the capablanca variants with flexible castling, for example, capturing the rook doesn't make any sense since that doesn't tell you where the rook goes, where as simply recording the king-from square and king-to square tells you everything (which, incidentally, is exactly how chess programs handle orthodox chess.)

Wildebeest is icky because moving a king a single space can be unclear whether you mean to castle or simply move the king.  FRC can have this ambiguity also with certain arrays.  In ChessV, I handle this all in what I consider the simple, consistent, intuitive manner.  When castling, you just move the king.  If there is an ambiguity, a dialog box will ask you if you are making a standard move or a castling move.  Prompting the user is not radical, as normal chess programs do this too when you move a pawn to the last rank.

Normal chess programs probably do the capture-the-rook thing because it was a simple fix to a problem with FRC and they weren't thinking in any larger context.  Chess programs basically played no variants at all until some started adding support for FRC and even that was probably added reluctantly in many cases.

I'll be honest and say that this castling routine is kicking my butt.  I'm not the most adept at coding, I just go by example, but I'm having trouble decoding other games' castling and applying it to Wildebeest.  I was trying to get this ready for the tournament, but I'm passing off the reigns to someone else.  Sorry guys.

Normal chess programs probably do the capture-the-rook thing because it was a simple fix to a problem with FRC and they weren't thinking in any larger context.

With FRC on Game Courier, I was concerned with consistency across different games, and not at all with how the game had been handled by other programs. Since in most Game Courier games, castling was handled as the move of a single piece to a space it actually goes to, I just extended that to work with FRC.

If there is an ambiguity, a dialog box will ask you if you are making a standard move or a castling move.  Prompting the user is not radical, as normal chess programs do this too when you move a pawn to the last rank.

Game Courier can do this too, as it commonly does for promotions. But I did write Game Courier in stages, and when I first put together a preset for FRC around 14 years ago, Game Courier didn't have all the capabilities it has now. Back then, GAME Code did not yet exist as a Turing-complete programming language, moves could be entered only by writing notation, and the commands now in use for diambiguating moves through prompts were not yet available. The early preset probably just randomized the position without enforcing any rules. When rule enforcement was finally made possible, moves were still being entered only by notation, and the mechanisms for handling mouse moves, which includes prompts for disambiguating moves, were not yet in place.

My comment wasn't intended to be a criticism of GC.  Just waxing philosophical on what I think makes the most sense, since we were discusssing.