Comments by FergusDuniho

One more option is to forbid Kings from occupying the same rank. This could be programmed by giving each King a checking move to every space in its rank. Being unable to occupy the same rank, Kings could not pass each other, and the impasse situation where each King has moved into the opponent's camp would never arise. If one King passed into his opponent's camp, the other King would have to be there too, which would leave that King vulnerable to attack. Additionally, the King in the opponent's camp would be unable to move to the last rank, which would leave it more vulnerable to some attacks.

I like how this option makes the game more decisive without fundamentally overturning gameplay. Unlike some options, it has no effect until the Kings come close together. Also, it's the easiest to program, it doesn't affect the movement of any piece but the King, and it doesn't add any new goals to the game.

It woould be worth it to apply this in normal Shogi, to create a variant 'Impasseless Shogi'.

I was thinking the same thing with the name Impassable Shogi, or perhaps Impassable Kings Shogi to make the meaning more clear.

It is now ready, and I decided to call it Shogi with Impassable Kings, because this name better indicates that it is Shogi with a slight difference. The other alternatives I mentioned for the usual way of handling impasses in Shogi can also be used with Shogi with similar names that put Shogi first. So,

• Shogi with Confined Kings
• Shogi with the Try Rule, or Shogi with Thronemate
• Shogi with Campmate
• Shogi with Unopposable Kings

I can't create new game invitations. The full invitation page isn't showing up, only the top part with the game board.

I have fixed that.

Plus, DZ's comment appeared after a negative amount of seconds.

How did you determine that? What should I be looking for?

I cannot access anymore to my page "Your Games On Game Courier". I just get a white screen. Same with "Game Logs".

They worked for me. Maybe this got fixed when I was fixing errors from the PHP error log. So, try it again and let me know if the problem persists.

On a mobile device, the board is supposed to be resized to entirely fit on the screen. I suppose this could make things too small for the large games that you sometimes play. Is that what is happening? Or is the board even smaller than it needs to be to fit on the screen?

Can I edit my own message?

However, now you can't edit comments you are the author of.

I just tried to do this, and I succeeded.

And I succeeded again by editing this comment.

When I saw the error messages produced from your use of the File Manager, there was an exclamation mark after the file name. When I looked at the directory with WinSCP, I did not see the exclamation mark, but I did see that its filesize was o bytes. When I tried running the File Manager on your page for Orthodia, it hung without completing the page. Trying a test page, I found that I could upload and modify an image file. I then deleted the image in your directory for Orthodia. The File Manager no longer hung, and I was able to use the File Manager to upload and delete an image for your page. So, try again, and let me know if you have any further problems.

I fixed the problem that was stopping the File Manager from working for your Interactive Diagrams page. It wasn't taking into account the return of a false value from one of the functions for turning an image file into a GD image.

Okay, the error regarding the swap command has been fixed.

After doing some experimenting, I have determined that the normal way for HTML to pass multiple values to the same PHP variable is through a series of array assignments. For example, category[]=Hexagonal&category[]=ShogiBased instead of category=Hexagonal,ShogiBased. This page does the latter, but it relies on JavaScript to get the job done. For multiple assignments to work in HTML, the variable name in the form should include square brackets after it, which causes PHP to interpret it as the assignment of a new array element. For a SELECT element, you also have to use the MULTIPLE attribute with it to enable it to allow selection of multiple options. For checkboxes with the same name, this is not needed.

I commented this page because I’ve seen last activity there, not for the page.

If you can see where the last activity was, don't you think we can as well? Post on the appropriate page, not on the page with the last activity.

While perusing the queryinc.php code today, I came upon the similaritems parameter. Looking into what this does and what might make use of it, I discovered the likethis.php script. This script shows pages that belong to the same type and the same categories as the identified page. So, I added a link in the menu that makes use of it, and I ironed out a few kinks concerning its use. I also added functions that acquire the names of types and categories directly from the database, so that there is less discrepancy between the code and the database. I'll later migrate them to the database-funcs.php include file for use with other scripts.

Here are your definitions for fd and FD:

def fd cond var firstpart (checkride #0 #1 1 1 or checkaride #0 #1 -1 0 or checkaride #0 #1 1 0 or checkmaxsteps #0 #1 3) (sub FD #0 #1 and cond empty #0 (not match old FD +WB +CS) (not match space #1 FD +WB +CS)) and #0 and #1;
def FD cond var firstpart (checkride #0 #1 1 1 or checkaride #0 #1 -1 0 or checkaride #0 #1 1 0 or checkmaxsteps #0 #1 3) (sub FD #0 #1 and cond empty #0 (not match old fd +wb +cs) (not match space #1 fd +wb +cs)) and #0 and #1;

Let me format these to show the logic better:

def fd 
cond var firstpart 
  (checkride #0 #1 1 1 or checkaride #0 #1 -1 0 or checkaride #0 #1 1 0 or checkmaxsteps #0 #1 3) 
  (sub FD #0 #1 
  and cond empty #0 
    (not match old FD +WB +CS) 
    (not match space #1 FD +WB +CS)
  ) 
and #0 
and #1;

def FD 
cond var firstpart 
  (checkride #0 #1 1 1 or checkaride #0 #1 -1 0 or checkaride #0 #1 1 0 or checkmaxsteps #0 #1 3)
  (sub FD #0 #1 
  and cond empty #0 
    (not match old fd +wb +cs) 
    (not match space #1 fd +wb +cs)
  ) 
and #0 
and #1;

These first make sure that #0 and #1 are included in the function so that you can use them in parenthesized expressions. It then skips over the parenthesized expressions and goes to the variable firstpart. If its value is non-empty, it executes (checkride #0 #1 1 1 or checkaride #0 #1 -1 0 or checkaride #0 #1 1 0 or checkmaxsteps #0 #1 3), and it is empty, it executes

  (sub FD #0 #1 
  and cond empty #0 
    (not match old fd +wb +cs) 
    (not match space #1 fd +wb +cs)
  ) 

First, it checks whether #0 is empty. If it is, it executes (not match old fd +wb +cs), and it it isn't, it executes (not match space #1 fd +wb +cs). Each returns a truth value. If the truth value is true, then it will allow the execution of the subroutine FD. That subroutine looks like this:

sub FD from to;
  return cond cond empty #from capture (not empty #to) (checkleap #from #to 0 1 or checkleap #from #to 1 1) (checkleap #from #to 0 1 or checkleap #from #to 1 1 and == var ori #to) and #to;
endsub;

For some reason, this subroutine just returns a function call without making use of the imperative programming available to subroutines.

Reformatting it to show its logic, it looks like this:

sub FD from to;
  return cond 
    cond empty #from 
      capture 
      (not empty #to) 
  (checkleap #from #to 0 1 
    or checkleap #from #to 1 1) 
  (checkleap #from #to 0 1 
    or checkleap #from #to 1 1 
    and == var ori #to) 
and #to;
endsub;

If a player hasn't moved yet, #from will be occupied, and if he has moved, #from will be empty. If he has moved, the inner cond returns the value of capture, and if he hasn't, it returns true if the move would result in a capture. This value is passed to the outer cond. If it's a capturing move, it can move one space in any direction. If it's not a capturing move, its move is allowed only if the value of ori is the same as to. It looks like #ori has been set to the origin. So, this might stop it from making non-capturing moves.

I am curious though: if you use old in a function definition, does it return the value at the time of the function definition or the function call?

I ran some tests, and it behaved as I predicted. When you just use old, it immediately replaces it with the current value of old at the time of the function definition. But when you use $old, it uses the current value each time you call the function. So, use $old, not old.

Okay, it's working now. I had to repair the ray function.

The point is that you have broken the GAME-code interpreter, so that it hangs (without producing a proper error page) on a program that contains nothing other than the statement

set b1 findpiece B first spaces;

This is the first time this has been brought to my attention, and I have now fixed it. I also fixed the problem with just entering "set b1 findpiece B".

We would appreciate it if you at least took the responsability to see to it that GAME code functions work as advertized...

I do that regularly, but I do require that bugs be clearly brought to my attention. I skim or skip over many comments that are not directed at me.

It makes sense that all paths for Bishops and Rooks should be two-way. In this case, I neglected to unlink 4 and 5 from spaces they got diagonally linked to with map. It would help to add the following to the rules to help clarify things:

1. Every path of movement for a Rook, Bishop, Queen, or King can go either way. So, for any two spaces, x and y, if one of these piece is normally capable of moving from x to y, it is also normally capable of moving from y to x.
2. Orthogonal and diagonal paths of movement are mutually exclusive. Orthogonal movement is permitted between spaces sharing a side, and diagonal movement is permitted only between spaces that share a single corner but no sides. So, between 4 and a4 or between 5 and h6, only orthogonal movement is allowed, and between 4 and b3 or between 5 and h6, only diagonal movement is allowed.

Now, based on these, it would be legal for a Queen (or Bishop) on g6, as illustrated below, to move to either h5 or 5. Is this correct?

To reduce the illusion that 4 and 5 are diagonally adjacent to a3 and h6, I have modified the board to use alternating horizontal lines of both colors in half of 4 and 5 instead of using a dividing line. This makes it look more like each pair of spaces in a switch are actually overlapping spaces.

Let me understand this correctly: A bishop on e8 moves in the direction of switch A4/a4. Further down in your description you say that in this case the bishop can only reach A4.

Correct.

But the bishop reaches the same corner of A4 and a4; therefore the bishop can decide whether to stop on A4 or a4.

No, it cannot. Let me break the move down into steps. First, the Bishop on e8 moves to d7. At this point, movement in the same direction must go through the opposite corner is just passed through. This is the corner that d7 shares with c6. Continuing in the same direction, it can go to b5. At b5, it can move diagonally to A4, because b5 and A4 share a corner but no sides. Also, this is in the same direction that the move from e8 to b5 was in. However, b5 and a4 do share a side, which means that movement from one to the other is not diagonal. So, a move from e8 to a4 would be illegal.

So, in principle, a move into the switch, no matter from which direction and valid for all pieces, must result in a decision between the two squares of the switch - provided that the switch is not occupied.

No, that is completely the opposite of how I understand the rules.

A bishop on e8 or d1 can move to A4 or a4 respectively to h5 or H5.

This is unintelligible. If you mean what you said above, it is contrary to my understanding of the rules.

Also, a Bishop on A4 can move away on either light or dark spaces, but one on a4 can move away only on light spaces.

But a bishop on A4 cannot move to f8. For that he would have to be on a4.

That is correct, and I didn't say anything to the contrary. The light path from A4 goes through b3, c2, and d1.

3. ... or one is occupied by an enemy piece. If a piece moves to the empty space in a Switch, and the other space is occupied by an enemy piece, that piece is considered captured.

A piece can only be captured on the square it stands. Therefore, in an occupied switch, you cannot move to the empty square and capture the piece on the other square of the switch. After the move into the occupied switch, the capturing piece stands on the square of the captured piece.

Are you saying that a piece cannot capture a piece in a Switch unless it can move to the space the piece is on? Or are you saying that when a piece can move to either space in a Switch, it can move to the Switch and capture the piece, and then it must occupy the space the piece was on?

The Knight can leap directly to any space that could be reached in two one-space moves except for those reachable by two in the same direction.

I am not sure if the rule is correct. In my description I use a definition which comes from Alfred Pfeiffer (Chemnitzer Schachverband e.V.):

• The knight moves to one of the squares that a king can reach from the square in two moves, but which are not on the same row, line or diagonal. It does not move across squares that lie in between.

They are the same, but I removed the ambiguities in his description and used some technical language. Since the King cannot move into check, and a Knight is not subject to the same restriction, I replaced the reference to two King moves with one to two one-space moves. Since I would normally refer to ranks and files rather than to rows and lines, and since I have been using these words in an algebraic sense rather than a geometric sense, I rewrote it to not use them. To "leap directly" is technical terminology that implies that a move "does not move across squares that lie in between."

Why do we leave out consideration of equal/different corners and sides?

I have not done that. I consider equal ones equally and different ones differently, which is what makes most sense.

Can't we agree that switches can be entered from all sides and a choice must be made between the fields of the switch? Surely that would be much easier for everyone.

No, it would not be easier for everyone. This makes the game more confusing and complicated, because paths to and from Switch spaces are no longer symmetrical with each other. This would allow one King to attack another, and the following position would count as checkmate.

I think my position is quite logical.

It's not logical. At best, it is not outright contradictory.

At the beginning of the discussions, I was of the opinion that switches work differently when they are operated from below, from the side, or from above.

That's the position which makes the most sense, because it makes how Switches work a consequence of the geometry of the board.

I have abandoned this opinion and changed it in favor of a pragmatic solution, in that a switch must be handled the same regardless of the direction.

This conflicts with the rule that the space a piece is on in a Switch determines how it may move away. While you could have both rules, it makes the game more confusing.

Are you saying that a piece cannot capture a piece in a Switch unless it can move to the space the piece is on? Or are you saying that when a piece can move to either space in a Switch, it can move to the Switch and capture the piece, and then it must occupy the space the piece was on?

This seems to me to be much simpler than you make it out to be. After all, a piece can only be captured where it is. Why should this be different for a switch?

I was asking you to clarify which of two possible interpretations of what you said is the correct interpretation, but you didn't do that.

Why should a piece be able to move to A4, and thereby capture a piece on a4 quasi en passent? That only happens with pawns. But that's where it should stay. The basic principle should be that pieces are captured on the square on which the pieces were placed. Pragmatic solution, isn't it?

In both of the alternatives I asked you about, the capturing piece ends up on the space the captured piece was on. But you have not indicated which you have in mind. So, let me illustrate the difference.

In this position, can the Black Pawn capture the White Pawn and move to A4? Or is the Black Pawn unable to capture the White Pawn, because the move from c5 to A4 is not diagonal?

I find the idea that a bishop on d1 can only move to a4 or to H5, or a bishop on e8 can only move to A4 or h5, to be completely illogical.

Assuming you mean the spaces in a Switch it can move to and not the full range of its movement, this logically follows from the geometry of the board.

You can bend it with corners and sides so that it seems logical, but basically, from my point of view, it leads to complicating the rules.

As an experienced programmer of Chess variants who has tried to program your game, I can give you my expert opinion that this is not true.

The rule that a switch is a place of decision to occupy the squares of a switch uniquely, no matter from which direction the switch is occupied, seems to be a clear rule that everyone can understand. I do not think that such a rule complicates the course of the game.

It really does complicate the course of the game. It is a tacked-on that does not follow from the geometry of the board, and the code required to enforce it would be more complex than the code required to enforce the rule you mistakenly imagine is illogical.

But why can't a bishop from d1 move to A4 and what am I still overlooking here?

It can move from d1 to A4. Here is a diagram I made for my Reroute66 page yesterday:

Should the description consider the following knight moves? Knight on b3, is the move to a5 possible, because on the same diagonal?

By your rules, I think it is not legal. By Reroute66 rules, it is legal, and I have illustrated it in a diagram on that page.

Or a knight on a3, are the moves to a5 or b5 possible, because on the same line?

I have also illustrated this on my Reroute66 page, because they are legal in that game.

Chess66 uses a different rule for Knight moves than Reroute66 does. Mine says that a Knight can leap directly to any non-adjacent space reachable by any combination of a single lateral and a single diagonal move. Your rule says that a Knight may leap two spaces away to any space not on the same line, row, or diagonal, which I assume are all meant in a geometric sense. While mine specifies the types of moves, yours does not, and it replaces this with a stricter restriction on which spaces a Knight may leap to. Besides excluding moves to non-adjacent spaces, it also excludes moves to spaces in the same row, line, or diagonal.

Since both rules would give you the Knight's usual moves on an 8x8 Chess board, this doesn't provide a basis for comparison. I favor the rule I use, because it allows the Knight to gain some additional powers of movement around a Switch. By making the Knight an inverse of the Queen, as your rule does, it weakens the Knight around the Switches, which I don't think is fair for what is already the weakest piece in the game.

Is it possible that the move to d5 is missing here?

That move is illegal in Reroute66, for it cannot be reached by any combination of a lateral move and a diagonal move. Unlike Chess66, A4 and b4 are not laterally adjacent in Reroute66. They do share a corner, though. So, I'm wondering whether I should tweak my definition of diagonal to not count them as diagonally adjacent, or if I should say they are diagonally adjacent though they aren't part of a longer series of spaces diagonally connected in the same direction. If I go with the latter, the Knight could also move to c4, and a Bishop on A4 could also move to b4, though it couldn't go any further, because none of the diagonal directions on d4 would be in the same direction.

I guess I could say that two spaces are diagonally adjacent if they share nothing but a corner, and there is a straight path from approximately the center of one space to approximately the center of the other that passes only through that corner without passing through other spaces. For A4 and b4, the only straight path between their centers would go through a4

More simply, I might say that two spaces are diagonally adjacent if they share nothing but a corner, and there is a path between them that passes straight through that corner without touching their sides.

I can't bear to look at the graphics on this page. I have never liked the Galactic set, and these huge smiley graphics are like something from a nursery room.

I took the first step of removing the smiley graphics. What I don't like about the Galactic graphics are that they are grainy looking, unevenly colored, and somewhat indistinct from each other. Since they're there mostly by the Diagram Designer, they could be changed to another set with a search and replace. But the question remains what to replace them with.

Back when Roberto Lavieri designed the Galactic set, I let Game Courier include it for those who preferred it, because Game Courier would not force anyone to use them. But the Diagram Designer, which I developed later, is a different matter, because viewers can't choose to just change the graphics for a page they are reading. So, maybe I should restrict the sets it can use.

This kind of thing is usually caused by a parsing error that is due to a simple syntax error. To find out what it could be, I added "list;" to the end of your Pre-Game code and clicked Run. At the end of the first listing, I got this:

907   remind "Enter third leg of move or press Pass;
gosub legalmoves2 KING 2;
continuemove;
elseif sub stalemated king:
endif;
;end;

So, it looks like your remind statement is missing a closing quotation mark. However, looking at your actual code, I don't see it missing.

I would recommend the general debugging technique of cutting or commenting out sections of code to determine which code is causing the problem. If you cut code, paste it back in before cutting more, so that you can later paste back in all that you cut out.

I see that your HT subroutine has a line where it refers to origin and dest instead of to #from and #to. That may be where your bug lies.