The Chess Variant Pages
Custom Search




[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Latest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Latest Ratings and Comments

Later Reverse Order EarlierEarliest
wrong personal invitations[Subject Thread] [Add Response]
Aurelian Florea wrote on 2019-06-12 UTC

All right!...


Carlos Cetina wrote on 2019-06-11 UTC

@Aurelian

Please note that the pair of personal invitations you gave me recently 

Modern+Chess&log=-Vernon+Parton-2019-159-445

Symmetric+Chess&log=-Vernon+Parton-2019-159-446

were wrongly addressed to a Game Courier user that does not exist: carlos cetina (with lowercase initial letters).

I am registered as Carlos Cetina (with uppercase initial letters) and userID: sissa.

Such logs are not listed in my "Your Games on Game Courier" page.

Now then, regardless of this random fact, I'm sorry to tell you that I'm currently focused on promoting the Symmetric Chess only; and, for reasons of time and energy savings both physical and mental, I have decided not to play other variants except those included in the current tournament.

So my dear friend, send me all the invitations you want as long as they be of Symmetric Chess!!!


Chess variant engines and CECP (XBoard) protocol[Subject Thread] [Add Response]
Greg Strong wrote on 2019-06-04 UTC

Yes, you're right, I was still on 1.2 somehow.  I will test with 1.3.


H. G. Muller wrote on 2019-06-03 UTC

Are you sure you got the new version, and that there was no problem with your browser caching the old version? It should say cwda-1.3 for the version number, and have 'dragons' as one of the options for the White/Black Army (not properly working yet, though). I tested it with a position "8/6P1/6k1/8/8/8/8/1K6 w - - 0 1" in FIDE vs Rookies, and it does play g7g8q without quote in that position.

In earlier versions I had some crashes too, which seemed to occur when the score got extreme. This disappeared after I calculated the interpolation between opening and end-game evaluation in a less overflow-prone way, and the version I originally posted had played several hundred games against Fairy-Max without a single crash. It could be that I broke something when changing the check test to also work with ski-slides. (But I see in the log that this happened for 1.2, so this cannot be the explanation.) This crash also doesn't reproduce.

Indeed I did not put equal armies in the list it announces in the variants feature. It would recognize the names in the 'variant' command, but of course a proper GUI would never send those if the engine did not announce it supported those. It is possible to play equal armies by selecting those through the White/Black Army options, and then select variant fairy. (This is how I test, as it currently is the only method where it is compatible with Fairy-Max, when I tick the option for old piece names, and turn traitor promotion off.)

BTW, in the log I see that you did not send a 'memory' command to set the hash size. That means KingSlayer would use its default hash size, which is only 1MB.


Greg Strong wrote on 2019-06-02 UTC

Also, it looks like it doesn't support both sides playing the same army?


Greg Strong wrote on 2019-06-02 UTC

Sorry, H.G., it looks like that did not solve the problem.  I am also getting an occasional crash.  I'll email you the debug output.  But when it doesn't crash or make illegal moves, it seems to win the majority of the time :)


H. G. Muller wrote on 2019-06-02 UTC

A yes, this was something I couldn't test, because WinBoard doesn't accept dressed letters as promotion suffix yet. This was a bit of a subtle bug: the quote suffix was initialized to 0 when entering the MoveToText routine, and then set to a quote if promotion to the 7th piece type occurred before being printed. But by an oversight the suffix had been declared as a static char, so the initialization did not work on every call of MoveToText, but only at program start. So once a move with quote suffix was printed, all promotions would from then on be printed with this suffix. (But WinBoard happily ignored that.)

I uploaded a fixed version to the same link.


Greg Strong wrote on 2019-06-02 UTC

Nice!  I didn't have an opportunity to mess with this during the week, but I now have KingSlayer cwda integrated within ChessV cleanly.  It is pretty strong!

I am finding one issue, though.  Sometimes upon promotion KingSlayer sends the wrong notation. For example, ChessV was playing the Clobberers with the white pieces and KS was playing the FIDEs with the black pieces.  When it went to promote, it sent c2c1q' which is not correct.  The Queen is part of its army, not the opponents, so the quote shouldn't be there.  (ChessV then says it forfeited due to illegal move.)


H. G. Muller wrote on 2019-05-29 UTC

