Check out Chess with Different Armies, our featured variant for July, 2024.

Enter Your Reply

The Comment You're Replying To

Thomas McElmurry wrote on Tue, Feb 21, 2006 01:38 AM UTC:

Okay, I think I understand now.  I had been thinking of the Abstract piece
set as the default, not realizing that it was in fact a setting which had
overridden a previous default.  So it makes sense that I can't override
it in the URL, especially now that I've gone and learned a bit about the
GET and POST methods of form submission.

Here's a related thought (related from a user's perspective, anyway). 
When I enter my userid and view a game in which it is my opponent's turn,
the board is displayed, along with a message saying 'It is not your turn
yet', etc.  But the board is shown from my opponent's perspective. 
(Actually, a quick check of my current games seems to indicate that it is
shown from the perspective of the player to move [i.e. my opponent] in
Chess and Xiangqi, but from the perspective of the first [Black] player in
Shogi.)  Perhaps it would be more user-friendly if specifying a userid
ensured that the board would be shown from that player's perspective.

Edit Form

Comment on the page Game Courier Logs

Name or UserID: Password: if signing in with UserIDRating: Comment or question:
Format:

Conduct Guidelines

This is a Chess variants website, not a general forum.: Please limit your comments to Chess variants or the operation of this site.
Keep this website a safe space for Chess variant hobbyists of all stripes.: Because we want people to feel comfortable here no matter what their political or religious beliefs might be, we ask you to avoid discussing politics, religion, or other controversial subjects here. No matter how passionately you feel about any of these subjects, just take it someplace else.
Avoid Inflammatory Comments: If you are feeling anger, keep it to yourself until you calm down. Avoid insulting, blaming, or attacking someone you are angry with. Focus criticisms on ideas rather than people, and understand that criticisms of your ideas are not personal attacks and do not justify an inflammatory response.

Quick Markdown Guide

By default, new comments may be entered as Markdown, simple markup syntax designed to be readable and not look like markup. Comments stored as Markdown will be converted to HTML by Parsedown before displaying them. This follows the Github Flavored Markdown Spec with support for Markdown Extra. For a good overview of Markdown in general, check out the Markdown Guide. Here is a quick comparison of some commonly used Markdown with the rendered result:

# Top level header: `<H1>`

> Block quote 
>
> Second paragraph in block quote

First Paragraph of response. *Italics*, **bold**, and ***bold italics***.

Second Paragraph after blank line. Here is some <U>HTML code</U> mixed in with the Markdown, and here is the same `<U>HTML code</U>` enclosed by backticks.

## Secondary Header: `<H2>`

* Unordered list item
* Second unordered list item
+ New unordered list
    * Nested list item
- An URL by itself:
    + https://www.chessvariants.com
