Comments/Ratings for a Single Item

Using the Web Developer Tools Console in Firefox to debug the JavaScript, it told me that board[castleRank] is undefined in your MoveToText function. While castleRank is assigned a value in your PartnerDetect function, it has not been assigned a value in MoveToText.

Can you add Interactive Diagram to Horizons please?

P. S. Can you add Zip (a.k.a. Lightning) in Piececlopedia?

What I think happened is that HTML entities got converted into the actual characters in the database, and this messed up those places where you relied on HTML entities. Since it now converts to HTML entities to display HTML in forms, and it now converts back to save to the database, you can no longer rely on using HTML entities if you use the HTML format. However, the new chr shortcode will let you display HTML entities without storing any in your code. Unlike HTML entities themselves, the shortcode is unaffected by the conversions that affect HTML entities. So, you can safely use them where you would once have used HTML entities. When replacing HTML entities, make sure to use chr with the text you would normally place between an ampersand and a semicolon for the HTML entity. If you use a number instead of text, it will use PHP's chr function to display the actual character rather than the HTML entity.

Using numbers 60 and 62 for the less than and greater than signs in the PRE tags.

<PRE>Using the text lt and gt for the less than and greater than signs in the PRE tags.</PRE>

<PRE>Using numbers prefixed with the # symbol in the PRE tags.</PRE>

Based on these tests, you can use numbers prefixed with # for HTML entities. Only an unprefixed number will give you the actual character.

The part of the wizard where you add pieces to the board is still broken. The board shows up, but nothing else.

I inadvertantly broke this when I added the Betza-to-text converter. This uses castleRank to get the name of the piece that is castled with. But it tries to do that when there exists a piece that can castle in the piece table. But if that piece is not yet on the board (as it is in the Wizard, as this starts with an empty board) castlingRank has not been determined yet. I fixed that now.

I get the Step 3 part now, but I can't get it to add pieces. I clicked on Stock, where it tells me to click on any nr of pieces and click Stock again. So, I clicked on all the pieces in Chess, clicked Stock, and the requester listing the pieces just goes away. When I click on "I'm done", it asks me to drag pieces to the board, but it doesn't supply any to drag to the board.

The table with pieces (from which in the next step you would have to drag the pieces to the board) does not appear. I suspect this is a consequence of the corruption earlier on the page, which inserted an extra Diagram on the page. This confuses the script as to which table it should insert the pieces you select in. Each Diagram comes with a table, even if that table is hidden by default.

There originally was one other Diagram in the introduction, and when the Wizardis opened it erases that Diagram to prevent this problem. But the corruption created a new table by transforming the visible text for what you would have to insert to embed a Diagram into an active Diagram, by replacing the &lt; that was 'disarming' it into actual < characters. When you select pieces a lot of activity occurs in that location. (All error messages, because the origial text only showed the enclosing HTML tags without actually having the content between them to specify a valid Diagram. That makes sense, as for each piece you add to the Diagram it tries to recreate the Diagram with the new parameters. But it recreates the parasitic Diagram instead of the one in the Wizard.)

I have been studying the membersubmission PHP scripts yesterday to repair my lack of understanding on what is going on. (I actually went so far as to copy some, and modify those to see what would happen. More about that later.) As I understand it now the function htmlspecialchars() acts on what is in the database to display it in a HTML textarea. And when this text is submitted htmlspecialchars_decode() reverses the substitution. This indeed should not surreptitiuosly alter untouched text in the database. So I still don't understand how this could have led to corruption: originally there was a &lt; in the database; it should have been converted to &amp;lt; for editing, and then back to &lt; on storing. It seems like htmlspecialchars_decode() has been acting twice on it, also decoding the &lt; that resulted from the decoding of the &amp;.

Anyway, the problem with this strategy (when it would work correctly) is not so much with altering untouched text, but altering what an unsuspecting user creates as new text. To get &lt; in the database, he should perform a mental htmlspecialchars() on it to encode it (typing &amp;lt; when he wants to see &lt; in the article). This indeed seems to result in the desired effect similar to the new method with chr that you created.

Both methods have the problem that the editing user would not know this has to be done.

I still wonder why we are doing all this encoding and decoding anyway. As far as I could determine text inside textarea tags is completely displayed 'as is', there is no interpretation of HTML tags or escaped characters. The only thing that is interpreted is a closing /textarea tag. (Just like the only thing you cannot have in embedded JavaScript is a closing /script tag, not even between quotes!) So to minimize the possibility for unwanted side effects it would be better to only encode and decode that closing /textarea tag for editing. Even if a user would not know about this encoding, and type a normal /textarea tag, this would then not be recognized by the decoding (which only hunts for encoded tags), and end up in the database exactly as he wants.

