Ratings & Comments
Ben Reiniger wrote on Tue, Feb 18, 2020 01:11 PM UTC:In the intervening time, we've had submissions from strong community members who do not have their real names displayed on these pages. I (and I think we?) still have a slight preference for real names, for the encyclopedic nature of the site, but there are many sites now where site-famous people are later referred to as "user xyz of site abc," so maybe it's fine.
Another thing that changed in the time since your submission: the Diagram Designer. The use of a period to denote a dot on the board (for movement diagrams) has been deprecated; you can replace them with a pound symbol (#), or a few other options.
Antelope. Makes (3,4)-jump.[All Comments] [Add Comment or Rating]The page still contains the error that this piece moves 4,5
Game Courier Settings Files. Keep track of all the settings files you have written for Game Courier.[All Comments] [Add Comment or Rating]
Expanded Chess. An attempt at a logical expansion of Chess to a 10x10 board.[All Comments] [Add Comment or Rating]Wow, I didn't even see this until now. I'm sorry. In both checkmate and stalemate, the last move is the one that checkmates or traps the other player, so the player who is trapped loses. With insufficient material or repetition, the last player to capture would win. The winning condition was intended as an experiment in defining a drawless chess game. I have no idea if it would actually be more interesting or not than any alternative.
The other thing I'm not sure about is the zebras. Their jump fits with the other pieces but maybe it's too far for a board this small?
If my name is required I can add that
ChessV
. Program for playing numerous Chess variants against your PC.[All Comments] [Add Comment or Rating]📝Greg Strong wrote on Mon, Feb 17, 2020 01:26 AM UTC:Yup, I've tracked that down too. Thanks for pointing it out!
H. G. Muller wrote on Sun, Feb 16, 2020 09:14 PM UTC:Well, 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.
📝Greg Strong wrote on Sun, Feb 16, 2020 08:42 PM UTC:Thank you very much for the help. I think I've gotten to the bottom it. It was tricky because there were several things going on.
I think the main problem was indeed with the TT. Those 169 scores you were seeing were mate positions but those weren't true mate scores. Amateur mistake here ... At some point I increased the value I was using to represent INFINITY (CHECKMATE) and I made the value larger than the number of bits I had reserve in my TT entry for storing the score. So those 169 scores kind of worked - it still prefered them to other things and prefered quicker mate, but other things didn't work. For example, the mate distance pruning didn't trigger because it didn't consider them mate scores. I'm sure there are other places in the code with similar issues.
I found this last night but correcting for it did not solve my problem because I had since introduced a new problem since the release of version 2.2. One of the things I'm doing for 2.3 is streamlining the code for Rules that store state information. Instead of each Rule-derived class handling this itself, I now derive Rules that store state information from a template class RuleWithState. Well, in doing that, I broke the DrawByRepetition rule and that was the reason I was still experiencing draws where there should have been wins.
Since things are still needing work on 2.3 and since this is a pretty major problem, I will release a service pack for version 2.2 today or tomorrow. I will also add the feature for saving the games for games in run in batch mode.
H. G. Muller wrote on Sun, Feb 16, 2020 02:55 PM UTC:I 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 Sun, Feb 16, 2020 05:23 AM UTC:It 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.
📝Greg Strong wrote on Sun, Feb 16, 2020 12:22 AM UTC:Thank you for the help. It is indeed pretty strange.
First, I should clarify a couple of things. The problem isn't specific to KRK - I know it appeared in other situations as well, but KRK was an easily reproduced and extreme example. Also, the special endgame code isn't specific to KRK, it is really KxK (King + plenty of material against bare king, probably the same idea as your bare king eval.) This KxK code comes from Stockfish but adapted to do the right thing on boards of any size. The other specific endgame evals I have so far are KRKP, KRKB, and KRKN (also from Stockfish.) There is also some special handling for KPK which overwrites the eval to return draw scores on certain positions that are known to be draws (this is custom code based on Wikipedia's KPK article - the Stockfish KPK code uses a bitbase which doesn't help me given variably sized boards.)
The null move was a good idea, as well as draw scores getting into the TT, but neither of these seem to be the cause. Null move is disabled with low enough material and disabling draw-by-repetition and/or 50-move rule didn't help.
With a fair amount of expirementation, I found another "solution". If I change the TT cutoff condition at PV nodes from hash depth >= depth remaining to hash depth > depth remaining that solves the problem entirely and my searches seem totally consistent. But I have "solution" in quotes because I'm not 100% sure this addresses the real problem either, but I think it probably does. Somehow something is getting off by one somewhere. I still need to understand it better because the underlying problem may be affecting non-PV nodes too resulting in weaker play that is not so obvious...
H. G. Muller wrote on Sat, Feb 15, 2020 04:59 PM UTC:This 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
📝Greg Strong wrote on Sat, Feb 15, 2020 03:50 PM UTC:@HG:
I had a problem. ChessV sometimes wasn't able to find the mate in KRK (for example), despite the fact that I have a custom endgame eval for this combination (which I'm sure is correct.) I was able to solve this by no longer returning on TT hits on PV nodes. This is an acceptable solution since you seldom get a cut-off on a PV node so it does not speed things up much, if at all, and it reports shorter PVs. But I'd still like to understand the problem in case there is something else wrong.
I only return at a PV node if the TT entry depth >= depth remaining and the entry type is Exact. I also shift mate scores by the ply before returning, as is typically done. Do you have any insight why I might be missing mates and stumbling into draws by repetition or 50-moves? I guess my TT code could have a bug, but I don't think so.
H. G. Muller wrote on Fri, Feb 14, 2020 10:28 AM UTC:Strange 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.)
I set the rule to bypass the cache for https://www.chessvariants.com/membergraphics/MSinteractive-diagrams/betza.js. There might be a way to purge the cache with a script, but I have not studied the Cloudflare API well enough to know how to proceed with that, and I don't know anything about using Curl. I normally just log in to Cloudflare's website and do it manually from there. I have also just increased the caching time from 4 hours to 3 days, so that HTML pages will stay up when the server goes down.
H. G. Muller wrote on Thu, Feb 13, 2020 06:35 PM UTC:Well, 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?
I cannot control Cloudflare through scripts on this site. I have one page rule left. I could use it to disable caching on your script or on the directory it is in.
H. G. Muller wrote on Thu, Feb 13, 2020 05:16 PM UTC:Such a setup breaks the possibility to change any of the articles and their associated uploaded files, as these are not PHP scripts. It makes you entirely dependent on manual intervention, because any update will with certainty be screened from all remote clients. If you want that, notification of the site admin or an editor that such intervention is needed should be automatic; having to post requests through the comments channel clutters the comments with garbage, as is now happening to this article.
Can the submission / upload script not automatically notify an empowered person that action is required, through e-mail or some specific requesting mechanism? It would of course be even better if these scripts would invoke a program that would purge the cached version in Cloudfare automatically.
There are two levels of caching. One is browser caching, and the other is caching at the DNS/CDN level. The latter is handled by Cloudflare, and it reduces the server load quite a lot, which keeps this site quicker and more stable. I am able to control caching through page rules, but my free Cloudflare account gives me only three page rules. I have two rules right now. One disables caching for pages with a .php extension, and the other enables caching for the drawdiagram.php script, which is used for graphics. I can purge the cache for individual pages as needed, but I need to be asked to do that for a particular page. Complaining about caching in general will not help.
Maka Dai Dai Shogi. Pieces promote on capture, some to multi-capturing monsters. (19x19, Cells: 361) [All Comments] [Add Comment or Rating]📝H. G. Muller wrote on Thu, Feb 13, 2020 04:13 PM UTC:I discussed this once with an official of the Japanese Chu Shogi Association, who wanted to revive the interest in Maka Dai Dai Shogi, and had written a manuscript defining the 'modern' rules. He insisted that it would be the last piece captured. And for a Lion Dog he insisted that jumping two squares out to capture something, and then retract one square to capture what you jumped over, was not a legal Lion-Dog move, but that you would always have to capture what is on the adjacent square in the outgoing leg if you wanted to finish there.
It didn't make much sense to me. I would also be happy if you were allowed to choose. Of course this is all highly theoretical; no one would allow both his most-valuable pieces to be in Lion or Lion-Dog range.
H. G. Muller wrote on Thu, Feb 13, 2020 03:34 PM UTC:As far as I am concerned, something is broken when doesn't fully work as it should. But this doesn't seem worth quibbling about, as long as we agree there is an issue.
It is unfortunate enough that the list of comments to the Betza Notation article gets cluttered with messages like this not directly related to the topic, and losing all relevance in a short time.
@Ben:
How do you know it is the browser? It doesn't look like it is the browser to me. In FireFox, when I press Shift during reload, it will always bypass the cache for the files the main document links to (like images or JavaScript code). And the main page will never be cached. But that does not happen here: I access chessvariants.com/membergraphics/MSinteractive-diagrams/betza.js directly (so that the browser should never have cached it), and it still shows the old content. When I load the directory it is in, it gives the file with today's download date, so the correct file must be on the server.
When I append the requested betza.js link with a dummy CGI argument "t=19", to be sure no one can cache, I do see the altered content. But if I then omit it again, it reverts to the old content.
This happens on two browsers (FireFox and Chrome). After I use the Chrome menu to delete all cached files, I still get the old contents. I don't think it are the browsers.
I guess adding a dummy CGI argument that contains a dynamically requested time to the link in the page that refers to betza.js should fix it. But it is crazy that such a work-around would be needed.
[Edit] I added the dummy "?t=19" suffix to the link to betza.js in the Betza Sandbox comment, so that this at least uses the updated version. But it is not really a feasible solution to do that in every page that refers to the file. And when I update again the "?t=19" would be the cached version, and all the suffixes would have to be updated to a value never used before...
Ben Reiniger wrote on Thu, Feb 13, 2020 03:25 PM UTC:...and the overzealous use of caching seems to be the browser, not our site. I don't know what changed, or if there's an easy thing for us to do to override that browser behavior. (On some pages we've been appending dummy unique ids as part of the query in URLs, which fixes the caching but is not ideal.)
If caching on the site were broken, there would be no caching, and all changes would appear immediately. Your issue is that caching is working even when you don't want it to.
Maka Dai Dai Shogi. Pieces promote on capture, some to multi-capturing monsters. (19x19, Cells: 361) [All Comments] [Add Comment or Rating]A. M. DeWitt wrote on Thu, Feb 13, 2020 03:14 PM UTC:If you were to capture both a Deva/Teaching King and a Dark Spirit/Buddhist Spirit with a multi-capturing piece such as a Lion or Lion Dog, which piece would you promote it to? The rules state that the promotions of these pieces are contagious, but do not elaborate on which promotion has priority when a multi-capturing piece captures a Deva/Teaching King and a Dark Spirit/Buddhist Spirit in a single move. See the promotion rules in Taishin Shogi for some possibilities.
Betza Notation. A primer on the leading shorthand for describing variant piece moves.[All Comments] [Add Comment or Rating]H. G. Muller wrote on Thu, Feb 13, 2020 07:52 AM UTC:OK, I can get it too now. It only appears to add the spurious Rook moves in two directions, and only when the mount is on an F square. In fact the piece behaves like a bifurcator, going to the second leg not at the mount, but one step in front of it. It is apparently the yafscpF contribution that does this.
And it seems to be caused by the 'original' use of 'p' in the final leg. When I use 'p' in the new meaning of ending on an occupied square for a non-final leg, as in yafscpafF, everything works fine. Which is surprising, as the Betza parser should convert p to paf on any final leg, on reading the description, so that they really should be the same thing. This is apparently what goes wrong.
This is definitely a bug in the Interactive Diagram code. I will look into it. Thank you for reporting it!
[Edit] OK, I have fixed it. The problem was that the Betza parser turned the old-style 'p' on final legs to a multi leg move, by making it into a non-final leg with 'p' mode, and adding an extra leg for the part of the trajectory after the mount. In the internal representation each leg lists how many legs still follow, so that they can be skipped whenever an earlier leg cannot be completed. The existing parser did not increase this skip count on legs before the leg with the old-style 'p', so that when they were blocked the newly added leg for after the mount was not skipped, but was considered another independent move. So when the first F step in yafscpF could not be made because of a blocker, it would transplant the path that should have come after the mount in the second leg to the piece itself.
I also fixed another problem: finite-range hoppers were not working properly. E.g. pR5 would not be an R5 that had to pass over exactly one obstacle, but would be a pR that could only land on the first 5 squares behind the mount. I think in original Betza notation the range should apply to total range, and changed the code accordingly. Downside is that it is not easily possible now to describe hoppers with a fixed finite range after the hop. (Unless that range is 1, in which case the range-toggling 'g' modifier can be used.) I suppose an 'Extended Grasshopper' that could land (precisely) 2 squares behind its mount can still be described as gafafQ (where gafQ would be an alternative notation for gQ, the normal Grasshopper).
Note that caching on this website is broken, so that you might not be able to benefit from the fixed diagram code I uploaded until the site maintainer takes manual action to make the changes visible!
25 comments displayed
Permalink to the exact comments currently displayed.
My thoughts -
Zebra: The Camel is the more common complement to the Knight. I think a Zebra is OK on a 10x10 board but would be less mobile than the Knight because more moves would be off-board (although a Camel is color-bound so also weaker than a Knight, but I think this is OK because a Bishop is a colorbound piece that could be considered the complement of the Rook.) Also, if you keep the Zebra, I think you should keep the name as-is.
No Draws: I'm not sure how advisible this is. The point of Stalemate is to give the player who is behind something to play for. For repetition and 100-move rule, at a minimum, the written description needs to be clarified. It currently says the "last player to move" wins, but your comment says "last to capture". And for 100-move, do you mean "last to capture or push a pawn"? That would make more sense. And do you mean 100 half-moves, like the Chess 50-move rule? Or do you really mean 100 full moves? I think that would be too much and I don't see any reason to increase it at all. Personally, I'd scrap all of this and leave all the victory/draw conditions as in orthodox Chess, but that is just personal opinion.