The previous version was still plagued by a woken-up 'sleeper bug': all the end-game discounting worked fine when I tested it on setup positions for the end-game, but it did not apply it when the same end-game was reached in games! Turned out castling messed up the Rook counter, which had never mattered before, as the count was not used. But now it made the drawishness code think both sides had (tons of) Rooks. I uploaded a fixed version ("KingSlayer cwda-1.2") to the same link. This also prints some results of the drawishness detection for the root as part of the Thinking Output, so that it can be easily seen when it misjudges. Like Fairy-Max it slightly randomizes the first 8 ply of any game, (adding -8 to +7 cP to the score of each move in the root), to provide more game diversity in test runs.


H. G. Muller wrote on 2019-05-27 UTC

OK, I seem to have produced something that works according to specs. I uploaded it to http://hgm.nubati.net/CwDA.exe. I had it play matches against Fairy-Max in FIDE-Nutters and Clobberers-Rookies, and there don't seem to be any illegal moves anymore. I did this using the old piece IDs of Fairy-Max, but in the uploaded version I replaced this by the new IDs we agreed on, but added a checkbox option that can be used to select the old IDs. The piece-to-char tables sent in the 'setup' command still always use the old IDs, though, and don't provide IDs for pieces of the opponent army; this is still something I have to fix. But I am not sure ChessV even looks at the setup command, and the pieceToCharTables probably have meaning for Win/XBoard only.

I also added a checkbox option 'Traitor promotion', where you can switch the possibility to have it promote to the super-piece of the opponent army on or off.

[Edit 2019-05-28] I fixed a problem with input of under-promotions, (which could not be tested by playing against Fairy-Max, as it never does those). It now also can do all under-promotions to pieces of its own army (the FIDE version of KingSlayer only considered promotion to Q and N, but not in all armies the other pieces are as redundant as B or R). The pieceToCharTables in the 'setup' command now use the piece IDs that are selected by the old IDs option, and merge in the super-piece of the opponent army, if the 'Traitor promotion' option is enabled.


H. G. Muller wrote on 2019-05-25 UTC

I currently put an extra ~ in the names compared to what I proposed here earlier: A~B~(C) instead of A~B(C). This looked more balanced (the latter form suggested a tighter coupling between B and C). This would also make it possible to recognize '1-parameter' sub-variants by the ~ alone, e.g. bird~(10x8), carrera~(10x8).

Name explosion would occur when a sub-variant needs multiple parameters (such as CwDA); with a single parameter the possible parameter values would have to be mentioned anyway. We could solve it by introducing wildcards for the parameters: nutters~*~(cwda) would mean the variant group 'cwda' has two parameters, and 'nutters' would be a possible value for the first parameter. Such a partial variant declaration would be discarded if there weren't also declarations of the form *~rookies~(cwda) in the variants feature to specify some possible values for the second parameter. This is not backward compatible with existing GUIs, though; these would not recognize the * as wildcard, and take the names litterally. This problem could be ameliorated by making the engine such that it would also accept the names with the wildcard in it in the 'variant' command, and would treat the parameter value * as a command to keep the previous value of that parameter. A user could then still make the selection Nutters vs Rookies by first selecting nutters~*~(cwda), and then switch to *~rookies~(cwda). (On second thought, we could adopt the convention that a second parameter that is only given as a wildcard in all the supported sub-variants would be assumed by the GUI to allow the same values as the first parameter. The engine, when confronted with * for this parameter, could then use the previous value of the first parameter for it.)

BTW, many of the problems you mention for Cylinder Chess sound familiar. I remember that at some point of implementing XBetza support in XBoard I decided moves should be generated after 'lifting' the moving piece off the board, in order to allow bent multi-leg moves to pass back over itself (e.g. for igui). That caused XBoard to hang with an oR on an empty rank... I solved it by making the Betza-driven move generator such that it would treat all slides as finite-range slides with the maximum board dimension minus 1 as range. If you already support finite range slides, this would cause no extra overhead.

SEE is indeed troublesome, if there are pieces with fancy moves. But like you say, it isn't really necessary. Pure MVV/LVA already is pretty good, and Fairy-Max gets by with only sorting the MVV/LVA-wise best move in front, and searching the other captures in arbitrary order. My guess is that >90% of the beneficial effect of SEE comes from detecting if a piece is completely unprotected, so that HxL captures on it are safe. So I often use the simpler algorithm BLIND, which postpones HxL capture of protected pieces compared to MVV/LVA. This still requires you to know whether a piece is protected, though. The null-move reply could have told you, but in QS there is no null move. You could get (somewhat inaccurate) protection information as a side effect from the move generation that was done in the parent; this could have marked all pieces that block friendly captures as protected (e.g. in a bitmap of the board or of the piece list, or even a (packed?) set of counters, to be able to correct single protection for the piece that was moved).