I'm now seeing draggable pieces, and as a test, I did drag a Knight to the board. However, the pieces are very far away from the board, and I have to slowly scroll the page to drag the piece to the board. I presume these areas should be nearby each other, as that would make dragging pieces to the board much easier.

As I understand it now the function htmlspecialchars() acts on what is in the database to display it in a HTML textarea. And when this text is submitted htmlspecialchars_decode() reverses the substitution. This indeed should not surreptitiuosly alter untouched text in the database. So I still don't understand how this could have led to corruption: ... It seems like htmlspecialchars_decode() has been acting twice on it

To check on this, I first ran a script that called htmlspecialchars and htmlspecialchars_decode alternately, and then called htmlspecialchars_decode twice in a row. Calling them alternately did no damage, but calling htmlspecial_chars twice in a row did. I then tested the submission scripts with the same text I had used in the test script, and it displayed like it would with two calls to htmlspecialchars_decode.

Through some testing, I determined that submitting a form does an implicit call to htmlspecialchars_decode. So, I removed the explicit calls to that function. I also determined that not calling htmlspecialchars on the text that should be displayed in a TEXTAREA will modify it. So, this is form behavior and not CKEditor-specific behavior. In light of this, I changed the scripts to always call htmlspecialchars before displaying text in a form and to never call htmlspecialchars_decode. With these changes, you should be able to use HTML entities without them getting corrupted.

However, the pieces are very far away from the board, and I have to slowly scroll the page to drag the piece to the board. I presume these areas should be nearby each other, as that would make dragging pieces to the board much easier.

Indeed, the table should appear just right of the board. But the same thing happened here: the text of the article described what one has to embed in a HTML page to make the piece table appear there. This was upgraded by the double decode to an active element interpreted by the browser, and as it appears before the intended active element in the Wizard the table now appears there.

I now repaired the &lt; in all places that could confuse the script by mimicking an anchor for inserting a 'satellite', and that appears to fix it: the piece table now appears in the intended place, and I can now perform all steps of the Wizard up to the end.

To get back to the membersubmission scripts: I have been toying with one of those (the wrong one, but it was one I could easily invoke), in order to try to include some help for creating an article in HTML with an Interactive Diagram in the Setup section and a nicely formatted verbal description in the Pieces section. It is more like the Play-Test Applet than like the Wizard here, but unlike the former it also allows control over graphical appearance (square colors, piece images). The basic principle is still to move pieces from the adjacent table (which adapts to the chosen image set) to a board (first adjusted to the desired size). Once done pressing a button fills the Setup and Pieces sections with a proposal for the HTML, which can then be fine-tuned by manual editing.

To see it in action you can use Edit Page on an article (which invokes the membersubmission2a.php script), and then change the word 'member' to 'hgm' in the address bar to use the modified script hgmsubmission.php (keeping the CGI arguments of the URL). Of course you should be careful not to actually safe anything when using this on an article that already has Setup and Pieces sections, as it would overwrite these with what it cooks up itself.

