You are on the backup site for Chessvariants.com. Any posts, moves, or other changes you make here will not be permanent, because the pages and database from the main site will be backed up here every midnight EST. Additionally, things may not be working right, because this site is also a testbed for newer system software. So, if you are not here to test, develop, or merely read this site, you may want to change .org to .com in the navigation bar and go to the main site.



The Chess Variant Pages




[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Latest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments/Ratings for a Single Item

Later Reverse Order Earlier
A Wizard for GAME-Code Generation. A tutorial on using the Play-Test Applet for automating Game Courier presets.[All Comments] [Add Comment or Rating]
Fergus Duniho wrote on 2022-02-06 UTC

I'm having some problems with this game. First, I can't seem to get the piece images to show correctly. Right now it looks ok at first, but when viewing a game from black's perspective it's all wrong again.

Because you're using the Alfaerie:Many set, which includes some flipped pieces, you need to include a value for $flipped. Since you are not using any flipped pieces in your game, you should set it to the same value as you are setting $pieces to.


H. G. Muller wrote on 2022-01-18 UTC

That would be too bad. But I don't think anyone but Fergus can fix bugs in Game Courier or the GAME code interpreter.


Aurelian Florea wrote on 2022-01-18 UTC

I am not sure about Fergus being available, HG.


H. G. Muller wrote on 2022-01-15 UTC

This error is weird: the error message obviously comes from the GAME code used to automate the preset, from the move parser. But it seems thise is called in an unexpected context: Game Courier tries to feed the game history to the code in the Post-Move sections twice. And the second time the position has already been changed from the initial one to some weird one, which indeed has a Z on g4.

For debugging I added a statement

printr $space

at the end of the Pre-Game section. When I then use the preset in Play mode, and play the given game, the page that complains about the error contains two dumps of the $space array. The first is the initial position (as expected), but the second is

Array
(
    [a12] => d
    [b12] => l
    [c12] => u
    [d12] => z
    [e12] => o
    [f12] => q
    [g12] => k
    [h12] => o
    [i12] => z
    [j12] => u
    [k12] => l
    [l12] => d
    [a11] => r
    [b11] => m
    [c11] => n
    [d11] => b
    [e11] => a
    [f11] => y
    [g11] => y
    [h11] => a
    [i11] => b
    [j11] => n
    [k11] => m
    [l11] => r
    [a10] => x
    [b10] => i
    [c10] => e
    [d10] => g
    [e10] => s
    [f10] => c
    [g10] => c
    [h10] => s
    [i10] => g
    [j10] => e
    [k10] => i
    [l10] => x
    [a9] => p
    [b9] => p
    [c9] => p
    [d9] => p
    [e9] => p
    [f9] => p
    [g9] => @
    [h9] => p
    [i9] => p
    [j9] => p
    [k9] => p
    [l9] => p
    [a8] => @
    [b8] => @
    [c8] => @
    [d8] => @
    [e8] => @
    [f8] => @
    [g8] => @
    [h8] => @
    [i8] => @
    [j8] => @
    [k8] => @
    [l8] => @
    [a7] => @
    [b7] => @
    [c7] => @
    [d7] => @
    [e7] => @
    [f7] => @
    [g7] => p
    [h7] => @
    [i7] => @
    [j7] => @
    [k7] => @
    [l7] => @
    [a6] => @
    [b6] => @
    [c6] => P
    [d6] => @
    [e6] => @
    [f6] => @
    [g6] => P
    [h6] => @
    [i6] => @
    [j6] => @
    [k6] => @
    [l6] => @
    [a5] => @
    [b5] => @
    [c5] => @
    [d5] => @
    [e5] => A
    [f5] => P
    [g5] => @
    [h5] => @
    [i5] => @
    [j5] => @
    [k5] => @
    [l5] => @
    [a4] => P
    [b4] => P
    [c4] => @
    [d4] => P
    [e4] => P
    [f4] => @
    [g4] => Z
    [h4] => P
    [i4] => P
    [j4] => P
    [k4] => P
    [l4] => P
    [a3] => X
    [b3] => I
    [c3] => E
    [d3] => G
    [e3] => S
    [f3] => C
    [g3] => C
    [h3] => S
    [i3] => G
    [j3] => E
    [k3] => I
    [l3] => X
    [a2] => R
    [b2] => M
    [c2] => N
    [d2] => @
    [e2] => A
    [f2] => Y
    [g2] => Y
    [h2] => A
    [i2] => B
    [j2] => N
    [k2] => M
    [l2] => R
    [a1] => D
    [b1] => L
    [c1] => U
    [d1] => Z
    [e1] => O
    [f1] => Q
    [g1] => K
    [h1] => O
    [i1] => @
    [j1] => U
    [k1] => L
    [l1] => D
)

This is neither the initial nor the current position, although it does have some characteristics of the current position.

Perhaps Fergus can shed some light on how the Pre-Game section could be executed twice when entering a single move in Play mode.


Daniel Zacharias wrote on 2022-01-14 UTC

I'm having some problems with this game. First, I can't seem to get the piece images to show correctly. Right now it looks ok at first, but when viewing a game from black's perspective it's all wrong again.

Second, there's this error

ILLEGAL: P g4-g6 on turn 1:

There was no P on g4. The piece on g4 is a Z.

Go back with your browser's BACK button, reload the page, and try again.

For diagnostic purposes, here is the full movelist:

1. P g4-g6 
1... p g9-g7 
2. Z i1-g4 
2... a e11-i7 
3. P f4-f5 
3... a i7-d2; q-dest 
4. A h2-e5 
4... q d2-i7 
5. P c4-c6 
5... q i7-i3 // - check! -
6. E j3-i3

I have no idea what I did wrong


H. G. Muller wrote on 2021-05-28 UTC

The betza.txt include file for GAME code generated by the Play-Test Applet now also supports crooked and circular pieces (in general 'custom trajectories'). Even in combination with a p or g modifier.


H. G. Muller wrote on 2021-05-28 UTC

OK, works now.


Fergus Duniho wrote on 2021-05-28 UTC

I just turned on the group write bit for the file. Try it again.


H. G. Muller wrote on 2021-05-27 UTC

I tried to update the betza.txt GAME-code include file, but I get this error message:

Upload of /home/chessvariants/public_html/membergraphics/MSgame-code-generation/betza.txt
was allowed but failed! The cause of failure is unknown.

Fergus Duniho wrote on 2020-12-31 UTC

Just to be sure: I can use the word 'resign' as a string literal expression > operand without it being confused for a command? Like

if == resign thismove:
 resign
endif;

Yes, but you should include a semicolon after the second line. Without it, this code would result in an error.


H. G. Muller wrote on 2020-12-30 UTC

Just to be sure: I can use the word 'resign' as a string literal expression operand without it being confused for a command? Like

if == resign thismove:
  resign
endif;

?


H. G. Muller wrote on 2020-12-28 UTC

OK, thanks. This will make life easier, as indeed I would otherwise have had to break from several levels of subroutines.

Some explanation: the error message was from my own parsing routine. My code works by comparing the input move to all legal moves generated in the position before the move, and it needs a complete description of the move to do that. (Not only the basic move, but also optional freedrops or suicides that occur as (possibly mandatory) side effects.) So I don't rely on move parsing as it occurs when you feed a move primitive to GC through a MOVE: prefix, as this would also change the position, but wrote my own parser that extracts all square coordinates and piece labels from all primitives. Which again is called from another 'do everything' subroutine so that users only have to put a single subroutine call in the Post-Move sections. So if the parser doesn't see a hyphen in a move primitive, it exits through die without any of the primitives having been fed to GC.


Fergus Duniho wrote on 2020-12-28 UTC

What is the recommended way to handle resign (or drawn) in presets that have the checkbox ticked to not include moves in the code?

I don't believe the issue is with that in particular. In tests I just did with Extra Move Chess, resign and drawn worked as they should. Your code does some things differently, which I already mentioned below.

The GAME-code manual says that resign should not be used in code,

That may be a suggestion. I tried it directly in the code, and it did work. It made White resign as soon as he entered his first move.

but when I don't do anything about it, attempts of a user to resign will just draw an 'invalid move syntax' error message.

Is that the precise wording of the error message? Using multiple grep searchs, I did not find any text, PHP, or JavaScript file with code for that error message.

I can of course test for the input command to be 'resign' at the start of the ParseMove subroutine (and for efficiency reasons only do that test on the final move of the sequence, or even defer it to the point where it is rejected as a valid move). But what should I do then?

Yes, it may be a good idea to detect it before processing the move. If you are evaluating moves before playing them on the board, you want to evaluate resign and drawn moves differently. In Extra Move Chess, the code plays each move on the board before evaluating it. This is probably why it has no problem with resign or drawn.

Prefix thismove with MOVE: and offer it for execution?

That's what I would recommend. In general, you should be doing that for every move somewhere in your code.

And what happens to the control flow after that? Will it terminate execution of the remainder of the Post-Move code, or should I explicitly abort execution after it?

The resign, lost, won, and drawn commands all include return, which will exit the run_subroutine() function. This will end the current subroutine, and if the command occurs at the main level, this will end the entire GAME Code program. When moves are automatically included in the code, they are placed at the main level between the Pre-Move and Post-Move subroutine calls. But if you are executing the command from within a subroutine, it will exit only that subroutine, and program execution will continue from the point after that subroutine was called.

I have just modified these commands to exit the program entirely using the same method as the new exit command.

Incidentally, the end and stop commands are not particularly useful here. The end command works only on the main level, and the stop command just returns from the innermost call to run_subroutine(). There is no command for halting program execution from within a subroutine.* The die command uses PHP's exit() function, which exits the whole PHP script, but that's overkill for naturally ending the game. Ideally, you should be using MOVE: at the main level, or when your subroutine comes across resign or drawn, it should exit the subroutine with an error code, and the following code should immediately check whether the error code has been given and take appropriate action at the main level if it has.

* I just added the exit command, which does exit the GAME Code program.


H. G. Muller wrote on 2020-12-28 UTC

@Fergus:

What is the recommended way to handle resign (or drawn) in presets that have the checkbox ticked to not include moves in the code? The GAME-code manual says that resign should not be used in code, but when I don't do anything about it, attempts of a user to resign will just draw an 'invalid move syntax' error message. I can of course test for the input command to be 'resign' at the start of the ParseMove subroutine (and for efficiency reasons only do that test on the final move of the sequence, or even defer it to the point where it is rejected as a valid move). But what should I do then? Prefix thismove with MOVE: and offer it for execution? Put resign in the code after all? And what happens to the control flow after that? Will it terminate execution of the remainder of the Post-Move code, or should I explicitly abort execution after it?

As this seems a general problem with not including moves in the code, and resigning games seems a universal feature that should never be tampered with, I wonder if it wouldn't be a better solution to exempt resign from not being included in the code, and have Game Courier always recognize and execute it, irrespective of the checkbox setting.


H. G. Muller wrote on 2020-10-03 UTC

I have now adapted the betza.txt GAME-code include file to use the setjsvar command to pass the start position to the client as a JavaScript variable 'impmoves', and adapted the movepiece.js file that the client can link to to use this variable. This restores the ability to navigate locally through the game history with the aid of the buttons that will appear below the board.


H. G. Muller wrote on 2020-08-28 UTC

Ah yes, I had been experimenting a bit. Your previous client script was not bothered by this piggy-backed info, because it didn't match any of the square coordinates. Thank you for providing a more regular way to do transfer info. For now I just commented out adding that last element to $extralegal from the betza.txt include file; when I have more time I will try out the new way.


Fergus Duniho wrote on 2020-08-27 UTC

Since my copy of Mighty Lion Chess wasn't handling en passant capture, I updated it to the latest code. After doing so, I was unable to move pieces by clicking on them. This was so both in the code I was testing and in the already-tested stable code. On investigation, I found out that the list of legal moves included the move "zzz,rlbqkbnrpppppppp32PPPPPPPPRLBQKBNR,4". This was screwing things up. Please limit the use of the list of legal moves to properly formatted moves.

In case you need to pass other data to JavaScript, I have just added the command setjsvar. Use this like you would set. It will store values into an associative array keyed to the variable names, and after the program runs, it will write JavaScript variable assignments. It will write numeric values as is, put quotation marks around strings, and JSON encode arrays. It will write the assignments before the legalList assignment, so that you cannot use it to overwrite this variable.


Ben Reiniger wrote on 2020-08-17 UTC

So there is an item ID, a summary and a description. The item ID determines the URL (and I will never repeat the mistake to make that very long!).

Right so far.

The index will list item ID + description, the comment headers will list summary + description. Apparently summary and description are set to the same text when first submitting a new article? It is the summary that can be controlled by the author through the 'Edit index information', as 'Item name'.

I don't think this is right.

The Summary is also called the Item Name, and the latter name is perhaps clearer. The Description is a one-sentence(ish) blurb. The ItemID is a unique permanent identifier, which the URL is also based on. Then there are Index Entries, with a Link Text and Link Description; these are used on search pages (except What's New, which has its own description), and the header on comment threads use the Item Name and the Link Description (???).

When you first submit a page, you provide an Item Name and a Description. An ItemID is created based on that Item Name (generally with a prefix MS, MP, etc. and with spaces replaced with hyphens, etc.). The ItemID is meant to be a permanent unique id, and the URL for the page is based on this ID as well.

The Description that you provide when you first submit a page just populates the initial Index Entry, together with the Item Name. Most pages will only ever have this one Index Entry, but you can have more; see in particular the Piececlopedia, where a piece with multiple common names is given and Index Entry for each name, for ease of discovery. (We also distinguish "Primary" index entries, and the query can filter down to only those primary entries if you don't want the duplicates.)

You can update the Item Name. This will not update the ItemID nor URL (because those are meant to be permanent), so these can diverge. Also, changing the Item Name doesn't update the Index Entry, which might be a little confusing. I think users can't add index entries (perhaps to prevent exploiting them for greater visibility), but updating them may be made available.


H. G. Muller wrote on 2020-08-17 UTC

This is true; it was released a bit quicker than I expected. But the omission of the start square in where should already have been fixed; I noticed that this morning.

I did test the code now.


Fergus Duniho wrote on 2020-08-17 UTC

You appear to be posting untested code. I have seen various instances of the where operator with only two arguments. It should take three, because the value returned is relative to a coordinate given in the first argument.


H. G. Muller wrote on 2020-08-17 UTC

Ah, and you published it too! Thanks. The icon in the index still might have to be changed, as this is not a game description.

So there is an item ID, a summary and a description. The item ID determines the URL (and I will never repeat the mistake to make that very long!). The index will list item ID + description, the comment headers will list summary + description. Apparently summary and description are set to the same text when first submitting a new article? It is the summary that can be controlled by the author through the 'Edit index information', as 'Item name'.

Since the summary only seems to appear in the comment headers, which also always show the description, it doesn't make much sense to have those nearly the same. It would actually be more logical if the comment headers showed the same information as the index, i.e. use the item ID instead of the summary. Or, in other words, set the summary to the item ID, or something close to it, that doesn't repeat what the following description already says.


Greg Strong wrote on 2020-08-17 UTC

So, there's two different descriptions. There is the IndexEntry description which I have changed to what you request. But the Item table has a separate description, (called Summary), which is shown when viewing or commenting on the actual page. This field is limited to 64 characters, so I set it to 'Using the Play-Test Applet to generate Game Courier presets' because yours was too long.


H. G. Muller wrote on 2020-08-16 UTC

I posted a short tutorial on how to generate GAME code with the Play-Test Applet. But I aready regret the description I have given it (GAME code generation with the Play-Test Applet (a tutorial)). I called the item 'GAME code generation', because I wanted to avoid long URLs that refer to it (such as /membergraphics/MSplay-test-applet-for-chess-variants/*). But it appears the name of the item will automatically be written before the 'description', at least if the 'Unpublished submissions' list uses the same format as the alphabetical index will eventually use. That duplicates the 'Game code generation' phrase, which looks a bit silly, and wastes precious space that could have put to better use.

So my request is for an editor to change the description to:

A tutorial on using the Play-Test Applet for automating Game Courier presets


23 comments displayed

Later Reverse Order Earlier

Permalink to the exact comments currently displayed.