I'm not sure how you intend to merge move rejection, game termination, mandatory promotion, and offering promotion choice, into a single function, unless JS allows you to return a value that could be one of many different types.

This is exactly what JavaScript allows. It is a 'typeless language', where any variable can hold, or any function can return any type of data structure. Move rejection and game termination go through numeric codes (BadZone does that now, 1 for rejection, 0 for allowed, -1 and -2 for termination), forced promotion or a choice request as well (by WeirdPromotion, returning the piece-type number or 1000). It would be easy enough to rearrange the numeric codes such that they do not collide. It is just that when you request promotion choice, it uses the same procedure as when you enter the zone, controlled by promoChoice or promoOffset. Here it would increase flexibility if I allowed returning a character string or (more efficiently, but perhaps less user-friendly) the array that such a string would parse to when given as promoChoice. (Such an array would be indexed by piece type, and contain a non-zero value for each piece type that in principle can be chosen. Where 2 means 'if available in the holdings', and 3 means 'not on last rank'.

I understand that it will never be possible to handle everything by parameters. But the main point is that I don't want to realease on afficial specification for something I would have to change later. That would load the whole project with an obligation to remain backward compatibility for the legacy features. Now in this case it would probably not be so hard to maintain such compatibility: I could switch to a usiversal Custom() function that takes care of everything, only invoked when no parameters (such as morph or captureMatrix) are specified that require use of the standard function, and the user specified a legacy BadZone() or WeirdPromotion(). This Custom() function would then call the latter two, and integrate their return values into the new format. This Custom() could just get the complete move description used by the AI passed as an array.

It seems that the holdings do not work correctly. Whenever holdingsType is set to anything other than 0, for each piece, it subtracts the amount on the board from the amount present at the start of the game rather than showing the actual amount in the hand. Also, setting holdingsType to -1 does not change the color for Shogi drops like it should.

This is an area where I changed a lot, lately: in the past the AI was not updating the hand at all, and when the MakeMove of the AI was also used for the user move this was no longer tolerable. But to avoid slowing down the AI by figuring out whether to flip color, I now always store captured pieces in the hand of the previous owner. Then for holdingsType -1 the drops (which the AI currently does not consider at all) have to flip the color. Apparently I did not convert the code to this new system in all places. I will have a look at it.

[Edit] Should be fixed now. Turned out I had actually been too enthusiastic spreading around code that would swap the color of the holdings element that was used. Another interesting bug was that the black holdings were increased by concatenation; after capturing two pawns you had 011 in hand! This resulted from applying mirror symmetry to the initial holdings count, where I forgot to swap in the element being copied. Apparently undefined is considered a string in JavaScript, so that undefined + 1 gives '01' rather than 1.

It is now fixed.  However, I also noticed that promoted pieces are affecting the hand when they shouldn't, particularly for Shogi-style promotions (increments original, decrements promotion).

However, I also noticed that promoted pieces are affecting the hand when they shouldn't, particularly for Shogi-style promotions (increments original, decrements promotion).

I guess I should only take promotions from the hand for chess-style promotions where promoChoice says the piece comes out of the hand (by prefixing its type with an asterisk).

[Edit] This is implemented now, both with the old and the new move-entry system.

The advantage of the new move-entry system is that you can actually see what the AI would have done in its search, so that bugs becomemore easily apparent.

Nice.

It seems that the new move handler isn't updating the part of the diagram that shows which piece is selected.

It seems that the new move handler isn't updating the part of the diagram that shows which piece is selected.

Ah yes, it wasn't. I now fixed that too.

Help!

I edited the Interactive Diagrams article to describe the new 'background' parameter, and this completely destroyed the Design Wizard in the Notes section (which I did not touch). What happened, and why?

The Revisions for this page also look very strange, pegging loads of revisions to the same timestamp 2022-11-27 12:54:56. None of them load the wizard for me, but I'm on mobile right now.

The insert statement does not include the timestamp. It relies on MariaDB using the current_timestamp() function to fill in the value. So, I'm not sure why multiple revisions would have the same timestamp.

H. G., give me the revision number for when it worked and for when it was completely destroyed, and I will look into it. In the meantime, you may revert it to the revision that last worked.

Fergus Duniho wrote on 2022-12-08 UTC

H. G., give me the revision number for when it worked and for when it was completely destroyed, and I will look into it. In the meantime, you may revert it to the revision that last worked.

Well, when recalling old revisions the Design Wizard button never seems to do anything, so I guess it only works in the context of a real page. There is one problem that sticks out when I try to edit the current page, though: it has a < character in the text of the Notes section near the end, which the CkEditor sees as the start of a HTML tag (and consequently completely messes up the indentations, as this imaginary tag is never closed). Originally this < character was embedded in the text as the HTML escape &lt;.

If I look at the page source, that same < is also in it in unescaped form, and my first guess is that this is what cuts off most of the Design Wizard when it gets opened. (Initially it is on the page in display:none style to hide it untill the button gets pressed.)

The (spontaneous) replacement of the &lt; by < occurred from revision #7441 to revision #8100.

I would hate to lose the edits that I have made since then, though, especially since it is likely not possible to edit it through the usual form without the same corruption occurring again too. If we are lucky repairing the latest version might just be a matter of restoring the < to its original &lt; form. But to be able to do that the submission script would have to be repaired, otherwise it would just replace it back on submission.

H. G., Try switching to the Text format. Your HTML will still work, but it will not use CKEditor, and it will not run the functions that undo its formatting.

H. G., Try switching to the Text format. Your HTML will still work, but it will not use CKEditor, and it will not run the functions that undo its formatting.

OK, I tried that, but it makes no difference. I even tried switching JavaScript off during the edit, so that I am sure nothing can be done to the text in the browser client. I replaced the offending < by &lt;, and after I resubmitted the page still has a < at that place (as seen in the Page Source).

The problem must be in the PHP script that processes the submitted form.

I replaced the less than sign in the text with the words "less than", and I replaced some less than and greater than signs in your JavaScript with String.fromCharCode(60) or String.fromCharCode(62). But when I click on your "Start Design Wizard" button, all it does is hide or display a block of text. Looking at the source code for the page, I don't see any structural problems with the JavaScript. But I am too unfamiliar with your code to tell whether there might be a bug.

Well, hiding or displaying a piece of text is all the button is supposed to do. Except that this text should also contain many HTML input elements (check boxes and text entries) that the user can then operate to specify the Diagram he wants to create. I guess the text block in that gets opened is just more damaged than was easily visible in the revisions compare. The problem with that particular compare is that nearly everything changed because it was messing with indentation, so that you can no longer see which of the things that matter were changed.

I see that some other sections contained < characters in their text (as part of HTML code to be shown to the user, which is now converted to HTML code that is actually interpreted by the browser. These are now all corrupted as well. E.g. leading to a false Diagram in the 'Embedding' section, which only intended to show how to embed a Diagram.

I don't think there is an alternative to displaying actual < characters in the text of the aricle; If I write "write the diagram between less than div greater dan less than /div greater than tags" no one would understand it. Text containing such characters must remain editable, as they always have been. The current submission system is badly broken. It should not of its own accord replace escape sequences such as &lt; by the characters they stand for; the very reason the text would contain the escape sequence is that the plain character would be harmful in that context.

I can imagine that it is necessary for correct display in the edit boxes that characters with HTML significance must be escaped in those boxes. And that this escaping has to be reversed on submission, so that in the end texts that were not modified remain the same in the database. But if this was done correctly it should not lead to the observed effect, because & itself is a character with HTML significance, and would be escaped as &amp;. So the combination &lt; in a text in the database should appear as &amp;lt; in the edit boxes, and on submitting be converted back to &lt;. Not to <.

Your HTML is using the ID of 'wizard' twice, once for a P tag and once for a DIV tag. Each ID is supposed to be unique, though. It looks like your button is showing the text in your P tag while ignoring what's in your DIV with the same ID. Make sure you use the 'wizard' ID only once and that you use it for what you want to show up when someone hits the button.

Also, I fixed a bug in the scripts. While transitioning from $useshtml to $format, I left both variables in some conditionals. I have now removed $useshtml from those conditionals, and with that gone, the Text format should now work without modifying anything. Just be sure to not use the TEXTAREA tag in your code, and you should be okay.

Your HTML is using the ID of 'wizard' twice, once for a P tag and once for a DIV tag.

Ah, good catch! I added that ID for the P tag very recently, when adding a 'table of content' to quickly go to the desired section, because the article was getting too long for comfort. But I had not realized the 'wizard' label was already in use. As in cases like this the browser (or at least FireFox) only recognizes the first occurrence of the ID, the button was operating on the wrong text section.

The problem that escaped characters like &lt; are replaced by the character they stand for on storing (or retrieving for viewing?) from the database still exists, though. So it is still not possible to repair the damage to the 'Embedding' section. (Both with JavaScript on and off.)

Since you're an editor now, you could do this as an .html page. Once you get it working that way, we could test whether posting it through a form adversely modifies it in any way.

Fergus Duniho wrote on 2022-12-09 UTC

Since you're an editor now, you could do this as an .html page. Once you get it working that way, we could test whether posting it through a form adversely modifies it in any way.

Indeed. Or I could edit it directly in the database.

But the goal is to improve this website, right? Not to break it down piece by piece, and then make users editor so they can fall back on low-level features for doing what is needed because the regular methods for doing it no longer work.

Having the standard method for editing by ordinary contributors not corrupt the data doesn't seem such an outlandish requirement. In fact it has been working without causing any problems for several years. So a more logical solution would be to revert to that situation. We should not apply 'cures' that are worse than the disease.

Did you miss the second part of what I said? Having code that we know works in an .html file would give us a basis for figuring out what needs to be fixed. Once you have working code in an .html file, I could compare that code to what gets saved to the database and to what gets displayed with msdisplay.php and see if there are any important differences at either stage.

I created a new shortcode called chr, which can be use to display the indicated character. When given a number, it will display the character with the provided ASCII value if it's printable. When given text, it will place it between an ampersand and a semicolon to create an HTML entity. Since shortcodes work only at display time, its use will not affect what is stored in the database. I replaced the less than sign in the HTML with a shortcode that will always display it with the HTML entity. However, I never saw it actually display this part of the HTML. I also removed some tags at the end of Notes that more properly belong in a header or footer, since they were messing up the footer and seem to serve no function.

After it says "This requires an element", there was a gap, and it looked like you meant to display something instead of running it as code. So, I used chr shortcodes to display the appropriate HTML entities at display time, and now it shows up as text.