BTW, in order to make this work I had to adapt the list.php script that was in various directories with piece images (that also contained an index.html file) in order to get a directory listing of the available images. This script no longer could be used: 'cross origin policy' apparently forbids access to other directories than the one the original page was loaded from (/index), even if these are on the same server. So to know which piece images are present in a given directory (for creating the table) I had to put a script (hgmget.php) in the /index directory, and make it such that it accepts as an argument which directory you want the listing from. Perhaps this should still be made a bit more critical in what you are allowed to list (e.g. only subdirectories of graphics.dir and membergraphics/*), but my knowledge of PHP was not good enough to do that.

P.S. Indeed I needed no tricks anymore for making the &lt; for < replacement for removing the false anchors, so the system appears to work now.

Can you add Interactive Diagram to Horizons please?

Well, you can edit your own submissions, right? And there are already 3 such Diagrams using different piece themes you can choose from to copy.

the modified script hgmsubmission.php

I took a look at this, and I liked how it did some things better than the other wizard. Between them, I got a Chess diagram that mostly looks and works how I want it. See my new Chess page for the diagram.

When I tested the page in Firefox's Reader View, I got an empty grid, and when I tested it in Firefox's Print Preview, I just got the coordinates around the sides without the grid lines. Ideally, the diagram should always display the board.

As for building it right into the submission form, I would prefer to not do that, for I have a competing tool, and I don't want to leave the impression that we're expecting people to make Interactive Diagrams. Also, each requires a different skill set, and each has different capabilities. However, I did rewrite the text to include a link to your page for making Interactive Diagrams.

I got my diagram to play Chess with the AI, but there were some issues.

1. It allowed me to make various illegal moves, such as moving to any empty space, capturing a piece with a non-capturing move, and capturing a piece in a piece's line of movement even though movement there is blocked.
2. When I checkmated the King, it did not recognize this and just made an illegal move instead.
3. When I captured the King, it still continued the game.
4. When I captured all pieces except one blocked Pawn, it said Thinking.
5. It then let me make two moves in a row to capture the remaining piece, at which time it said "It seems I have already lost!"

I got my diagram to play Chess with the AI, but there were some issues.

1. It allowed me to make various illegal moves, such as moving to any empty space, capturing a piece with a non-capturing move, and capturing a piece in a piece's line of movement even though movement there is blocked.
2. When I checkmated the King, it did not recognize this and just made an illegal move instead.
3. When I captured the King, it still continued the game.
4. When I captured all pieces except one blocked Pawn, it said Thinking.
5. It then let me make two moves in a row to capture the remaining piece, at which time it said "It seems I have already lost!"

Some of these issues are caused by the fact that the Diagram definition contains the line royal=1, which designates the Pawns as the royal piece (as these were the first piece in the table). So it only considers the game lost when it runs out of Pawns (as the default is extinction royalty). The royal parameter indicates which piece type is royal, not that royalty plays a role. Some variants have multiple royal types (and would need multiple royal= parameters). By default the last mentioned piece would be considered the royal (here: King). To switch off royalty you would have to mention a non-existing piece type (e.g. royal=-1).

That it is does not enforce legality (or even turn order) is intentional, to make it easy to set up positions. The purpose of the Diagram is not primarily to act as an opponent, but also to get an idea for how pieces move. Especially for (multi-)hoppers and locusts it is difficult to understand the move from a static move diagram. There actually exists a parameter that can make the Diagram enforce legality, but that would severely hinder these other functions.

The Interactive Diagram is primarily designed as a replacement for the wooden chess equipment people woul have at home (but not with the desired board size or number of available pieces); such boards also do not complain when you make illegal moves.

I set royal to 6, and it works much better now. However, when I checkmated Black, it resigned instead of saying that I had won by checkmate.

As for building it right into the submission form, I would prefer to not do that, for I have a competing tool, and I don't want to leave the impression that we're expecting people to make Interactive Diagrams. Also, each requires a different skill set, and each has different capabilities. However, I did rewrite the text to include a link to your page for making Interactive Diagrams.

I think it would be helpful to contributors to put some assistance for diagram creation in the submission form, no matter what type of diagram is used. Especially when this is helpful in generating other standard sections of the article as well, such as a nice table with verbal descriptions of the piece moves, accompanied by the image of the piece in question. Not everyone would know how to make such a table, and even contributers that do know might consider it too much of a hassle.

If there are alternative tools, so much the better. The submission form should and could support all available tools. Just as the form provides a pull-down menu for selecting whether you want to use plain Text, HTML or Markdown, we could have a switch that enables the user to specify whether he wants to include an Interactive Diagram (ID) or an image link to the Diagram Designer (DD). In fact I think he would always have to use the DD: the site policy is such that we want the website to also be usable with JavaScript turned off, and under those conditions the ID would not work. In every article where I included an ID so far I have always done it such that a static image (or DD link) was present in noscript tags, and the ID started hidden, and would require JavaScript operation to make it visible.

The point is that we should mentally separate what will be included in the article from the interface that is used to specify it. The trial submission form I made could be made to generate a link to the DD, and place it in the Setup section, just as easily as it now does for an ID. In fact even when the user would specify he wants an ID it should do both: the DD link in noscript tags, plus a hidden ID and a small JavaScript section to make it visible. If the user selects a DD image for inclusion, it should only place the DD image link in the Setup section, without any noscript tags.

Note that the ID script as I normally use it actually does two independent things: it generates a diagram according to specifications when the user loads the page, as a HTML table with all kinds of event handlers attached to the table cells. And it contains the code for the event handlers, which is invoked when the user starts playing with the diagram. These functions can be separated: the HTML table could be generated at submission time, so it gets stored in the database and downloaded by the client used to view the page. Even with JavaScript off the Diagram would then always be visible; it would just not react to mouse clicks anymore. I never do that, because the ID definition is far smaller than the HTML code for the table that it will create. (But even that would probably be smaller than a whole-board PNG or GIF image of the initial setup.)

For the HTML elements that are not part of the ID per se the submission page already uses the 'create at submission time' strategy: it fills the Pieces section with HTML code for a table with piece descriptions, rather than just putting an empty HTML element (like div) there, and letting the script fill it after the user loads the page. Because we want that table of pieces to appear on the page even when JavaScript is switched off. But also because for really complex pieces the automatically generated verbal description might not be satisfactory, and to give the user a possibility to fix that by editing.

However, when I checkmated Black, it resigned instead of saying that I had won by checkmate.

Well, being checkmated seemed a good reason to resign!

But seriously: not all chess variants have the same winning condition (checkmate, stalemate, king capture, baring, reaching a goal square). Currently the Diagram only knows by the score returned by the search that it has lost, and it cannot see for what reason. So I made it print a universally valid message. The problem still exists when it wins, though; then it says 'checkmate'. Which sounds really stupid when the win was by another method, even stalemate. I could of course have it print 'I win'. But it already does that when it captures the King. And for some variants the goal actually is King capture. So checkmate would then not yet terminate the game (so that 'I win' would be incorrect); it would just be an announcement that it will force a win in the next move. For this reason you can always play on even when checkmated.

When I tested the page in Firefox's Reader View, I got an empty grid, and when I tested it in Firefox's Print Preview, I just got the coordinates around the sides without the grid lines. Ideally, the diagram should always display the board.

This is really strange. (But it also happens for me.) Because the coordinates are something that is generated at load time, just as the rest of the diagram. I could have understood it when it would have printed no diagram at all, or just the definition of the Diagram. That would mean that it is printing the page as it looks in Page Source. But it must have been running the JavaScript to get those coordinates. But not completely, or you would have seen the rest of the Diagram. Perhaps the JavaScript chokes during display of the position, because some HTML elements it tries to refer to are no longer present on the Print Preview page.

This is actually a bad problem, as it means that all pages I put Interactive Diagrams in have become unprintable. (In FireFox. I don't know if other browsers behave the same.)

One solution would be to provide a link/button on each such page to switch it to a special printable version. E.g. as if JavaScript has been switched off, using the static image of the setup. This could be done by not putting that image in noscript tags, but in a DIV section, which would be hidden by the JavaScript at the same time as it creates the Interactive Diagram and makes that visible. And have the 'Printable Version' link reverse that.

[Edit] I noticed that the message you currently print at the top of each page ("The site has moved...") in the Print Preview is printed with black text on a white background, while on the page it was on a black field. So it seems that the Print Preview is stripping style attributes and enforcing its own style to HTML elements. That explains the disappearance of the table borders and board checkering. It also explains the disappearance of the pieces: the Diagram renders these as background to the table cells (so that the highlighting markers can be displayed on top of them as cell content). Background images are also a style. Indeed, when I select a piece in the Diagram to get its moves highlighted, and then ask for the Print Preview, the highlighting markers are visible in the Preview.

[Edit2] Chrome behaves similarly, except that it does keep table borders (so that grid lines remain visible in the Diagram).

I'm working on a solution for printing and for when JavaScript is turned off. These days, I can turn JavaScript off only with the NoScript extension, and ironically, it also disables the <noscript> tag when I disable JavaScript. My alternative is to use a DIV with "noscript" as a class. On my Chess page, I have some JavaScript in the Notes section that will hide anything with this class. So, it shows up only if JavaScript is not running. That section of JavaScript also turns on the display of the "idiagram" class, which I have previously turned off with a section of CSS. This stops it from displaying when JavaScript doesn't work. For printing, I am using the "noprint" and "printer" classes. With the "printer" class, I have a static image of the board. This class is initially hidden, and CSS turns it on for printing. So that I don't get two board images when JavaScript is turned off, this board image is written to the page with JavaScript. Also, I have added the "noprint" class to the DIV with the "idiagram" class, so that it gets hidden while printing. I'll see how I can streamline this later. For now, I have two images on the page with the interactive diagram, one for printing, and one for when JavaScript is turned off. Each is slightly different to tell them apart and to see that it is indeed working. Unfortunately, none of this helps with Reader mode. However, our pages are not so cluttered with ads that Reader mode should become necessary.

Later plans include modifying the display_comment function to convert <noscript> tags into <DIV CLASS="noscript"> tags, to move the CSS into the header or a .css file, and to move the JavaScript into the footer.

I don't completely grasp the ramifications of all this yet. But a point of concern could be this: an Interactive Diagram on a page does not always exert its effect only within the elements of class="idiagram", but can have 'satellites' embedded in the text elsewhere on the page. E.g. for creating a clickable list of the pieces as an UL or P element, creating the piece table (that you can normally open under the diagram) in another place so that it is in permanent view (for when the variant involves drops or setting up an initial position), or a table with verbal descriptions of the piece moves.

In the Diagrams I inserted in articles I often used a two-cell table, with the Diagram itself in the left cell, and the clickable list of pieces in the right cell. When JavaScript is off, I wanted that entire table to disappear. I did this by starting the table in the display:none style, and including a script on the page that called the OpenDiv() function in the betza.js file to make it visible. But that table did not have the idiagram class. So it might be difficult to automatically decide what should be hidden in print mode. We might have to explicitly go through all pages with Interactive Diagrams to surround the parts we want to disappear with class="noprint" DIV tags. 

I streamlined it to work with only one static image in <div class="noscript"> and to use only the "idiagram" and "noscript" classes. This way, no new elements have to be added to existing diagrams.

As a test, I displayed the Print version on the page, and it did not show up at all in the Print Preview. When I had tried this earlier before hiding idiagram during printing, it showed up with missing elements in Print Preview. Since it's not suitable for printing, I would suggest calling it something other than Print. Then we can hide it during printing without getting complaints that it is not printing. I was testing this with Eurasian Chess, and you can get the background colors and pieces printed if you select the "Print backgrounds" option in the Print Preview.

Speaking of Eurasian Chess, that game uses a background for the main image, but it doesn't for the individual piece diagrams. It seems like it should, though.

I modified the settings of NoScript to show the contents of <noscript> tags, and an interactive diagrams can be printed when "Print backgrounds" is selected. So, the problem I was trying to solve is not as big of a problem.

However, other users of NoScript might not think to modify its settings, and someone could miss the "Print backgrounds" option in Firefox. Also, it's nice to not see the text for the interactive diagram settings when viewing the page without JavaScript. So, I'm still thinking about making these changes, though I'm not in a hurry to do it.

One consideration is that these changes could prevent the print version of an interactive diagram from printing. This is fine for the Chess page, which has descriptions and diagrams for all the pieces in the pieces section. But some pages might not include all this information on the page itself.

It seems there is a bug affecting certain XBetza moves enclosed in parentheses that prevents their highlights from displaying properly. For example, this bug will show up after executing the following moves in Suzumu Shogi's interactive diagram:

1. HFmm11 HFxm12xm13+

After promoting the Falcon to Bishop General (XBetza (cmpaf)2cBmcB), click on it and then click on the Lance in the corner. If done right, the highlights for the second part of the move will not show up at all.

The bug seems to be coming from this line in the NewClick function:

        var h = hlights[k], victim = board[h[1]][h[0]], col = ((h[3] & 3) == 1 ? h[3] & 64 ? '#00C000': '#00FF00' : h[3] & 64 ? '#C0C000' : '#FFFF00');

Any help fixing this would be greatly appreciated, as I could potentially reduce the length of the most complicated Suzumu piece's Betza strings significantly.

I didn't have time to actually debug this, but the m in (cmpaf)2cB  is asking for trouble. This is like describing a plain Bishop (on 8x8) as (maf)7B rather than just B. You would get exponentially many paths to a distant destination, because it tries to use all intervening squares as intermediates to step on. So you could go from a1 to h8 in 64 different ways, which are all completely equivalent. I suppose that NewClick gets confused by this: it highlights the Lance in cyan, indicating that there are multiple moves to or over it. But then it turns out there is no way to resolve the moves by an additional click.

With just  (cpaf)2cB each leg would automatically skip all empty squares, and you could fly over up to 2 pieces, optionally capturing the enemies. And it would be able to do that only in a single way, each leg going from one occupied square to the next.

There could be a problem in combining destuctive modes with non-destructive modes in non-final legs. Although I am not sure if that is also the case with NewClick.

Yes, using cpaf instead of cmpaf does work, but only if it used once. (cpaf)2cB only covers a subset of the moves that (cmpaf)2cB covers. Remember, the p and a modifiers exclude the m modality if only c and/or d are specified in the modifiers immediately before it, per their definitions. Thankfully, this problem can easily be solved by writing the missing legs separately, yielding B(cpaf)2cBcafpafcBpafcafcB. Longer for sure, but it won't have the same search explosion problem, at least for the (cpaf)2 part. The other two multi-leg parts may have search explosions since paf is (usually) equivalent to mpaf (which can lead to the same problem as before), but they will be much more subtle explosions since paf is only used once.

I will update the diagram at the page I used to demonstrate the Suzumu Shogi BadZone bug (which can be found here) to include this bug, for future reference.