KingSlayer uses MVV/LVA, but it has a provision to initially abort the search of HxL captures that go sour, to reschedule them until after the other captures have been searched. To this end it can pass the value of the victim as 'threshold' to the child. When that child then generates a capture of a piece more valuable than 'threshold' on that same square (which it would after H x protected L), it immediately returns 'abort score' INF+1 (so the caller can see that the capture was bad and needs to be rescheduled). As an extra it would also abort if the 'obvious gain' from capture on a different square would exceed 'threshold'. Where that gain is defined as the value of the victim if unprotected, or the difference between victim and attacker value if protected. This protection information is obtained from the parent (inaccurate as it is, but only used in 'second order'). Normally you would only abort on capture of a King (returning +INF, as no rescheduling is needed), i.e. use threshold = INF-1. This is what is done during the search of the rescheduled captures, to prevent it would abort again.

Duplicat moves are not really a very large problem; the duplicat should give a hash hit that makes it fail low immediately. Bifurcating pieces (e.g. bent sliders like the Griffon) also tend to produce them, if you are not careful to define the overlapping part of one of the branches as a lame leap.

Bent sliders (including the ski-jump case) are pretty nasty anyway. They blur the distinction single vs double check, as beside offering the possibility for triple (or even quadruple) check, they can cause double check to occur along a single path. So that contrary to normal double check, it can be resolved by interposition (but still not by capture of the checker). The ski-slide of the Wyvern thoroughly wrecks KingSlayer's implementation of check detection and handling. Perhaps I should not spent further time on that now, and try to get the other armies working as quickly as possible.

In that case I am nearly there; I have implemented a rather general material evaluation that reproduces the general trend of the EGT results, driven by a 32-bit 'properties' word for each piece type. The even bits in this word are used as flags to indicate whether that piece has the corresponding property (e.g. mating potential, color binding, lacking mating potential even as a pair, being rather weak for a major, etc.). As I won't do any score discounting with more than 2 pieces for each side, the property words can be added for each player, and when both pieces have a certain property, this cause a carry to the (originally unused) next-higher (odd) bit. This makes it easy to recognize conditions like having two majors (almost always a win), having a pair of Knights (draw), having only minors (draw against any defender), etc. Pieces with the 'super-piece' property will use a 2-bit field in the properties word to indicate their ranking, so that we can decide whether an extra minor on their side will make it a win.

It also detects uneven distribution of color-bound pieces over the square shades, to penalize that by a fixed score (which is equivalent to awarding a pair bonus), and declaring a draw when it happens to the only two pieces in absence of Pawns. And when both sides have full color binding on opposite shades it will discount the evaluation by a factor 2 even with many Pawns. This seems to capture the most important effects. I guess I could still have it invoke the existing code for detecting a KBP.K draw in all cases where the only remaining piece is color bound.

Still have to test everything, though.


Greg Strong wrote on 2019-05-24 UTC

Wouldn't it be more logical to use 'E' for the War Elephant? It is likely to be depicted as an Elephant, so this would have a better mnemonic value.

Yup, I agree with this.  I have updated the table.

Just let me know what exactly you want the xboard game names to look like.  I was thinking we could extend your idea a little and say that where game-specific parameters need to be encoded in the game identifier, they are formatted like P1(game) or P1~P2(game) or P1~P2~P3(game), etc.  CwDA has two parameters, P1 is white army and P2 is black army.  At some point I would like to come up with a better option for programs that support it so we don't have an exponential explosion of game names, but as a starting point, and for backwards-compatability with programs that don't support it, this seems like a promising approach.

I'm really looking forwards to having multiple interoperable CwDA engines.  I originally started writing ChessV because I wanted to better study CwDA and Zillions wasn't good enough (and there was nothing else.)


Aurelian Florea wrote on 2019-05-24 UTC

@HG

I had sugested, for one of his variants, the name platinum general for the drunk elephant. To me that seems more interesting. But that's a bit off topic!...


H. G. Muller wrote on 2019-05-24 UTC

Wouldn't it be more logical to use 'E' for the War Elephant? It is likely to be depicted as an Elephant, so this would have a better mnemonic value.