- A text link:
    - [The Chess Variant Pages](https://www.chessvariants.com)

### Third Level header `<H3>`
	
1. An ordered list item.
1. A second ordered list item with the same number.
2. A third ordered list item.

~~~
Here is some preformatted text.
  This line begins with some indentation.
    This begins with even more indentation.
And this line has no indentation.
~~~

![Alt text for a graphic image](/graphics.dir/cvp-logo-draft8.png)

A definition list
: A list of terms, each with one or more definitions following it.
: An HTML construct using the tags `<DL>`, `<DT>` and `<DD>`.

A term
: Its definition after a colon.
: A second definition.
: A third definition.

Another term following a blank line
: The definition of that term.

Top level header: `<H1>`

Block quote

Second paragraph in block quote

First Paragraph of response. Italics, bold, and bold italics.

Second Paragraph after blank line. Here is some HTML code mixed in with the Markdown, and here is the same <U>HTML code</U> enclosed by backticks.

Secondary Header: `<H2>`

Unordered list item
Second unordered list item

New unordered list
- Nested list item

An URL by itself:
- https://www.chessvariants.com
A text link:
- The Chess Variant Pages

Third Level header `<H3>`

An ordered list item.
A second ordered list item with the same number.
A third ordered list item.

Here is some preformatted text.
  This line begins with some indentation.
    This begins with even more indentation.
And this line has no indentation.

A definition list: A list of terms, each with one or more definitions following it.; An HTML construct using the tags <DL>, <DT> and <DD>.
A term: Its definition after a colon.; A second definition.; A third definition.
Another term following a blank line: The definition of that term.

Credits

Author: Fergus Duniho.

Comments

Game Courier Logs. View the logs of games played on Game Courier.

H. G. Muller wrote on Sun, Jun 23 04:57 AM UTC in reply to H. G. Muller from Mon May 13 05:54 PM:

It was announced in a longer Comment to which this is a reply.

Kevin Pacey wrote on Sat, Jun 22 11:41 PM UTC in reply to H. G. Muller from 05:47 AM:

Thanks H.G., I moved my Advancer as indicated and check was now announced by the Applet generated preset for Butterfly Chess in my game vs. Joe Joyce.

If there was a post on 13 May saying in effect that the preset would now work as I hoped (i.e. announce check by the Advancer move), I somehow missed such a post.

H. G. Muller wrote on Sat, Jun 22 02:26 PM UTC in reply to Fergus Duniho from 01:06 PM:

Anyway, your code employs huge tables that somehow define how a piece moves, and I don't understand how these work.

The format used to encode (possibly complex) moves in the table is to split those into a sequence of rides ('legs'). Each ride is characterised by four parameters: maximum number of steps, x-step, y-step, and an integer where each bit corresponds to a 'power' that the leg has. (Like can-capture-destination, can-move-to-destination, can-e.p.-capture-to-destination, base steps cannot jump, base steps must jump, can-hop-over-destination, initial-move-only, must have as many steps as previous ride, etc.) Each move is encoded as the number of legs N, followed by N leg descriptions of four numbers each. The moves of a piece are tabulated all behind the other, the end indicated by a dummy move of zero legs (i.e. just a 0).

For example, an orthodox Rook would be encoded as four simple slides in different directions:

1 99  0  1 3
1 99  1  0 3
1 99  0 -1 3
1 99 -1  0 3
0

Where the 3 stands for can-move (1) and can-capture (2). The 99 is used to indicate an unlimited range. For leapers this would be 1. The moves of all pieces are all stored one after the other in the same array 'legdefs'; I use functions with the name of the piece label that return the index in legdefs where the moves for that piece starts.

A bent rider like Griffon would have moves consisting of two legs, like

(showing one simple F move, and two bent slides). The first leg of the latter is a (1,1) leap to an empty square, the second leg an unlimited-range slide with (1,0) or (0,1) step that can move or capture.

There is a GAME-code routine NextLeg which interprets the table in order to lay out all tabulated moves for a given piece on the board, and for each move it can make to a valid final destination it then calls a routine to do something with that move. (Like comparing it to the input move, or add it to the array of legal moves for highlighting.)

There is a slight complexity: normally you only have to worry about (pseudo-)legality for the last move in the game, and do that in Post-Game code. The earlier moves were already vetted in the turn they were entered. So you can take them at face value, performing them 'no questions asked'. This does not work for moves with implied side effects (i.e. board mutations not indicated in the move notation), such as e.p. capture. Such moves would have to be generated for every move in the game, and if the explicit part matches the stored move, the generated side effect would have to be performed as well.

To this end moves with implied side effects are always stored behind all others, and the routine that returns the index of the first move to be tried for a piece of that name has a parameter that indicates whether you want to try all its moves, or only those with implied side effects. By convention pieces without such special moves point to an empty movelist (a single 0), stored at the start of legdefs.

🕸📝Fergus Duniho wrote on Sat, Jun 22 01:06 PM UTC in reply to H. G. Muller from 08:00 AM:

In principle legality of each psudo-legal move M can be tested by performing the move, and then trying all pseudo-legal moves of the opponent to see if any of those captures the King.

This is beginning to explain how you organize the evaluation of moves, and there are some differences from what I do. My code does not perform every move before testing it. While it does perform actual moves before testing them, it evaluates potential moves without performing them. When it comes to evaluating whether a move places a King in check, it does not go through a list of pseudo legal moves to see if any capture the King. Instead, it does not bother to build a list of pseudo legal moves for the position, and it simply checks whether any enemy piece has a legal move to the King's position. After all actual moves have been evaluated, my code will then evaluate the potential moves and build a list of legal moves. It evaluates each potential move in stages. First, it builds a list of the spaces the piece might possibly reach with its powers of movement. Then it checks for pseudo-legal moves to these spaces. For each pseudo-legal move it finds, it performs the move to check whether the resulting position places the King in check.

Since this is in the context of the Advancer, which does not capture by displacement, I will mention here that my code assumes displacement capture but can handle non-displacement capture when appropriate functions are written for it. I have done this for Ultima, and I have an earlier comment explaining this in detail.

What I was saying I don't understand, though, was how you handle the evaluation of individual moves. My code evaluates individual moves with individual functions for each piece and sometimes employs subroutines for evaluating actual moves. The functions are all designed to work without the need of performing the move first. Since actual moves get performed before their evaluation, a subroutine may sometimes be used for the actual move of a divergent piece. But if a divergent piece has no side effects, a function might be designed to work for both actual and potential moves, such as this Cannon function is:

def Cannon cond cond empty #0 capture (not empty #1) (checkhop #0 #1 0 1) (checkride #0 #1 0 1) and #1;

This function tests whether the origin space is empty to tell whether the move has already been performed. If it has been performed, it tests whether a capture has been made, and if it hasn't been performed, it tests whether the destination space is occupied.

Anyway, your code employs huge tables that somehow define how a piece moves, and I don't understand how these work.

H. G. Muller wrote on Sat, Jun 22 08:00 AM UTC in reply to Fergus Duniho from 12:20 AM:

I don't even understand how Applet generated presets evaluate legal moves.

Conceptually this is not very difficult. In principle legality of each psudo-legal move M can be tested by performing the move, and then trying all pseudo-legal moves of the opponent to see if any of those captures the King. To speed this up it only tries the opponent moves that were already attacking the King before move M was made, and all moves that were affected by M because they encounter a square the occupancy of which was changed by M in their path. Most moves only affect two squares, the origin and the destination, and only a small fraction of all moves would have found one of these two squares in their path.

Moves that were not attacking the King before M, and did not encounter a square mutated by M, will not attack the King the King after M.

Number of ratings: 29, Average rating: Excellent, Number of comments: 736

List all comments and ratings for this item.

Add a comment or rating for this item.

The Chess Variant Pages is an amateur, hobbyist website that has been run by volunteers since it was founded in 1995. It focuses on documenting games based on, related to, or similar enough to Chess and on letting you play many of them.

Who What When Where Why Which How

Privacy

Operating expenses are covered through advertising and donations. Help out by making a PayPal donation or by shopping with these affiliate links:

https://server.chessvariants.com/index/editcomment.php
First Created: Wednesday, January 16th, 2002
Last Modified: Tuesday, September 9th, 2003
File Timestamp: Tue, 05 Mar 2024 01:07:52 +0000
[info] [links] [edit]

Enter Your Reply

Top level header: <H1>

Secondary Header: <H2>

Third Level header <H3>

Top level header: `<H1>`

Secondary Header: `<H2>`

Third Level header `<H3>`