Comments by FergusDuniho
The rule is borrowed from Xiangqi, but since that game doesn't include the Immobilizer, appealing to it alone cannot resolve this question. I think the usual rule in Xiangqi is that Generals may not occupy the same file with nothing in between them. But when it comes to programming Xiangqi, the simplest way to code for this is to give each General the power to capture the enemy General as a forward-moving Rook. Since they cannot move into check, this never actually results in one capturing the other, and it functions the same as a ban on occupying the same file with nothing in between.
Since the Immobilizer comes from Ultima, we might look to that game to resolve this question. Can a King occupy a space adjacent to an immobilized King in Ultima? More generally, does an Immobilizer eliminate the checking power of a piece or simply its powers of movement? Our page on Ultima does not address this issue, but Pritchard does in Popular Chess Variants. He writes, "An immobilized king can be mated by its rival moving next to it." Using this as a precedent, it looks like the Immobilizer does eliminate the checking power of a piece, and this would allow an immobilized king to be checked by the enemy King.
However, the one thing that could be said against this interpretation is that Glenn Overby writes in the "Rules of Play":
The King may never be on the same file/column as the enemy King, if there are no pieces of either color in between them.
My point here is that it is being described as a rule of the game, not simply as a description of how the King moves. This rule might be understood to override the ability of the Immobilizer to rob a piece of its checking powers. Ultimately, this may be something for Glenn Overby to rule on.
It's not an earlier version of the same game. Dekle's Hexshogi is an earlier game with a very similar name and concept, but since I was unaware of it when I created this game, it had no influence on its creation, and I didn't think to choose a more distinctive name. Unfortunately, the description in Pritchard's Encyclopedia is too incomplete to tell how it was played.
Having grace time makes things fairer for people who normally move at different times. A day of grace time is good for assuring that differences in personal schedules do not cost some players more time than others. While we should do something to rein in the length of games, some games go on because of several moves. Limiting the total time of the game could unfairly hurt the player whose turn happens to run up against such a time limit. The maxtime value is used to limit the total time a player may have between turns. It does not limit the total time for the game. This could put a cap on how much extratime and bonustime could increase someone's total time. Setting this to 30 days would mean that no player could take more than 30 days between turns. I would suggest setting it to 28 days, which is twice the initial spare time. If we want to be a bit stricter, we could set it to 14 days, which matches the spare time. This would allow someone who is behind on time to gain some back by making moves, but it would not allow anyone to gain more time than the initial 14 days of sparetime.
I'm interested. I was also thinking about going with Metamachy instead of Perfect 12. It seems to be a more recent evolution of Perfect 12. Perfect 12 does not appear in the "Chess Variants on very large boards" section of Cazaux's website, and that section begins with the statement "I consider that these variants are now surpassed by METAMACHY." So, I expect that he favors it over Perfect 12. Although he does not list it in his Favorites section, we have already done Shako as you mentioned, and the other two were for design contests with unusual board sizes. There is already a bare preset for this game, but I could make one that enforces the rules.
Isn't it too early to cancel the tournament from a lack of interest? I haven't even seen a call to sign up for it yet. At present, I have just been waiting for the final lineup of games to take shape.
If you want live tournaments, it will probably be best to let someone other than myself handle it. I have no experience in running live tournaments, I went to maybe one Chess tournament before quitting the Chess club in high school, and I don't travel much. I'm more into the variety of Chess variants than I am into the intense competition of the Chess world.
On comparing the post-game code in the two presets, there are some piece label differences, and in the Post-Move 1 code for the second preset, there is an endif without a semicolon after it.
In the one with the infinite loop, there are complicated piece functions for the G and A pieces, and the N function has some more code in it. One of these functions might be at fault. I would recommend that you get the second one working, then introduce these functions back into the script one at a time and see what happens. I do not think that anything in the post-move code is involved in the infinite loop, since it happens before I have the opportunity to make a move. But to rule that out, you could try deleting the post-move code temporarily to see if it makes a difference.
When I try to use the first preset, it repeats "Please report any bugs or errors to Fergus Duniho" on the screen endlessly. In looking more closely at the code, I see that they are not the same. I guess I was not using the Compare plugin properly. I've tried it again, and this time it is showing differences. But I have not determined what is causing this infinite loop.
When I tried to move a Pawn in the second preset, I got the error "Call to P subroutine got misrouted."
Looking at your code as it is displayed below the error message, I do not see a P subroutine defined anywhere. So, it appears to be calling a subroutine that is not defined in your code. Looking at the code you have written in your pre-game section, you have
commented out. This is the include file that would have the P subroutine defined in it. So, including it should eliminate this error.
include chess3
Returning to the code displayed below the error message, this code is properly indented, and anywhere the indentation seems incorrect, you may find an error. On line 85, you have an endif without a semicolon after it. You have the same error on line 114.
By doing automated comparisons with the Compare plugin for Notepad++, I determined that the code in these two presets are the same. Although you say that they display legal moves, they do not. They presently lack any post-game code, but that is where code for recording the legal moves should go. What errors in particular have you been seeing?
As in Rocket J. Squirrel. But I do believe that Rocket is another name for the piece.
Deciding who moves first: In Chess and most chess-like games, the first move is always given to one side. In Chess, the side with the first move is always White. However, the side with the first move also has first-move advantage. In Chess, White has a slight statistical advantage over Black simply because White always has the first move. Because either side can move first in Yangsi, that slight statistical advantage is eliminated.
You make it sound like this is an advantage of this game, but it isn't. The first move advantage still exists. While it no longer belongs exclusively to one color, the new rule concerning who moves first doesn't change how frequently the actual players each have this advantage. I would recommend scrapping this rule, because it does not actually make the game any fairer. It is simpler and better to just follow Chess on this one and let White move first. How the players decide who will move first would then simply come down to how they decide who will move as White.
While I'm glad that Gross Chess has played a role in igniting your interest in Chess variants, I have my doubts that reducing the size of the board while keeping the same pieces will make for a better game. The opening setup in Gross Chess is designed to give most of the pieces a little bit of freedom of movement from the very beginning. That gets lost with all the pieces crammed together. Also, this game has 60% piece density at the beginning of the game, which is higher than the 50% in Chess or the 64/144 = 44.4% in Gross Chess. This might make the game more cramped. However, I haven't done any extensive study on how piece density affects game quality, and I'm only guessing that higher piece density could have a deliterious effect. Some actual gameplay is required before I can make a more considered judgement on this matter.
On /r/shogi today, someone asked where they could get BCMShogi, and the person who answered provided a link to the final version of BCMGames, which is later than the version I previously had here, and unlike that version, this one works. So, I added my Shogi graphics to it and made a new distribution. Since it also supports other games, I will look into adding graphics for other games. For now, this new distribution just adds the Shogi graphics I previously added to earlier distributions. I also updated the screen shots so that they say BCMGames instead of BCMShogi.
While the message "Please report any bugs or errors to Fergus Duniho" is suitable for my own presets, it makes less sense to include it in presets written by others. Also, if you're going to try deleting code, make a copy of the complete code before you do this, and use cut instead of delete. You're not going to be able to rely on using undo like I do in a text editor.
> I get the following error message: "This preset enforces the rules and displays legal moves." many, many times.
That's not an error message. But it is repeatedly printing "Please report any bugs or errors to Fergus Duniho", and that's a sign of an infinite loop. I don't know what could be causing it. When I don't know the cause of a bug, I will delete chunks of code until it goes away, then I will restore the code, narrow down to which code is causing the problem, and fix what's wrong.
> Also as a sidenote to Fergus the command you recomened me &submit=Edit works only with capital "E". Lowercase "e" issues an error involving something with not writting in English :(!
I know that. It's case sensitive.
Since you're already registered, you could try changing your email address instead of deleting your account and signing up for it again.
The link to the script was missing from the Delete It button. I have now put it back.
One part of the code said $SESSION instead of $_SESSION. That's now fixed.
I changed the condition with isset($author) to !empty($author), which should now allow you to write to a pre-existing settings file whose author has been set to the empty string. Since the login() function can still return a true value when an empty string is passed to it as the userid, I added some lines of code to set $userid to the value of this function if it was previously empty. That should prevent anyone from saving a settings file with an empty $author string.
3d_chess_war/default.php has its author recorded as the empty string. That isn't supposed to happen.
Yes, use setsystem to set the value of capturedpieces. This is an associative array of captured pieces to display. The keys should be piece labels, and the values should be numbers of how many captured.
For the present, you pass it along to an editor to upload it for you.
25 comments displayed
Permalink to the exact comments currently displayed.
Looking at the ZRF, which was written by Glenn Overby himself, the code for the King looks like this:
The
free
command is used to verify that a piece is not immobilized by an Immobilizer. This command is used before every type of movement except the last one. This last one is for capturing the enemy King by moving forward as a Rook. Therefore, an otherwise immobilized King can still threaten check against the enemy King, and this prevents the enemy King from checking it by moving to the same file with nothing in between them. Therefore, the rule against Kings being in the same file with nothing in between them is absolute, and there is no exception for checking an immobilized King with the other King.