You make a strong case for 'Lion'. (And it indeed is a very nice piece.) I suppose the reason I don't like it is that I am just too involved with Shogi, and that the Lion is such an iconic piece there. But I guess I just should come to terms with the fact that Shogi names often have completely different meaning than those in western chess variants, and that a (Drunk) Elephant is nothing like an Alfil, and a (Dragon) Horse nothing like a Knight.


Greg Strong wrote on 2019-05-23 UTC

I like Lancer as well.  So the Fibnif becomes Lancer (L), freeing up N for the Charging Knight.  Now we are only changing the names of pieces Betza didn't get around to yet and we still have pretty good one-letter notations.

I have updated the table below.


H. G. Muller wrote on 2019-05-23 UTC

"Lancer" does seem a good name, as a Lance seems to be a weapon ill-suited for lateral combat.


Aurelian Florea wrote on 2019-05-23 UTC

A good name for the narrow knight could be searched in the realm of light cavalry, maybe. Lancer or hussar could be interesting options. Donkey is a fun option also for the not this "not that horse" piece, but maybe this is not that appropriate. 


Greg Strong wrote on 2019-05-23 UTC

How about this? I changed Bowman to Tower, which is probably a little better. It is unfortunate that I cannot find a historical precident. It seems like this is an obvious piece that would have been used log ago but apparently not. For the Nutty Knights, We have Charging Rook, Charging Knight, and Colonel all beginning with C. The Charging Rook can be R. The Charging Knight could be N, but then what about Narrow Knight? I think Jockey sounds like a reasonable choice for the Charging Knight (a piece that moves partly like a horse and partly like a man) and J is unused. Leaving us with:

Colorbound Clobberers
Archbishop Archbishop A
Bede Cleric C
FAD War Elephant E
Waffle Phoenix X
Remarkable Rookies
Chancellor Chancellor C
Short Rook Short Rook S
Lion Lion L
Woody Rook Tower T
Nutty Knights
Colonel Colonel C
Charging Rook Charging Rook R
Charging Knight Charging Knight N
Fibnif Lancer L

I'm also open to something other than Narrow Knight if we can come up with a GOOD name that makes sense. Although, if we did that, that would free up N for Charging Knight, which would have the advantage of not reassigning names to those pieces that Betza already fixed. I suppose that the Fibnif could be Jockey since it also has horse-moves and man-moves, although not as obviously as the Charging Knight.


Game tree complexity[Subject Thread] [Add Response]
Aurelian Florea wrote on 2019-05-23 UTC

As, from what I remember, the article says considering all possible games is meaningless. So what people usually do is get statistics for the average branching factor and the length of the game. With a program like chessV you can do this. Take grand chess for example. Run 1000 games in decent conditions. Say 4mins +3 secs time. Read the data. You probably need help here but I think it can be set up. Same with Omega chess or Shako (one of your favorites I remeber) for a few more known games.

It seems to me though that you aim for the more theoretical rather than applied part of math. There might be relevant conclusions to be drawn from things like number of captures and so on as long as games are chesslike enough.  

For some games like go or havannah the game lenght is quite obvios based just on board size.

When the time I'll maybe try to deduce some such heuristics on games, I'll try on Apothecary as the final article on them is pending on my to do list along with chessV2 expeiments which I hope to be able to do soon!...


Kevin Pacey wrote on 2019-05-22 UTC

Today I was looking at the wiki re: the mathemematical concept of Game Complexity, which led to the following sub-link on Game-tree Complexity, that gave me food for thought about CVs that might one day compete in terms of popularity with such well known games as Chess (which arguably is slowly being played out at elite level, in terms of opening theory):

https://en.wikipedia.org/wiki/Game_complexity#Game-tree_complexity

If the mathematically inclined on this CVP website are interested, perhaps there might be a way to evaluate the Game-tree Complexity of various CVs on CVP, and even slowly compile a list of those CVs with very large Game-tree Complexity number estimated for them; thus such CVs, if they ever become popular, might have a longer lifespan than e.g. Chess, and part of popularizing such CVs could be pointing out their great Game-tree Complexity number (as estimated).

Just as an example, here's a link to a 10x10 CV of my own invention:

https://www.chessvariants.com/rules/sac-chess

