Check out Grant Acedrex, our featured variant for April, 2024.


[ 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

LatestLater 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]
💡📝H. G. Muller wrote on Sat, Oct 3, 2020 04:52 PM UTC in reply to H. G. Muller from Fri Aug 28 10:02 PM:

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 Fri, Aug 28, 2020 10:02 PM 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 Thu, Aug 27, 2020 09:14 PM 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 Mon, Aug 17, 2020 03:57 PM UTC in reply to H. G. Muller from 08:56 AM:

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 Mon, Aug 17, 2020 01:10 PM UTC in reply to Fergus Duniho from 01:07 PM:

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 Mon, Aug 17, 2020 01:07 PM 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 Mon, Aug 17, 2020 08:56 AM UTC in reply to Greg Strong from 01:18 AM:

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 Mon, Aug 17, 2020 01:18 AM UTC in reply to H. G. Muller from Sun Aug 16 09:50 PM:

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 Sun, Aug 16, 2020 09:50 PM 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


9 comments displayed

LatestLater Reverse Order Earlier

Permalink to the exact comments currently displayed.