Comments by FergusDuniho
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.
GAME Code uses prefix notation, not infix notation. This means the operator comes first. Where it looks like infix notation, the operator is actually working with only one operand. In particular, the logical operators can work with either one or two operands. This allows you to string them together as though you were using infix notation, but it doesn't work the same way as infix notation would.
The Bishop in Caissa Britannia had used this code:
def B checkleap #0 #1 1 0 and nor capture nor empty #0 empty #1 or checkride #0 #1 1 1;
Based on what I wrote earlier, this code is incorrect. In a test I ran, this code allowed the Bishop to make a non-capturing orthogonal move, but it did not display it among the available legal moves. So, it seems to be working for actual moves, but it is not working for potential moves. With that in mind, I have changed it to this:
def B checkleap #0 #1 1 0 and cond empty #0 not capture empty #1 or checkride #0 #1 1 1;
Running the same test, this code worked correctly for both potential and actual moves.
The former is a common rule in other games, but I don't know of any game where the latter is a rule.
Because the function is going to be used for both actual and potential moves, it has to be able to handle both. For a potential move, #0 will still be occupied, and #1 must be empty, but for an actual move, #0 will be empty, and the move must not be a capture. So, depending on the value of #0, you want to confirm either that #1 is empty or that the move is not a capture. The portion of your code devoted to this looks like this:
and nor capture nor empty #0 empty #1
First, "nor empty #0 empty #1" returns true if #0 and #1 are both false. This value is used as the second value for the next nor. So, "nor capture nor empty #0 empty #1" returns true if #0 and #1 are not both false and it is not a capture. This does not seem to be what you want, since it will always require a false value for capture. But this matters only when #0 is empty, and it could throw off the evaluation of a potential move.
It would be better to use this:
and cond empty #0 not capture empty #1
This returns "not capture" if #0 is empty or "empty #1" if #0 is not empty. The and requires this value to be true for it to continue. Note that this test has to be done only once. So your code can look like this:
checkleap #0 #1 3 0 or checkleap #0 #1 2 2 and cond empty #0 not capture empty #1 or checkleap #0 #1 2 1;
Please contain your emotional outbursts. While I normally enjoy fixing bugs, I'm less inclined to do so when someone makes a huge stink about one. So, for now, I'll just tell you how to work around it. Open another tab, log in to the site, then go back to the tab where your comment was seemingly lost and reload it.
As I've programmed the game for Zillions-of-Games, promotion is possible only when a Pawn reaches the last rank by capturing a piece.
Since another user claimed authorship of this page in the comments, I updated the author and inventor of this page. I don't know if there was another erik before you. If there was, there is no trace of activity before you joined. Even the page you mentioned has a start date that is later than you joined. I'm not sure why some comments are earlier than the start date for this page. It leaves me wondering if another page had the same ItemID but got deleted. However, the page itself says the game was invented in 2013. So, maybe there was just a screw-up in the information recorded about this page.
When this happens, manually add "&submit=Edit" to the end of the URL and reload the page.
25 comments displayed
Permalink to the exact comments currently displayed.

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.