I'm not mathematically inclined, but I'd guess that the branching factor for Sac Chess (based on the Chess and Sac Chess armies operating at maximum centralized power for each piece in each game's setup) would be 2 to 3 times higher than for Chess on average, and I'd also guess that the average game of Sac Chess (especially for well-played games) would be about 2 to 3 times more than for Chess in terms of number of ply (a piece is traded in Chess about every 10 ply, I've read long ago, so a game of Chess [or possibly Sac Chess?!] would thus be over on average with a total of 32-2x(70/10)=18 units left on the board), and thus Sac Chess' Game-tree Complexity may be ((35 [=avg. # moves in chess] x2.5) to the power of 70 [=avg. # ply in a game of chess] x2.5, if I understand the Game tree Complexity estimate formula right) which may well easily exceed that of e.g. the game of Go - see the chart given further below in the sub-link on Game-tree Complexity that I first gave. Note that in played Sac Chess games I've looked so far, it seems a pair of pieces are traded about every 8 ply (rather than every 10 ply, as in Chess) on average, but this is based only on a small observation.


Chess variant engines and CECP (XBoard) protocol[Subject Thread] [Add Response]
Greg Strong wrote on 2019-05-22 UTC

Excellent.  I'm glad you're on board.  And I did, indeed, use X for the Phoenix.  I think I used S for Short Rook also if memory serves.  I have to head to work so I don't have time go into too much detail about what I chose and why right now.  My goal was to not invent names myself any more than absolutely necessary - I used existing naming wherever I could find one.

Funny you mention "an important cleric" for the BD.  The name I have been using is "Cleric".  This is a case where I was not aware of any existing name and Cleric was a nice medieval name that hadn't been used.  For FAD I used "War Elephant" - the piece is an elephant crossed with a dabbabah (war machine.)  I didn't invent that, but I don't remember exactly from where it came.  I think Joe Joyce may have come up with that originally.  The Fibnif, I used "Narrow Knight".  This just seemed obvious and similar to Charging Rook and Charging Knight, who's names I didn't feel needed changing.  The HFD is the "Lion".  This was originaly used by David Paulowich in his games and I followed his lead in my games (Opulent Chess and Hubbub.) This is one of my favorite variant pieces.  Yes, the Lion has a different meaning in Chu Shogi, but that piece is pretty different and wasn't really used in conventional chess variants.  You have since used it in Elven Chess with a different name, but that was long after.  David used this name about 15 years ago.  Then there's the BD.  I have been using "Bowman" but I was never all that happy with this one.  It came from Compton Medieval Chess, which was the only existing use of the piece I could find, but this game is extrememly obscure and the name didn't really seem to match the piece.  Tower is probably a better name and I'm happy to change.


H. G. Muller wrote on 2019-05-22 UTC

But I'm not sure what the "correct" notations would be anyway.  I have assigned letters already but you probably won't like them.  I abandoned Betza's terrible, horrible, absolutely no good names at least a decade ago, using alternatives when they already existed. 

I completely agree. I am all in for renaming them, but I do think it is important we do it in the same way. 'Phoenix' is great, but what ID do you use, as the P is already taken? I would use 'X', as that is otherwise in little demand. 'Short Rook' (S) for the R4 would also be an obvious choice. I always liked the name 'Tower' for Rookish pieces (as there is also little pressure on T), but am not sure whether that would best fit the WD or the Charging Rook. 'Lighthouse' would also be a suitable name for an augmented Rook. 'Duck' for the HFD seems as good a name as any. Fairy-Max used 'Unicorn' for the Charging Knight, but this has already a Grant Acedrex meaning. How about 'Jockey' for a Horse/Man-like piece (other than the KN Centaur)? The Bede should probably have the name of some sort of (rather important) cleric. How about 'Ayatollah'? The FAD gives the impression of nervously jumping around, but the name Squirrel is already taken. It can be seen as an augmented Modern Elephant, but that seems a misnomer for a jumping piece in the first place. 'Kangaroo' would be fitting, but has occasionally been used for several other pieces.


Greg Strong wrote on 2019-05-21 UTC

I now managed to have KingSlayer play some CwDA games against Fairy-Max, which it eventually could do without illegal-move complaints (and even win some). This is just the basics (move generator and check test); the material table is not implemented yet. The non-standard a-side castling of the Clobberers works, though.

Nice.  That's progress :)

I currently programmed names like "fide~nutters~(cwda)" (all lower case; the space existing WinBoard versions reserve for these names in the New Variant dialog is rather small, and capitals take more space). This we obviously have to sync between ChessV, Quaddrox and KingSlayer, and then I will adapt the names in Fairy-Max' ini file likewise.

That's fine.  I will present the formal names to the user so it doesn't matter much to me what is sent to the engine in the backgrond.  I will synch to whatever you settle on.

The other issue is the piece IDs. I currently use the same as Fairy-Max already used. These are not very satisfactory, though; many were picked to match the piece symbol I picked to represent the piece in WinBoard (e.g. U for Charging Knight because I displayed it as a Unicorn, E for Waffle because I displayed it as an Elephant). They make no sense in a GUI that would use a less fanciful representation.

Yeah, there is that too.  But I'm not sure what the "correct" notations would be anyway.  I have assigned letters already but you probably won't like them.  I abandoned Betza's terrible, horrible, absolutely no good names at least a decade ago, using alternatives when they already existed.  The Waffle?  For real?  People will not take seriously a game with a piece called the Waffle...  And that piece is already know by the far more satisfactory "Phoenix".  Betza had already started fixing the names - the "Furhrurlbakking" becoming the Colonel for example.  Too bad he disappeared before he finished.

I patched it to allow use of the formerly unused type code 7. So that could be its own pieces plus the opponent's super-piece. But then under-promotion to an opponent piece will always be impossible.

This is not ideal, but is probably not all that big a deal.  How often will any engine pick something other than the two super-pieces?  I would think pretty rare, and then 50% of the time it will still pick one of its own lesser pieces.


H. G. Muller wrote on 2019-05-21 UTC

I now managed to have KingSlayer play some CwDA games against Fairy-Max, which it eventually could do without illegal-move complaints (and even win some). This is just the basics (move generator and check test); the material table is not implemented yet. The non-standard a-side castling of the Clobberers works, though. No bent or ski-sliders yet, so also no Dragons Army.

This already touched on some compatibility issues. Like Fairy-Max KingSlayer now supports two methods for variant selection: in variant 'fairy' the armies are decided based on White Army / Black Army engine options. This is compatible with Fairy-Max, which has a single engine option to select a pair of armies, but the options have to be set by hand anyway, and mean nothing to WinBoard. The other method is through the variant names, but the names are incompatible with those in use by Fairy-Max; I currently programmed names like "fide~nutters~(cwda)" (all lower case; the space existing WinBoard versions reserve for these names in the New Variant dialog is rather small, and capitals take more space). This we obviously have to sync between ChessV, Quaddrox and KingSlayer, and then I will adapt the names in Fairy-Max' ini file likewise.

The other issue is the piece IDs. I currently use the same as Fairy-Max already used. These are not very satisfactory, though; many were picked to match the piece symbol I picked to represent the piece in WinBoard (e.g. U for Charging Knight because I displayed it as a Unicorn, E for Waffle because I displayed it as an Elephant). They make no sense in a GUI that would use a less fanciful representation.

Promotion to an opponent piece will always be somewhat problematic in KingSlayer, as it can only support 7 piece types per army (including Pawn and King), now that I patched it to allow use of the formerly unused type code 7. So that could be its own pieces plus the opponent's super-piece. But then under-promotion to an opponent piece will always be impossible. This is not very important for the purpose I wanted to use it for, but it makes it a somewhat incomplete implementation of the official rules. Things could be stretched a bit further by dynamically assigning the piece type during the game. But that would not remove all limitations, and add a lot of cumbersome code for something that would be almost entirely hypothetical.

I also discovered a problem in WinBoard: it does not relay castling rights in a FEN when the corner piece is not a Rook. This never hurt Fairy-Max, as this relies on the 'edit' command rather than 'setboard', which does not relay any info on castling rights. So Fairy-Max would reconstruct these just based on the corner piece being the one from the initial setup. KingSlayer takes the rights in the FEN seriously, though, and in an engine-engine game the initial setup specified by the first engine would be loaded in the second engine, which then would lose its castling rights. (With external configuration of the initial position both engines would lose these rights, if they rely on 'setboard'.) There is a WinBoard command-line option that can force the castling field to a desired value, though (to force compatibility with the broken Arena Chess960 FEN), so I suppose that would be a work-around. Obviously I have to fix this in WinBoard.

 


A could be interesting result about picket like limited sliders on a at least 12x12 board[Subject Thread] [Add Response]
Aurelian Florea wrote on 2019-05-21 UTC

@HG

Bug found!

I was adding a bishop ray twice!... Shame on me for not noticing!...

I guess this is how people sometimes find "faster than light" objects.


25 comments displayed

Later Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.