Ratings & Comments
This is what I expected. Stockfish uses bitboards, and the standard algortithms for bitboards are very much specialized for sliding along diagonals and orthogonals. Fast algorithms for check detection also often assume that moves are reversible which is also not true for bent riders.
Thanks, HG!
The moves aren't completely clear to me; some examples would probably help.
The sliders must reach an empty square beyond a single captured piece, I think? The knights can capture up to three pieces, but always move 2 then 1? The kings don't capture at all?
Since this comment is for a page that has not been published yet, you must be signed in to read it.
I don't know what PGP has to do with Game Courier, but the problem is now fixed. Perhaps you meant PHP.
In the rules it says that the dromedary moves are induced only in no pawn pieces. Also why did you added a H power to the dromedary?
I have done a complete overhaul of the move-entry routine of the Interactive Diagram. It is now based on the move generator of the AI, which has a more elaborate system of move encoding than the old highlighting routines. In particular there is no longer any limit to the number of locust victims a move can have.
The new system works by generating a list of all moves for the side whose piece gets clicked, and then click by click delete the moves that do not correspond to the clicks that have been made so far. In principle all 'destructive' legs of the move have to be indicated in the order the piece traverses those (according to the XBetza move definition). So the first click serves to identify the origin, the next clicks all the locust squares, and finally the destination square. Hopper mounts or bends in a trajectory do not have to be clicked.
After a click has reduced the number of moves that still conform to the click sequence, the first not-yet-selected square of all these moves gets highlighted. If a square gets multiple highlights a click on it won't reduce the number of moves in the list to one, so it cannot be the final click. To indicate that, it is highlighted by a blue star (as in the old system). Even if only a single move would go over that square, but it is not the destination, it is highlighted this way, and the user is expected to click subsequent squares visited by the move until the destination. (There is in general no 'autocomplete of moves'.) Square that would finish the move entry when clicked, because it is only used as destination of a single move, are highlighted depending on the type of move (capture, non-capture, initial, castling...), as in the old system.
The system tries to be smart w.r.t. the click order, though. It recognizes moves that were generated as e.p. captures or castlings, and does not require you to click the e.p. victim or Rook as locust squares. For each move that is generated it assigns an order in which the relevant squares have to be clicked to select that move. For castlings it actually does define the third click (after King origin and destination) to identify the Rook, (which is essential to disambiguate a normal King move from a castling where the King steps only a single square). But castlings are an exception to the rule that moves are not auto-completed, so if there is no ambiguity it would not request the Rook click.
For locust captures it uses a heuristic to distinguish 'shooters' from 'tramplers'. If the XBetza definition of the move ends in a back-and-forth locust capture, that either does not consist of King steps, or the point from where it started was not reached by a King step, it is classified as a shooter. The click order is then modified so that the destination has to be clicked before the locust victim, and no click is needed to return to the destination. Tramplers keep using the standard click order, where they visite all locust squares before the destination gets clicked.
There is an additional issue: The AI's move format not only specifies squares that get mutated, but can also specify one or more squares where e.p. rights get created. Sometimes two moves to the same destination only differ in the e.p. rights they create (for a multi-path piece that can be e.p. captured). Betza's Doublemove Chess is an example of that. Such ambiguity is also recognized by the new move-entry system, and the e.p. square is in that case included in the click order (just before the destination). Normally e.p. squares would not have to be clicked.
The system seems to work now; I still have to integrate it with the AI and game-recording routines. It will not be used as the default move entry for the Diagram script until that is also done. But here already is a Diagram with a variety of pieces that show some of the possibilities:
satellite=test
files=10
ranks=10
graphicsDir=/graphics.dir/alfaeriePNG35/
squareSize=35
firstRank=1
lightShade=#FFFFCC
darkShade=#669966
holeColor=#663300
rimColor=#663300
coordColor=#D6DEAD
whitePrefix=w
blackPrefix=b
graphicsType=png
useMarkers=1
borders=0
enableAI=1
newClick=1
pawn::ifmnDfmWfceF::a3-j3
double knight:N:NmmamN:nightrider:b2,i2
valkyrie::BudBafudB:bishop:d2,g2
rook::::a1,j1
forest ox::NmpafsmcacabK:ox:c2,h2
dragon::KADGHcavKmcafcavKpafcafKcafmpafK::f2
lion::KNADcabKcaK::e2
king::KisO1isO2isO3isO4::f1
|
Move-Entry test |
The Forest Ox is a shooter, which optionally destroys an adjacent piece after his Knight move. The Valkyrie is a swapper, that can relocate a friently piece at its destination anywhere along its path. Both these pieces are from Odin's Rune Chess. The Dragon is the Lion Dog from the large Shogi variants; it can capture up to 3 pieces. The Lion is from Chu Shogi. Both these pieces are tramplers. The Double Knight can make two Knight moves in one turn, but only if both are non-captures. After a double move it can be e.p. captured (by Pawns, the only pieces that can do e.p. capture here). It also can do a single Knight move. The King has flexible castling, 0 to 4 steps.
This preset and the Apothecary Chess-Modern one, are broken. The problem seems to be with the rank labels. The rank labelled 0 is removed from the setup, but if you change the rank label to something else it will display properly.
I rewrite the page understandingly Knight can capture up to 2 pieces, but he can capture a piece which stands in the corner of the board. All rangers can capture up to 6 pieces.
Pieces check differently from how they capture? But you write they can also capture the King?!? Or is it only the Knight that captures differently from how it checks?
Help is needed. I'm trying to accept Numerist's invitation at Pemba. When I click on "Anyone" I get this message:
Your userid is timurthelenk. This log is private. It may be viewed only by the players. If you are one of the players, please sign in first. You may use the menu for this.
I remember that it was also the case few days ago, also with an invitation from Numerist, and Aurelian had also the same problem, getting a similar message.
Maybe Fergus may have a look. Is Numerist doing something wrong when inviting? Or something else?
Thank you
I don't see the invitations you're speaking of. So, I can't look into it. The message you're reporting should be displayed when someone tries to accept a private invitation meant for someone else.
The description of Knight's move was edited as follows :
-> Moves to the nearest square among squares that do not correspond to the same file, rank, and diagonal from its position.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
yes, PHP. lol. oops. Thank you.
I will write it in page. All pieces are checking on their moving and capturing’s lines, but Knight is checking on his moving squares, and is capturing by dissect.
Paul had deleted his invitation in between. Strange, it was an open invitation to anyone and I was getting this message as if the invitation was private. We will see if this occurs again in future. Thanks.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
I extended the functionality of the morph parameter. It can now not only be used for specifying irregular promotions / piece-type morphing, but also to specify inaccessible or goal areas for each piece type. For this a square in the board image would have to contain a ! (inaccessible), + (delayed win) or # (immediate win). A piece ID indicates forced promotion to that piece type, a * a promotion choice according to the rules specified with the promoChoice parameter.
I added a section to the article to describe the morph feature, also giving some examples of its use.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Dear Publishers, How can we record our own include files that are stored on and recalled from "/play/pbm/includes/" directory ? I would need this to modify move definitions of some pieces. Side question: how can we suppress old inactive setting files ? Regards, SB
Can Canvasser be Agitator?! In my notation, he is it. Noted as Ç
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
25 comments displayed
Permalink to the exact comments currently displayed.
So it seems stockfish cannot do bent riders!