[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]
Comments by FergusDuniho
Has who tested what game?
I don't think it is a matter of Imposter Chess being unplayable online. It seems to be simply a matter of not yet understanding how to make complicated moves with Game Courier.
Although I have never tested Game Courier on WebTV Plus, I have no reason to expect that Game Courier would be incompatible with it. Nearly everything that Game Courier does is done on the server-side. The few things it uses client-side JavaScript for are inessential, and Game Courier should work perfectly well without JavaScript even running. The only incompatibility I can imagine is if WebTV does not properly display some methods of rendering the board. In that case, I would recommend switching to a method that it would render properly.
You wrote: >> I made sure to type lowercase 'p', as I was playing Black. >> Could I be getting this error because my WebTV Plus isn't compatible with the PbEm system?' No, the system you're browsing the web on should have no effect on this kind of error. My best guess is that you are actually trying to move a Black Pawn from a space that does not have a Black Pawn on it. If this is part of a complicated move, make sure that you have not emptied the space before you try to move the Black Pawn from it. The order in which you string together parts of a move is critically important. Each part of a long, complicated move updates the configuration of pieces before the next part is looked at. Separate parts of a move are not performed simultaneously. For example, if you wished to swap the White King and Queen in Chess, 'K e1-d1; Q d1-e1' would not work, because there would be no White Queen at d1 when it got to 'Q d1-e1'.
Tony, I am not sure what has happened with the log for the game of Pocket Mutation Chess between Andreas and Laila. My best guess is that Laila actually entered her move as a comment, perhaps because she was having difficulty sending it normally. Looking at her earlier comments within the context of this game, it appears to me that 'p e7-e6' should have worked. If it didn't work, there might have been an earlier problem. Based on my examination of the Log, Andreas issued an open invitation, Laila accepted it, chose to play Black, then Andreas made the first move. Would Andreas or Laila please confirm whether this is correct?
Andreas wrote: 'Another thing I suspect is that Laila entered not 'p e7-e6', but '1....p e7-e6'. I made a similar mistake when I played here for the first time.' I tried the same thing in a test log I created, but it isn't getting the same results. It may help for Laila to tell me exactly what she typed in.
Laila, Here is what I specifically want to know. When you verify your move, does the new move appear on a new line? Or is it even then appended to the previous line?
Laila, Here is what I think might be happening. In verify mode, the movelist is contained in a hidden INPUT element. When it gets passed to send mode, WebTV may be ignoring the linefeeds in the movelist, passing what should be multiple lines of text as a single line. If this is what is happening, you will see your move on a new line in verify mode, but when you get to send mode, the whole movelist will be on one line. Please let me know whether this is what you observe.
Laila, Try it again now. I have read that WebTV is very strictly standards compliant, and that the standard newline indicator is CR+LF. So, in the movelist, I have now ended each line with a carriage return plus a linefeed instead of just a linefeed. Please let me know if this fixes things for you.
Peter's idea is a good one, but he left out part. The next direction used in the macro presumes that all spaces on the board have been linked together with the next direction, and a1 is the first position on the board. If your ZRF didn't already have this set up, you would have to set it up before this macro would work. The OFF position would be defined as a position after the end of the board. Here is a macro that would work just as well and is more optimized. (define Pawn-Win ( (verify (in-zone? king-capture)) a1 (while (and (not-piece? King) not-enemy?) next) add )) There is no need to check for OFF or even for (on-board? next) -- unless you loop the whole board back to front, which you don't need to do. A while loop stops once the end of the board is reached. Besides this, the assumption is that the King is always on the board, and so the King would be reached before the while loop went off the board.
As I understand what you want, Lynn's suggestion that add won't work may be mistaken. After all, you don't want the win-condition to be the <b>mere</b> presence of this haloed Pawn. You want it to be the presence of this piece at the beginning of a turn.
I suspect that your own idea of using a PseudoKing is what would work best. And I don't think it entails an extra click to end the game. Just make the goal of the game the checkmate of the PseudoKing on the dummy square, and make it possible to check it only by a Pawn on the square it must reach to win. So long as the opponent can't take it, the player will win when he reaches that space with his Pawn. But if the opponent can take it, then the game will continue.
Here is what may be the shortest and most efficient way to do what you want. In addition to creating a dummy position with a PseudoKing on it and making the goal checkmate of this piece, use an otherwise unused direction to link any space the Pawn must reach to win with the dummy space. Then give the Pawn some extra move code as simple as (tovictory add), assuming that tovictory is the direction you used. This dispenses with the need to test for zones or change a piece's type. And that dispenses with the need to create zones and an additional piece type.
The line you mentioned in sendmove.php is part of a for-loop. The error you reported is probably caused by an infinite loop. Since this for-loop goes through the lines of the movelist, odds are very good that my solution did not work for you. I have now tried a new solution. The script now encodes and decodes form data. So linefeeds no longer even appear in hidden form values. Please let me know how this works for you.
The problem should now be fixed. As mentioned in my message to Laila, I made some changes to accomodate WebTV. It now encodes and decodes form data. But I did not have it decode form data early enough. I had it decode form data after reading the log, because it was at this point that I was already assigning all the POST variables. But this was only to override the values set in the log. PHP naturally assigns all POST variables without any explicit assignment in the program, and I was using some post variables to tell which log to read. This is where it broke down. It tried to use the decoded form of the game's name, and this didn't work for names with spaces in them. So, to fix this, I copied the code for assigning POST variables to an earlier part of the script. It should now properly identify which log to read for all games.
There is insufficient contrast between the board and the off-board areas. There is no need to checker the off-board areas, since they are just holding areas, not playing areas. Leaving them uncheckered would create better contrast with the board, which would allow players to more easily distinguish between the two.
This page could use a legend telling what the pieces are.
It's good that the new pieces have descriptive names instead of letter names. This practice ought to be extended to all the pieces. Did you use letter names because Game Courier uses letters to identify pieces? The letters used to represent pieces are defined in a set file, not in the piece names themselves. If someone wanted to make sets of your pieces that match the sets made with other piece designs, the letter names given to the pieces would be of no help at all.
Let me add another reason why descriptive names are preferable. Game Courier normally displays all the pieces in a set at the bottom of the page, and it puts the image name in ALT text. So when you place your mouse cursor over a piece, it shows you the image name. When names are descriptive, this provides users of Game Courier with very useful information. Someone designing a preset can use this information to tell whether a set has appropriate pieces for a game and to choose the right pieces. But when image names are just letters, the ALT text provides users with no useful information. In fact, if a set were made that matches a set of some other design, the information provided in the ALT text could be more confusing than helpful. For example, some other sets associate the Cannon with c/C. If a Galactic set were made that matched one of these sets, a user placing his cursor over the Cannon image at c would see 'a.gif' in the ALT text.
I'm all for tournaments using Game Courier. I haven't brought it up before, because Glenn has been inactive on this site. Apparently, Glenn has been very busy. In a recent email he sent to the editors, he mentions that he is still swamped. I think something like what was done the last time would be a good idea. Someone could elicit a list of games people are interested in playing in a tournament, then base the tournament around the most popular games in the list.
Is there any precedent in the Chess world for giving Black more points for a win or draw? Unless there is a really good reason for it, I would not favor this practice. Instead, I would favor giving out the same number of points for a win or draw no matter which side a player plays. Also, as was done in the last tournament, I'm in favor of not limiting a tournament to official recognized variants. A tournament can be a good vehicle for giving greater recognition to good variants that have not yet become officially recognized.
If it's to be specifically a Game Courier tournament, then I recommend that the pool of games people select from should be those games that have had Game Courier presets made for them. Anyone who wanted to add games to this pool could make new presets.
I've created a page for starting a multi-variant Game Courier tournament. Details are given on the page, and we can continue discussion of this subject there.
Makruk already has a preset. Tony Quintanilla and L. Lynn Smith have been working on a preset for one of Smith's 3D Star Trek variants. Fischer Random Chess is currently beyond the capabilities of Game Courier. As for the others, I will let those who are interested in them make the presets.
Regarding the games from the 2003 Multivariant Tournament, the following already have Game Courier presets: Cavalier Chess, Chess with Different Armies, Grand Chess, and Hostage Chess. Those without presets are these: Chess on a Longer Board with a few Pieces Added, Extinction Chess, Omega Chess, Rococo, and Ximeracak. I think I never did a preset for Omega Chess mainly because the PBM system could not handle its peculiar coordinate system. Game Courier can now handle it with the custom shape method. But, since it is proprietary, I will hold off on making a preset for it. As for the others, I'll leave them to those who are interested in including them in the Game Courier tournament.
25 comments displayed
Permalink to the exact comments currently displayed.