Comments/Ratings for a Single Item

"Fergus Duniho Verified as Fergus Duniho wrote on 2016-04-12 None

The Preview and Verify mode now has a Cancel button. This is like clicking the back button, but it preserves any comments you have written, and if you're in a multi-move game, such as Extra Move Chess, it will cancel the whole move at once. The main reason I added this was because I didn't like having my comments go away every time I decided against a move."

Thank you very much - I got burned by that little feature more than once myself. I'm sure others have, also. I like what's been happening here lately.

Since deleting old settings files would break the games that used them, and completely replacing them with new code could also break the games that used them, I added the ability to deprecate an old settings file. To deprecate an old settings file, go to Edit mode and enter the name of another settings file to redirect new invitations to. This will allow the settings file to be used when viewing games already played using it, but it will direct new invitations to the preferred settings file. This is useful when you change the rules or setup of a game or when you program a game in a way that will not work with notation used when previously playing the game with another settings file.

Excellent, thanks you for this.  Just what I needed!

I have now written a script for keeping track of all the settings files you have written. It is at

/play/pbmsettings/index.php

It provides some useful information for determining which ones you may want to edit or deprecate. It sorts files for the same game by date, and it tells you how many fields for GAME Code are filled in.

After exposure to Jocly's distinction between model and view, I realized that the same distinction was implicit in Game Courier, but I hadn't made it as explicit. So I have now reorganized Edit mode to reflect the same kind of distinction. I have split what Jocly calls the model into two different sections. These are Structure and Code. The structure of a game is its coordinate system and its location of pieces. The code is where automation and rule-enforcement are handled. The code has to regularly refer to the structure of the game to interpret, evaluate, and make moves.

What Jocly calls the view, I'm calling Appearance. These are details that affect how the game looks. In general, the code has nothing to do with appearance, and it should not be allowed to change it, but, for the most part, details of appearance should be user-configurable. The main exception to this is the shape of the board. This will have an impact on the rules, which the code needs to handle, and except for changing between squares and custom grid, it should not be user-configurable. But the code does not need to know the value of this field to process moves, and changing it should have no effect on the game logic.

While doing this reorganization, I have also linked each field to the appropriate entry in the Developer's Guide, and I have placed a brief description of it in the link's TITLE field, which you can view by hovering over it. Edit mode is currently showing all fields. I will fix this later.

I have taken a big step toward making Game Courier more suitable for games played in real-time. I have removed the automatic page refreshing when you hit the Continue button, and I have replaced this with a bit of AJAX that periodically checks whether it is your turn again, then refreshes the page once it is your turn again. I still have more things to do to better support real-time play. One is to include a starting time in invitations for real-time games. Another is to add an audible alert when it is your turn again. I might include a selection of sounds and give players a choice.

