[ 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 ]Comments by H. G. MullerLater ⇩Reverse Order⇧ Earlier⇩ Earliest⇧ Apothecary Chess-Classic. Large board variant obtained through tinkering with known games.[All Comments] [Add Comment or Rating]H. G. Muller wrote on 2020-03-26 UTCIndeed, if there is a diagonal path from Joker to King, Bishops and Queens would be pinned. If there is a diagonal path of a black Joker to f1 (say from d3), I would not think that this would forbid O-O, because it also doesn't forbid Kf1, The tricky question is what to do when the Joker has a diagonal path do e1 (say from c3). Can white castle now, or is he in check, and consequently cannot? This again depends on how one imagines the Joker to move after a turn pass. And if he keeps his old move in that case, it depends on the previously moved piece. H. G. Muller wrote on 2020-03-26 UTC But that's not true of other pieces. Other pieces retain checking power during the opponent's move. That is exactly what I disagre with. Checking power is defined as the ability to make an actual capture after the opponent passes his turn (thus giving the turn back to the owner of the checking piece). So the question is really how the Joker must move after a turn pass, because such a turn pass cannot be assigned to any particular piece. Must it then also pass its turn, or does it retain the powers it had on the move before? This question is important to distinguish checkmate from stalemate. For 'passing through check' turn passing plays no role, though. The King was already moving when it reached the square it aims to pass through. The logical approach is to evaluate the situation under the fiction that he would stop there, and then the last move would have been a King move. So I would say the Joker has to be assumed to move as a King in order to judge whether the King passed through its attack. Even when the ultimate rule for Joker movement after a complete castling would be that it should move like a Rook. (E.g. because castling according to FIDE rules must first move the King, and then the Rook, so the Rook would be the last moved piece.) H. G. Muller wrote on 2020-03-25 UTCI would say the borrowed power of the Joker ends after the player owning the Joker moved it, or moved something else. Because then it is no longer that players turn, and a Joker is not allowed to move in the opponent's turn. So during the opponent's turn it has no powers at all. H. G. Muller wrote on 2020-03-25 UTCI always like the 'not castling through check' rule as a form of e.p. capture: the King makes a double step, and can then be taken by a capture-capable move to the square it passed through in the subsequent move. As exposing your King to capture is illegal, such a castling would be illegal. In this interpretation it would be legal to castle over a square that was diagonally attacked by the Joker from a distance, as after the castling that Joker would no longer move like a Bishop, and thus not be able to execute the e.p. capture of the King. I am not sure how the Joker moves after castling: as a Rook, as a King, both or neither. The rules would have to specify that. If it would move as a King, then a black Joker on e2 would make white castling illegal, as that Joker could in the reply become a King and attack f1/d1. Basically the rule would become: the King cannot pass a square during castling that it could not legally move to. It is always a tricky question whether a Joker can deliver check. In most positions this is not important, as most moves would alter the Joker's capabilities in a way that resolved the check. But it can be important to distinguish checkmate from stalemate. Basically the question boils down to how the Joker would move after a turn pass of the opponent, because the 'in-check' definition involves the fiction of a turn pass. Must it also pass a turn, or will it just keep the move it had on the turn before? In the former case the position w:Ke3, Je2 b:Ke1 would be a stalemate, in the latter case it might be a checkmate (if white black moved Ke1 on the move before). Game Courier Developer's Guide. Learn how to design and program Chess variants for Game Courier.[All Comments] [Add Comment or Rating]H. G. Muller wrote on 2020-03-14 UTCAh yes, you are right! In fact this is what Jocly uses, in Wildebeest Chess. That is for free castling, but it would be equally suitable for fast castling. H. G. Muller wrote on 2020-03-13 UTCIndeed, this is how it should normally work. Notation should be unique. But if this mechanism is used as a kludge to indicate a move has a possible side effect, you could leave the squares swapped in the notation to indicate that side effect. H. G. Muller wrote on 2020-03-13 UTCJust an idea: some chess GUIs allow 'reverse' entry of moves, by first clicking the destination square, and then the piece that should go there. (Usually in combination with some 'auto-complete' mode, where the move is executed immediately if only a single piece could reach the clicked empty square, and pieces that you click move immediately if there is only one place they could go.) If you would in general allow the origin and destination of a move to be swapped, the difference could in exceptional cases (such as fast castling) be given a special meaning. Such as the reverse order (empty square x King) would indicate the castling, and move the Rook as a side effect. Wa Shogi. Game with many different rather weak pieces, with or without drops. (11x11, Cells: 121) [All Comments] [Add Comment or Rating]H. G. Muller wrote on 2020-03-09 UTCUghh, this was a case of a >= that should have been a > in the Diagram script. The algorithm is that the promoOffset is added to promotable pieces (all types from 1 up to and including maxPromote) to get the promoted type. When this gets larger than the number of defined pieces, it is replaced by the promoted type of the first piece. The latter was introduced to not explicitly have to define all the Golds that result from promotion of a host of different Maka Dai Dai Shogi or Thai Shogi pieces; if the first piece is a Pawn, and promotes to Tokin, all pieces that also promote to Tokin can then be put last amongst the set of promotable pieces. After that can follow the unpromotable pieces, and then all the promoted types that are explicitly defined. So if (say) maxPromote=10, and promoOffset=15, piece 1 will promote to piece 16, pieces 11-15 will be unpromotable. Piece 16 and higher are the promoted types. But if only six are defined (16-21), these will be the promoted versions of 1-6, and 7-10 will all promote the same as 1, to 16. I fixed it now, thanks for reporting. Match between Fairy Max and ChessV[Subject Thread] [Add Response]H. G. Muller wrote on 2020-03-04 UTCI think the real problem is that the ChessV.Engine.exe is defective; see my posting in the ChessV comments. Note that Fairy-Max calls this game 'frog' only because the user configured it this way; Frog Chess is neither pre-cofigured in Fairy-Max, nor an XBoard standard variant. It would be just as easy to make Fairy-Max use the name that ChessV uses. I am not sure it is 'unfortunate' that XBoard protocol only defines a very limited list of standard variants. The problem is that such a list, no matter how long you make it, will never be (or stay) complete anyway. To be future-proof, any name should be allowed. This means the names are not really part of the protocol anymore than the names of chess engines are; they are just data, and the protocol prescribes only what commands should be used to communicate them. IMO the list of standard variants is already way too long; many variants in the list have no special properties, and only differ from each other (or from orthodox Chess) through board size, array, and piece moves. And the latter properties have basically become freely specifiable parameters for 'engine-defined variants'. So variants like Capablanca Chess, CRC, Great Shatranj really have become redundant, and are maintained only to deal with 'legacy engines'. Because the latter would not reply to the 'variant' command that selected them with a 'setup' command for specifying the array and board size. The concept of engine-defined variants does raise the problem of name standardization, though. Which becomes more than a cosmetic problem when we want to play engines against each other. Perhaps GUIs should already provide a work-around for cases where engines disagree on the name of a variant they both play, like a per-engine 'alias list' of variant names. Which the GUI then should apply (in either direction) on both variant names received from the engine and sent to the engine. Betza Notation. A primer on the leading shorthand for describing variant piece moves.[All Comments] [Add Comment or Rating]H. G. Muller wrote on 2020-03-02 UTCI don't know. Divergence is rare, friendly capture even rarer. If the latter occurs at all, I would expect it to be as a special rule that captures in general can also take friendly pieces. I.e. that d would imply cd, and on all pieces except Pawns even mcd. In that case the only possible confusion would be between mcd and cd in a move diagram. We could use a blue circle for mcd, but the diagram also has a mode to use background colors for highlighting, and what to do there? Lighter blue, perhaps? Using the same shape marker with another color is bad practice to begin with, as the markers were intended for use of pure black & white displays (e-readers and such). I am not very keen on preparing for stuff that might never be encountered, such as divergent pieces that capture enemies in a different way from capturing friends. BTW, when I fixed the hover thing, I also added hover squares for squares where lame leapers can be blocked (i.e. non-final m-only legs), so that hovering over them would place a blocker, and make the moves passing over it disappear (like it would make hopper moves over it appear). I am not sure whether that was a good idea; perhaps I should use anothe color / symbol for such squares. H. G. Muller wrote on 2020-03-02 UTCOK, I sort of fixed this too. To show the move diagram the move generator must be run in a special mode. Normally (i.e. when playing moves on the board) it would just indicate the pseudo-legal moves. But running t on an empty board for the purpose of displaying a move diagram would then omit all captures. So in this mode it applies extra highlights on empty squares, to indicate what could happen there if it was occupied. In particular red or yellow highlights when enemy pieces could be captured there. (And it also indicates 'virtual' hopper mounts / locust victims on the end-point of non-final legs.) But the highlighting for the 'destroy' mode (capture friend) is not really well developed. There are 7 possible non-empty combinations of mcd, and mc (yellow), m (green) and c (red) have their own color. There are no distinct colors for d, md, cd and mcd, though, there only is blue. Considering that I haven't really encountered any variant where friendly capture is possible, it seems wasted effort to elaborate very much on this. The problem is compounded by the fact that the highlighting for entering moves is not completely consistent: on empty squares it distinguishes mc (yellow) and m (green), even though capture is never possible there for lack of anything to capture. But actual captures are always highlighted in red, without distinction between mc and c. So when an mcd move hits an opponent, should I highlight in red, to indicate it is a capture, or in blue, to indicate that a friendly capture would also have been possible on that square? Match between Fairy Max and ChessV[Subject Thread] [Add Response]H. G. Muller wrote on 2020-03-01 UTCWell, for one the spaces are missing behind the # and & in the piece-descriptions for WinBoard, which probably leads to WinBoard ignoring them altogether. Which is just as well, as HH and WH are not the Betza notations for the moves of the Hannibal and Waffle: you defined the Hannibal for WinBoard as a Trebuchet-rider. But for Fairy-Max you defined it as a Modern Elephant, which has no moves in common. But even when ignoring the piece definitions, WinBoard will revert to the default move of the piece, which for the Elephant that you use in all cases will be the Alfil move. The F moves of the Hannibal and the W moves of the Waffle will then be rejected by WinBoard as illegal, when Fairy-Max plays them. And Fairy-Max can recognize checkmates where WinBoard still sees a possibility for the King to escape, to a square that the Hannibal or Waffle attack without WinBoard being aware of it. And then WinBoard would judge the mate claim by Fairy-Max illegal. ChessV. Missing description[All Comments] [Add Comment or Rating]H. G. Muller wrote on 2020-02-29 UTCI am sad to say that there still seems to be a problem with the ChessV.Engine.exe WinBoard engine, which I failed to catch and report before, even though I should have realized something was amiss by the long time it took to load ChessV. When I run this engine from the command line, it nicely prints "feature done=1" at the end of a long list of features (ending with the variants feature), in response to "protover 2". But when I run it under WinBoard it does not do that. So that WinBoard, after a timeout (which fortunately occurs after 10 sec, as ChessV did not start with feature done=0), WinBoard qualifies it as a WB v1 engine, which apparently sets the variants list to just the current variant, 'normal'. (This is arguably a WinBoard bug, but it was a hack to make WB v1 engines dedicated to a specific variant, such as TSCP-G work.) This doesn't seem just a failure to flush the feature done=1 when running under a GUI; in the WinBoard debug log the "feature done=1" never appears, but after sending the engine a move, before it starts thinking, it resends the option definition for "Weakening" instead. Btw, the syntax of that option definition is wrong (which causes it to be rejected by WinBoard): the closing quote should be at the very end, not immediately after the option name, like feature option="Weakening -slider 0 0 15" [Edit] And from the command line it doesn't seem to respond to the 'quit' command. Match between Fairy Max and ChessV[Subject Thread] [Add Response]H. G. Muller wrote on 2020-02-29 UTCFor 'engine-defined variants', the definition in the fmax.ini file should also specify a 'pieceToCharTable' (to indicate which images should be used for what piece) and a 'parent variant' (normally 'fairy', unless there are some special rules that you want to borrow from another variant, such as a wider promotion zone, or the possibility to gate pieces). They go on the 'Game:' line, after the name of the variant, separated by #, like Game: frog # PNBRQ.FKpnbrq.fk # fairy if you want to depict the Frog as an elephant (because the F is in the 7th place of the pieceToCharTable, and WinBoard's 7th piece image is an elephant). The last piece mentioned for each color will always use the King symbol. It will also be helpful to make Fairy-Max inform WinBoard on how the Frog moves, so that you will be able to play the games with legality testing on. To this end you should append the following two lines to the game definition: # # F& FH This will make Fairy-Max emit a 'piece' command at the start of the game for F (the '&' indicating it applies to F of both colors), to indicate it moves as a (Betza) FH. (The other pieces move as WinBoard would expect a piece with that image to move, so there is no need to (re)define their moves.) Unfortunately Fairy-Max is not smart enough to construct the Betza notation that XBoard needs from the move definition as it was given on the 'f:' line. I still hope that I can make some future version of Fairy-Max work entirely from Betza move definitions in the fmax.ini file, rather than from the list of step vectors and primary/secondary move rights it uses now. Betza Notation. A primer on the leading shorthand for describing variant piece moves.[All Comments] [Add Comment or Rating]H. G. Muller wrote on 2020-02-27 UTCIndeed, its absence is unintended. When we split the mc leg into mNmafsWcafsW it does work as intended, so the presence of both m and c on the same leg seems to confuse it. I will have a look at the script, to see if it is just a matter of more carefully recognizing the condition that has to add the pawn on hover, or whether the Betza parser should already split up such move in the internal representation. [Edit] OK, I fixed it. It was not only that the hover did not work, but the W squares were not indicated at all as (locust) capture targets in the primary move diagram. Turned out the code for indicating those was in a branch that only treated cases where there were no m rights. Now I also test for locust captures on non-final legs with m rights, and that automatically makes the hover work as well. Grasshopper Chess. Each player has eight additional grasshoppers.[All Comments] [Add Comment or Rating]H. G. Muller wrote on 2020-02-19 UTCAh OK. I overlooked that. So drawdiagram + arguments is as good as a fixed image, and Cloudfare will carry most of the burden for supplying it. There still could be some concern as to whether Cloudfare would cache unique images of an entire board long enough for the caching to be actually helpful, while individual pieces of the various sets would be requested so often that they would never leave the Cloudfare cache. Broken ranks is of course awful, and it is good you fix that. But it should be possible to produce good-looking board images from individual piece images through HTML tables (this is what the Interactive Diagram does), so I wondered if it would not have been better (for the server load) to fix it that way. H. G. Muller wrote on 2020-02-19 UTCNow I am confused. I thought you exempted PHP scripts from caching by Cloudfare, through one of the rules. I don't see how it could be otherwise. PHP scripts are running on the server, not in the client. Surely Cloudfare is not running PHP for us? That would be a much heavier task than just caching the output these generate. (And how would it get the scripts? Normally scripts should not be loadable from other machines, just their output.) Diagram Designer. Lets you display diagrams without uploading any graphics.[All Comments] [Add Comment or Rating]H. G. Muller wrote on 2020-02-19 UTCThe 'diagram designer' was not made by me, but by Fergus. I am only responsible for the 'Interactive Diagram'. Because you explicitly address me, I will answer for the latter: It is certainly not possible in the Interactive Diagram to use other board topologies, such as hexagonal bords, or circularly deformed boards. All boards must consist of a corner-connected grid of squares. Irregular shapes of such boards (such as e.g. in Omega Chess, with its wizzard squares, or the citadel of Tamerlane Chess) can be emulated by declaring some squares in the smallest surrounding rectangle to be inaccessible 'holes'. The Design Wizard in the Interactive Diagram article has no provisions for defining those, though. But you can just edit the HTML code that it delivers to add the holes; you only need to define an extra 'piece' with the name 'hole', followed by a list of squares that should be holes. Grasshopper Chess. Each player has eight additional grasshoppers.[All Comments] [Add Comment or Rating]H. G. Muller wrote on 2020-02-19 UTCYou do realize that this drives up the bandwidth it requires to download the page, and increases the server load? Browsers would display a table of individual piece images without any further server access, once the complete Alfaerie set is in their browser cache. And the most commonly used pieces certainly would be, from visiting other pages on this site. Perhaps a rare piece (such as the Grasshopper) would have to requested once (from Cloudfare!), and then the user would have that cached too. A monolythic image of the entire position would be unique for every article though, and have to be downladed. Using a PHP script to generate the image 'on the fly' means it cannot even be cached by Cloudfare. ChessV. Missing description[All Comments] [Add Comment or Rating]H. G. Muller wrote on 2020-02-16 UTCWell, while you are at it, could you also check out why the engine version prints such strange values for the time in CECP Thinking Output? That must be pretty trivial to fix. H. G. Muller wrote on 2020-02-16 UTCI presented the position to ChessV 2.2RC1, and after 5 min (the time it reports itself is bogus!) it produced a move at 32 ply: dep score nodes time (not shown: tbhits knps seldep) 32 +169.59 106.2M 8:50:53 f2f3 f5e5 d4d1 e5e6 f3f4 e6f6 d1e1 f6g6 f4g4 g6f6 g4f3 31 +169.59 45.1M 3:35:35 f2e3 f5f6 e3e4 f6g5 d4d3 30 +169.58 28.1M 2:11:14 f2e3 f5e5 d4d3 e5f5 e3d4 f5f6 d4e4 f6e6 d3d5 29 +169.55 19.1M 1:25:46 f2e3 f5e5 d4d1 e5f5 d1d5 f5f6 e3e4 f6e6 d5d2 e6f6 d2a2 f6e7 e4e5 e7d7 e5d5 d7e7 a2a5 e7f7 a5a3 f7f8 a3a7 f8g8 d5d6 g8f8 a7b7 f8g8 28 +169.55 15.9M 1:08:52 f2e3 f5e5 d4d1 e5f5 d1d5 f5f6 e3e4 f6e6 d5d2 e6f6 27 +169.55 13.3M 56:28.33 f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f6 d1d6 f6e7 f4e5 e7f7 e5e4 f7e7 26 +169.55 11.1M 46:51.12 f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f6 d1d6 f6e7 f4e5 e7f7 e5e4 f7e7 25 +169.55 8.86M 37:24.84 f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f6 d1d6 f6e7 f4e5 e7f7 e5e4 f7e7 24 +169.55 6.49M 27:22.68 f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f6 d1d6 f6e7 f4e5 e7f7 e5e4 f7e7 e4d5 e7f8 d6e6 f8f7 e6e1 f7f8 23 +169.55 5.23M 22:09.12 f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f7 f4f5 f7e7 d1d2 e7f7 d2d8 f7e7 d8d5 e7f8 f5e5 f8f7 22 +169.55 3.91M 16:38.40 f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f7 f4f5 f7e7 d1d2 e7f7 d2d8 f7e7 d8d5 e7f8 f5e5 f8f7 21 +169.55 2.79M 12:06.96 f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f7 f4f5 f7e7 d1d2 e7f7 d2d8 f7e7 d8d5 e7f8 20 +169.55 2.39M 10:25.56 f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f7 f4f5 f7e7 d1d2 e7f8 d2d8 f8f7 d8d5 f7e7 d5d3 e7f8 d3d6 f8f7 d6e6 19 +57.24 1.85M 8:09.84 f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f7 f4f5 f7e7 d1d2 18 +169.56 1.42M 6:22.20 f2e3 17 +169.56 1.13M 5:12.00 f2e3 16 +169.56 895583 4:14.28 f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f7 f4f5 f7e7 d1d2 e7f8 d2d8 f8f7 d8d5 f7e7 d5d3 15 +57.24 696806 3:22.80 f2e3 f5e5 d4d2 e5f6 e3e4 f6e6 d2d5 e6f7 e4f5 f7e7 d5d3 14 +57.04 435297 2:11.04 f2f3 f5e5 f3e3 e5f6 e3f4 f6e6 d4d3 e6e7 f4f5 e7f7 d3d7 f7e8 f5e6 e8f8 e6d6 13 +56.96 285881 1:27.36 f2f3 f5e5 d4d3 e5f6 f3f4 f6e6 d3d4 e6e7 f4e5 e7f7 e5f5 f7e7 d4d5 12 +56.88 187028 0:57.72 f2e3 f5e5 d4d3 e5f6 e3e4 f6e6 e4f4 e6e7 f4e5 e7f7 d3d7 f7g6 e5f4 11 +56.80 115957 0:34.32 f2f3 f5e5 f3e3 e5f6 e3e4 f6e6 d4d5 e6e7 e4e5 e7e8 e5e6 10 +56.72 68603 0:20.28 f2f3 f5e5 f3e3 e5f6 e3e4 f6e6 e4f4 e6e7 f4e5 e7e8 9 +56.72 39705 0:12.48 f2f3 f5e5 f3e3 e5f6 e3e4 f6e6 e4f4 e6e7 f4e5 8 +56.64 23739 0:07.80 f2f3 f5e5 f3e3 e5f6 e3e4 f6e6 d4c4 e6d6 7 +56.64 12952 0:04.68 f2f3 f5e5 f3e3 e5f6 e3e4 f6e6 d4c4 6 +56.64 5601 0:03.12 f2f3 f5e5 f3e3 e5e6 e3e4 e6e7 5 +56.64 2579 0:01.56 f2f3 f5e5 f3e3 e5e6 e3e4 4 +56.52 1034 0:01.56 f2f3 f5e5 f3e3 e5e6 3 +56.56 418 0:01.56 f2f3 f5e5 f3e3 2 +56.52 121 0:01.56 f2f3 f5e6 1 +56.64 28 0:01.56 f2f3 0 # So like micro-Max it finds a mate score pretty fast; difference is that it seems to be that the pretty slow over-the-horizon mate it finds first isn't improved as much as the depth goes up. Still it is strange that it wouldn't simply play out the mating line it found, and is now in its TT, in the following moves. [Edit] Umm, I might misinterpret the 169.xx scores as mate scores: when I let ChessV play out this position against itself there do appear standard mate scores at the end. Strange thing is that after the black engine admits to being 'mated-in-1' is its last move, the white engine crashes without performing the checkmate. H. G. Muller wrote on 2020-02-16 UTCIt could be that the new condition just makes hash cuts so rare that the damage they do is not apparent. And can you still solve Fine #70 with this new condition? Some of these end-games are really difficult (like KBNK), but KRK is not amongst those. If the start position is not extremely unfavorable (like the shown mate-in-12 rather than the worst-case mate-in-16), a fresh search should show you a mate score after a few seconds. Once there is a mate score, it should just start playing from the mating line that is now in the TT. Just walking the winning King to the center should already be enough to get better than mate-in-12. How long does it take ChessV to get a mate score from the given KRK position, and what depth does it reach? Not being able to act out an already found mate would point to entirely different problems than not finding the mate in the first place. H. G. Muller wrote on 2020-02-15 UTCThis is very strange. Why do you need custom evaluation for KRK in the first place? Fairy-Max had absolutely no trouble to win KRK on its normal evaluation. (Which has Rooks completely neutral, and use the parabolic centralization table for Kings.) In the latest Fairy-Max version I use what you could call custom evaluation for checkmating a bare King (it just multiplies the centralization bonus for that King by a large factor), but that was only needed for end-games with many centralizing pieces (such as KFFFK in Makruk), because these did not bother to leave the center just for driving a single piece into a corner. Checkmating with Rook is very easy on any size board; you almost need no search depth for it at all. You just shephard the King towards the corner with your Rook, keeping the latter protected from behind by your King. I suppose you do switch off null move? The only thing I can think of that causes what you describe is contamination of the hash score with draw scores resulting from repetitions. What happens when you disable repetition detection (accepting PV hash cutoffs)? I don't really understand how a line that makes progress could get draw scores from this, though. Can you post a game of how it typically plays KRK? (Best would of course be one that it bungles.) Here is thinking output from a version of Fairy-Max that doesn't use the special bare-king evaluation, for position 8/8/8/5k2/3R4/8/5K2/8 w - 0 1 : mover viewpoint fewer / Multi-PV margin = 0 / more exclude: none best +tail dep score nodes time (not shown: tbhits knps seldep) 28 #12 121.4M 1:17.65 1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kg5 4. Re5 Kg6 5. Kg4 Kf6 6. Re4 Kg6 7. Rf4 Kh6 8. Kf5 Kg7 9. Kg5 Kh7 10. Kf6 Kh8 11. Kf7 Kh7 12. Rh4 27 #13 61.4M 0:40.03 1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kg5 4. Re6 Kf5 5. Re4 26 #12 46.8M 0:30.38 1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Re4 25 #12 28.3M 0:18.23 1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Re4 24 #12 15.6M 0:09.85 1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Kg3 23 #12 10.3M 0:06.45 1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Re4 22 #13 7.44M 0:04.55 1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Re2 Kg5 5. Re5 21 #14 5.88M 0:03.52 1. Kf3 Ke5 2. Rd3 Kf5 3. Re3 Kg5 4. Re5 Kg6 5. Kg4 Kf6 6. Kf4 20 #18 4.72M 0:02.74 1. Kf3 Ke5 2. Rd1 Ke6 3. Kf4 Kf6 4. Re1 Kg6 5. Re3 Kf6 6. Re5 Kg6 7. Kg4 20 #22 4.50M 0:02.59 1. Ke2 Ke6 2. Kf3 Kf6 20 +4.59 3.68M 0:02.07 1. Ke3 Ke5 2. Rd8 Kf5 3. Re8 Kg5 4. Ke4 Kf6 5. Re5 Kg6 19 +4.57 2.37M 0:01.27 1. Ke3 Ke5 2. Re4 Kd5 3. Kd3 Kc6 4. Kd4 Kd6 5. Re5 Kc6 6. Rd5 Kc7 7. Kc5 Kb7 8. Rd6 Kc7 9. Kd5 Kc8 10. Ke4 18 +4.56 1.54M 0:00.81 1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Rf4 Kg5 5. Kg3 Kh5 6. Rg4 Kh6 7. Rg8 17 +4.55 1.12M 0:00.57 1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Rf4 Kg5 5. Kg3 Kg6 6. Kh4 Kg7 7. Kg5 Kh7 8. Rf7 Kg8 9. Kf6 16 +4.54 729185 0:00.35 1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Rf4 Kg5 5. Kg3 15 +4.54 518699 0:00.25 1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Rf4 Kg5 5. Kg3 14 +4.54 354924 0:00.15 1. Ke3 Ke5 2. Re4 Kd5 3. Kd3 Kd6 4. Kd4 Kc6 5. Re6 Kc7 6. Kd5 Kd7 7. Ke5 13 +4.53 218794 0:00.09 1. Ke3 Ke5 2. Re4 Kd5 3. Kd3 Kd6 4. Kd4 Kc6 5. Re6 Kb5 6. Kd5 Kb4 7. Ke5 12 +4.53 150300 0:00.06 1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg5 4. Rf4 Kg6 5. Kg4 Kh6 6. Kf5 Kh5 11 +4.52 107753 0:00.04 1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Kf4 Kf6 5. Re3 Kg6 6. Ke4 10 +4.50 54436 0:00.01 1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 Kf6 4. Re5 Kg6 5. Ke4 Kf6 9 +4.52 36093 0:00.01 1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 Kf6 4. Re5 Kg6 5. Ke4 8 +4.51 20251 0:00.00 1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 Kf6 4. Re5 Kg6 7 +4.50 9192 0:00.00 1. Ke3 Ke5 2. Re4 Kf5 3. Re8 Kf6 4. Ke4 6 +4.49 5719 0:00.00 1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 Kf6 5 +4.49 2747 0:00.00 1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 4 +4.48 559 0:00.00 1. Ke3 Ke5 2. Re4 Kf5 3 +4.48 223 0:00.00 1. Ke3 Ke5 2. Re4 2 +4.48 23 0:00.00 1. Ke3 Ke5 1 +4.49 13 0:00.00 1. Ke3 Piece Values[Subject Thread] [Add Response]H. G. Muller wrote on 2020-02-14 UTCStrange anomaly I have started an attempt to determine piece values on a 12x12 board, about which very little is known. I use Fairy-Max self-play for this. To not make the games too long, the basic start position I use consists of a FIDE army augmented with 4 Pawns (to close the Pawn rank). So the board is pretty thinly popuated. The 4 central Pawns start on 4th rank, to speed up engagement, but the 3 Pawns in each wing start on 2nd rank, to provide some King shelter. The Knights also start in a somewhat advanced position, on 3rd rank behind the central Pawns, as does the Queen (to not have too many unprotected Pawns in the start position. To determine piece values I delete some pieces from this setup, or sometimes replace them by fairy pieces. The side with the weaker piece can be compensated by giving the opponent Pawn odds, for which I always delete the same Pawn (on the h-file). Such Pawn odds alone results in a 68-70% win of the side with the extra Pawn. I only trust results when the total advantage is closer to equality than Pawn odds. I don't want to delete more than a single Pawn, because Pawns are highly cooperative pieces, and I cannot be sure that deleting two Pawns gives twice the advantage of deleting a single one. By always granting the same simple Pawn advantage (or none at all), I can get a reliable 'measuring stick' on which the values of other pieces can be mapped. This poses a problem if there is a gap of more than 2 Pawns in the 'piece-value spectrum', though: I cannot play those 1-on-1 without getting an imbalance that is too extreme. I solve that by also introducing fairy pieces with values in the gap, and also determine their value. I try to avoid Bishops, (and color-bound pieces in general) because of the pair-bonus problem, which would introduce yet another unknown. Which, if not handled properly by the engine, might invalidate the results. So I tried to find a very 'Bishop-like' piece that is not color bound. My first choice was this: to break the color binding of a Bishop, I gave it Wazir moves. To compensate for that (and prevent mating potential), I take away the Ferz moves. But to not affect the more distant B moves, they can still be blocked on the F squares. (So basically this is a Tamerlane 'Picket' + Wazir.) Such a modified Bishops beats a Knight on 12x12 (as ordinary Bishops also do). The strange thing is that when I then handicap them with Pawn odds, they still beat the Knight, by about the same score. The extra Pawn doesn't seem to help the Knight at all! I have never seen that before; normally deleting a Pawn lowers the score by about as much as the pure Pawn-odds advantage. I watched a few games, and often they end in Knight + Pawns vs modified Bishop + Pawns, where the Knights are still judged by the engine to be ahead (because there are more Pawns on their side). But the Knight then almost always loses. The 'WazirPicket' can easily prevent advance of many isolated Pawns, by guarding a diagonal. And by just stepping in front of a Pawn it attacks as well as blocks it, so that the Pawn easily falls. Even connected passers are easily destroyed this way, if they still have far to go. (And on 12x12 they usually have; I use promotion on last rank only.) I guess the WazirPicket is just unrepresentatively dangerous to Pawns, in the absence of pieces that can protect those. (And Knights are pitifully slow on 12x12...) So that the value of opposing Pawns shrinks to almost nothing in the late end-game. My next attempt at a non-color-bound substitute for a Bishop will only change the mF moves of a Bishop to mW, but leaves the captures in place. This will also have the advantage that it cannot be blocked on a square that it doesn't attack, so that it cannot be blocked with impunity (as lame leapers can). Such a piece cannot do more damage to Pawns than ordinary Bishops can, but the mW move does allow it to switch color on non-captures. (Hence I dubbed it Swishop.) Caching[All Comments] [Add Comment or Rating]H. G. Muller wrote on 2020-02-13 UTCWell, if there are no other contenders for that rule, then it would certainly help me. Or perhaps exempt .js files in general: browsers would typically cache those themselves, so they won't request them even from Cloudfare unless the user would explicitly bypass or flush his browser cache. But why are you so certain that you cannot control Cloudfare through a script on chessvariants.com? I guess you flush files from the Cloudfare cache (or perhaps the entire cache) through a TCP/IP connection. So why not have the submission script open a TCP/IP connection to it, and send the required commands over it? Or do you have to solve some "I am not a robot" puzzle there? 25 comments displayedLater ⇩Reverse Order⇧ Earlier⇩ Earliest⇧Permalink to the exact comments currently displayed.