There are now animated clocks, and you can watch games live. The clocks appear in timed games above and below the board. The one below the board is for the player whose turn it is to move, and, as long as JavaScript is on, this one counts down one second at a time. It shows days as a serif number on a white square and hours, minutes, and seconds in a digital clock font (DSEG7 Classic Bold from http://www.keshikan.net/fonts-e.html). The number of days will not show up unless greater than zero. The hours, minutes, and seconds appear in green so long as only grace time is being used, and they change to yellow when grace time is used up, and time is being lost for real. The clock for the opponent of the current player appears at the top, and its hours, minutes, and seconds appear in red. The color coding is by traffic light colors. Red is for the player who is stopped, and green and yellow are for the player who can go.

When you view a game you're not playing, and you're viewing the latest move, the page will update whenever a new move is made. JavaScript must be on for this to work. This allows you to view games live, watching the moves as they're being made.

When making the first move on a multi-move variant, the border color and text color are now reverting to black.

Game Courier will now display the captured pieces. By default, this works by making a list of pieces in the starting position, subtracting from the list any piece on the board in the latest position, and displaying the pieces still left in the list after sorting them in case-sensitive alphabetical order. Since this is not always appropriate for every game, how or whether Game Courier displays captured pieces can also be controlled with GAME Code for individual games. To display captured pieces, Game Courier populates an associative array called $capturedpieces. This array takes pieces labels as keys and piece counts as values. This variable can be set with setsystem to an array calculated with GAME Code, or it can be set to false, which will cause no captured pieces to be displayed. This is appropriate for games with drops, such as Shogi, which already display captured pieces in the playing area.

The problem with the border and text colors was more general than anything to do with double move variants. Tying this back into the history of Game Courier, I am currently studying HTML5, and I am trying out new ways to improve the forms with the use of new features in HTML5. One of these is the color type for the input element. This displays the color instead of its name or hexadecimal code, and it provides a color selector, like what you may find in a graphics program. But when I changed the input fields for the border and text colors to the color type, I learned that it expected the color code to begin with a #, and I had been allowing color codes without it. To fix this, I used a regular expression to test whether the pre-existing value PHP would populate the form with was a six-digit hexadecimal number without a preceding #, and if it was to add one. But I had forgotten to begin and end this regular expression with ^ and $, which caused it to return true for values that already had a preceding #, causing it to add an extra one, which caused the color to change to black.

The addition of the text color is new and incomplete. I think I still have to go through the scripts for displaying the board and change how they access the text color.

When a GAME Code program displays a message with the say command, it will now also insert the message as an inline comment for the current move. To distinguish it from user-entered comments, it will surround it with two hyphens. In games I have coded, this will add comments for check, checkmate, stalemate, and draws. It can also be put to other uses.

Although Game Courier cannot fully analyze GAME Code to tell whether it fully enforces the rules of the game, I have given it the ability to more accurately estimate which presets enforce rules and which don't. One new thing that helps with this is the ability to display legal moves. When a preset has been programmed to display legal moves, it will populate an array of legal moves. So, if this array exists and has something in it, then it can display legal moves, and it very likely enforces them too. Besides checking this, Game Courier checks which code blocks are populated with code. If they're all empty, then it can be known for sure that there is no rule enforcement. If the post-move blocks are empty, odds are good that it doesn't enforce rules, and if the post-game blocks are empty, it's expected that it does not spot check, checkmate, or stalemate. One more thing is that it checks the post-game code for the strings check and stalemate. If it finds one of these in both, then it is assumed that it includes code for spotting check, checkmate, or stalemate, and this is taken as a good indication that full rule enforcement is present.

Based on this analysis, Game Courier will include a message above the board before a game begins to let you know what its capabilities appear to be. If you have programmed a game, you may bypass this and inform potential players of your preset's capabilities with even more certainty by including something like this in your pre-game code:

if == thismove null:
  say This preset enforces the rules and displays legal moves.;
endif;

By running the say command only when thismove is null, this message gets passed to it only at the beginning of the game before any moves have been made.

For games that can display legal moves, the ability to display legal moves is now extended to View and Preview modes in a user-friendly way. When you touch or click on a piece, it will show you how that piece can move. When you click an empty space, it will clear any markers that have been displaying legal moves for a piece. This can be particularly useful in Preview mode, because it will let you see how your opponent would be able to move if you go through with the move you are previewing. It will also enhance View mode by letting you see how the current player to move can move.

Game Courier has now been modified to give an error message if it does not recognize the value of the Submit field when clicking on a form. This is because the use of Google Translate may change this value to something Game Courier does not recognize, and users should be notified of this error when it happens.

I have begun to replace buttons made with the INPUT tag with buttons made with the BUTTON tag. The BUTTON tag allows me to separate the display text from the form value, which allows the display text to be translated to another language without changing the value that will be passed by the form. I have already changed a few forms, and they are working correctly when translated.

I have also begun to add the notranslate class to some tags, so that translations do not mess up the data passed to the form, and so that coordinates display properly on translated pages.

Game Courier checks where GAME Code has been entered for a preset, whether there is a list of legal moves, and the value of the rules flag to determine the extent of a preset's rule enforcement, and it now displays this information below the board, just underneath the name of the game, which links to the rules page. It used to put this information above the board before a game began, and it didn't weigh in the value of the rules flag. It now displays it below the board during the course of a game. The rules flag can be set with the command "setflag rules;", typically in the pregame code. Setting this simply serves as a signal that the code you wrote actually does enforce the rules. It has no effect on the rest of your code, and it will not provide you with rule enforcement if you don't actually program it in.

I have added an Advanced section to the Edit form. This includes a couple options that can be checkmarked. One of them was already included in the Edit form. The new one is the option "Do Not Include Moves in Code." For most games, this option should not be checked. And for unprogrammed games, it should never be checked. It's useful if you handle the execution of moves within your code. What this does is stop Game Courier from automatically adding the moves in a game to the code it generates for the game. If your game is not programmed, the result is that moving pieces will not work.

I added this option, because when I castled in Marseillais Chess and then tried to move the Rook that had just castled, it wouldn't let me, giving me the error message that the Rook was not on the space I was trying to move it from. I realized this was happening, because it would automatically execute all the moves before evaluating any of them. But I didn't need to include that in my code, because my code for Marseillais Chess would normally undo the latest moves, then replay them individually. Given that it was already doing that, I could just remove the moves it was undoing. So, I added the option to remove them.

I have modified how constant values can be included in code. In the past, a constant could be used by preceding its name with the # sign, just the same way that variables can be used, and constant names would have higher precedence than variable names. This helped keep the value constant when the name was used for a constant. But I have decided that this is a bad practice, because it interferes with a function's ability to count on its local variables having higher precedence than anything else with the same name.

So, I have made two changes. First, the @ sign may now be used in place of the # sign to get a constant value. This works only for constants, and its use will make it clearer that a given name belongs to a constant. Second, the # sign may still be used to return a constant value, but it now has lower precedence than variables with the same name. This will provide backwards compatibility so long as your variables and constants do not use the same names.

Very nice.  This, combined with the new fairychess include file, marks a definite step forward.  I'm glad to see GC code is continuing to be developed.  I was a little concerned that the change of precident could break some presets, but I just opened a large number of finished games and didn't see any issues.  Using constants and variables with the same name is probably uncommon.

I'm glad you like it. The changes I made to constants came about while I was working on the fairychess include file. Since I planned on using constants to associate piece labels with piece names, I wanted to avoid collisions between constants and variables with the same name. I did a grep search on the settings files and changed a few to use the @ sign instead. Just in case constants are used in presets that are defined in forms instead of settings files, or in case someone inadvertently uses # for constants in the future, I let it continue to be used that way but with lower precedence. Even without replacing # with @ in a few settings files, this would have been enough, because they normally did not use the same names for both variables and constants. But if I name constants after piece labels and also use short variable names in functions, collisions could arise. So, I wanted to separate the namespace between them.

I am deprecating the use of global and setglobal as aliases for system and setsystem. I would like to eventually eliminate these from the language, since global variables have a different meaning in the language.

I have limited the power of the system built-in function. While it had prevented people from viewing a password with it, it did allow you to enter "system GLOBALS" to view all the variables, which could be a big security risk. I changed it to return values only from a whitelisted set of system variables. These correspond to the same ones that may be set with setsystem.

I introduced the use of the dollar sign as a system variable designator. When appearing at the beginning of a variable name, it will return the value of the corresponding system variable if it has been whitelisted. I also added support for $old and $moved, which return the values of $lastcaptured and $lastmoved. Since the dollar sign is also the designator for PHP variables, it is basically a way to get the values for some of the PHP variables with the same name. You may also think of the S in $ as standing for system.

Game Courier is already set up to recognize old, moved, origin, and dest as values of system variables, but I don't like this, because it prevents these from being used as ordinary words, and it might make the code more confusing if you don't already know their meaning. The use of $old, $moved, $origin, and $dest should now be preferred, though I can't phase out the old way without rewrting lots of code. I have at least made the changes in the new fairychess settings file for Chess, so that they can be used going forward.

I have removed $countextrasas from the system variables. It was not used in any settings file, and I could not figure out what it was for. My comments on it were not informative enough. I commented out the code that used the variable, since it appeared to be useless.

Since I am updating the GC presets for Opulent anyway for the new array, I am going to modify it to use the new fairychess include file.  To that end, I modified the include file to add a few new pieces.  I added Half_Duck and Knight_Wazir since Opulent requires those.  While I was at it, I added the three new pieces for Kevin's games that Aurelian has been working on: Elephant_Ferz, Elephant_Wazir, and Frog.

For reference, here are all the pieces currently supported by the fairychess include file (the notes in parenthesis are not part of the actual name):

Queen
Rook
Knight
Bishop
King
White_Pawn
Black_Pawn
White_Berolina_Pawn
Black_Berolina_Pawn
Cardinal (BN)
Marshall (RN)
Amazon (BRN)
Cannon
Vao
Wazir
Ferz
Camel
Camelrider
Dabbabah
Dabbabahrider
Elephant
Elephantrider
Nightrider
Dragon_Horse (BW)
Dragon_King (RF)
Eques_Rex (NFW)
Wizard (CF)
Champion (WDF)
Korean_Elephant
Chinese_Elephant
Giraffe (4,1 leaper)
Grasshopper
Short_Rook (R4)
Squirrel (NAD)
Spider (DA)
Spider-rider (DDAA)
Squire
Unicorn (BNN)
Zebra
Elephant_Ferz (FA)
Elephant_Wazir (WA)
Half_Duck (HFD)
Knight_Wazir (NW)
Frog (FH)
Griffon
Aanca
Leo (Cannon + Vao)
Mao
Moa
Murray_Lion

One small nit-pick, the Spider-rider has a dash while the other riders do not. Any objections if I correct this inconsistency?

The hyphen is in Spider-rider to separate the two adjacent r's.