[ Help | Earliest Comments | Latest Comments ]

[ List All Subjects of Discussion | Create New Subject of Discussion ]

[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments/Ratings for a Single Item

⇧Earliest ⇧Earlier ⇧Reverse Order⇩ Later⇧ Latest⇩

Interactive diagrams.

Diagrams that interactively show piece moves.[All Comments] [Add Comment or Rating]

💡📝H. G. Muller wrote on Sun, Jul 9, 2017 08:09 AM UTC:

> Diagrams don't seem to work anymore, just code appears!

Is this still the case now? It could have been due to an update of the browser you use, which prevents it from using .gif files as JavaScript sources. Initially the JavaScript powering the diagram was uploaded as a .gif file, because the CVP software did not allow me to upload .js files. But the Chrome browser did not want to use the .gif file from the very start, and Fergus then copied the .gif file to a .js file, and altered the upload scripts so that I could update that. But recently the diagrams that were still using the .gif file also stopped working for me in FireFox, and became active again when I changed them to use the .js file. The diagram creator now also will refer the .js file rather than the .gif file in the diagrams it creates.

Aurelian Florea wrote on Sun, Jul 9, 2017 09:35 AM UTC:

Hello and welcome back, H.G. long time no see.

Unfortuneatly diagrams don't seem to work at my end, I can't figure out why.

Moreover I'm moving to another city these days and I can't get back to you early.

Anyway talk to you soon.

P.S. Off topic HG if you have the time take a look on my two published apothecary games, as you were a influence in their desing!

💡📝H. G. Muller wrote on Sun, Jul 9, 2017 10:19 AM UTC:

Yeah, I was very busy with other stuff (such as writing an engine for Tenjiku Shogi), and I semi-lost the password Fergus had assigned me last time when logging in was impossible, (and I of course forgot because it was not my usual one) while attempts to get a new password ran into error messages only. Eventually I managed to find the e-mail with the password again, and once logged in, was spontaneously asked to change it (which did work, so that now I again have a my usual password).

> Unfortuneatly diagrams don't seem to work at my end, I can't figure out why.

I am not sure what you mean by 'at your end'. Is this for diagrams that you created yourself? Or is it even impossible to see the diagrams here on the website? (E.g. the one of Caissa Brittania my previous post links to, or that in the article about Macadamia Shogi.) What browser are you using? Is JavaScript enabled?

Aurelian Florea wrote on Sun, Jul 9, 2017 10:56 AM UTC:

Caissa Britania works, I've just checked. Omega chess doesn't. Also the diagrams on my hard drive don't work. I use Mozilla Firefox 52.02(32bit). Java script is enabled. Macadamia shogi works, nice game by the way, I've just noticed it!

💡📝H. G. Muller wrote on Sun, Jul 9, 2017 11:31 AM UTC:

Omega Chess should work now too. Funny thing was that when you clicked the 'View' link at the bottom-right to see the comment in isolation it did already work. Problem was that I referred to the JavaScript file through a relative path "../membergraphics/MSinteractive-diagrams/betza.js". But the Omega Chess page is apparently in another place of the CVP file-system tree, one level deeper than usual (/large.dir/omega/rules.htm), so that this was not correct on the rules page. I now used an absolute path by removing the leading "..".

I guess I never tried to see the diagram on the pages of the articles themselves. When you post them, after seeing the preview, you are routed to the total comments listing, and there you would also see it in a context where the path name would be correct.

As for the diagrams on your hard disk: where does the link in the <script> tags point to? If it points to a betza.gif instead of a betza.js file, this would explain why it doesn't work.

I have now checked out all diagrams I could remember having made, and they all seem to work (in FireFox, at least). As a demo for the various things that can be done with the interactive diagram, I listed links to all of these below:

In comments to existing chess-variant articles:

Variants of my own design using an interactive diagram in their article:

Historic Shogi variants for which I wrote an article using an interactive diagram:

sirius628 wrote on Wed, Aug 30, 2017 03:50 AM UTC:

Hey, my diagram won't work. Could you help me? The code that I used is below. I am using my own uploaded images, just so you know.

💡📝H. G. Muller wrote on Wed, Aug 30, 2017 06:39 AM UTC:

It does not like spaces in front of the key-words / piece names. I am aware that the new editor adds those automatically, every time you open the text-to-be-edited in source mode, which is extremely annoying.

Don't worry about it; I will fix the diagram script so that it automatically strips leading spaces from the diagram definition, and then your diagram should work again. Editing of comments that contain a diagram will still be a disaster, though; it seems that editing source there doesn't let you edit the original source, but instead tries to reconstruct a source from the displayed text, in which process it completely destroys the diagram definition. But submissions with diagrams can then be edited without tricks.

[Edit] Leading spaces should now be ignored. Please test if this solves your problem. Don't forget to reload the page with Shift pressed to flush the old betza.js script from the browser cache.

sirius628 wrote on Wed, Sep 27, 2017 11:58 PM UTC:

I have a few questions.

Is it possible to describe pieces like the Rose or Crooked Bishop using this notation, which doesn't support the "q" or "z" modifier? Same goes with cylindrical piece
What is the "j" modifier supposed to do?
Can you merge multiple cells together for a masonry pattern?

sirius628 wrote on Sat, Sep 30, 2017 03:50 PM UTC:

The interactive diagrams are completely broken. If you click on a piece, none of the squares are highlighted, and clicking on the target square does nothing.

💡📝H. G. Muller wrote on Sat, Sep 30, 2017 06:26 PM UTC:

Thanks for warning me. It should work again, now. When I added the interface with the engine two variables were not declared in the diagram script, but in the page that defined the diagram on which I tested. So it did no longer work with the existing pages. Now I declare those variables in the diagram script.

As to your earlier questions: 'q' and 'z' are not yet implemented in the Betza compiler. I did not kow any variants that featured Rose or Crooked Bishop. Do you have need for them? 'pp' For multi-hopper (which I would need for Tenjiku Shogi) is also not implemented yet.

As to 'j': In the original Betza notation this is ill-defined for oblique moves, like its counterpart 'n'. You would not know to which square(s) it appies. It also seems redundant; e.g. a Dababba that must jump ('jD') can also be written as a hopper with range 2 ('pR2'). In XBoard's XBetza implementation I overloaded the 'j', giving it a different meaning on atoms that do not move 'over' any squares, like W and F: on sliders using such steps the 'j' would mean they skip the first square ('ski-slider'). This is just for conveniece, as it can also be written with the aid of the 'again' modifier: a Ski-Rook would be 'ygaW', meaning that after a first Wazir step it toggles range to infiniteboth on an empty square ('y') as on an occupied one ('g'). But 'jR' looks less obscure.

On the 'O' atom XBetza uses for castling, a 'j' would mean to skip one file when looking for the castling parter starting from the corner. So 'sjO2' would mean castling not with the corner piece, but with the pieces one step inward (i.e. the Knights in FIDE). Omega Chess needed this. But the diagram uses a kludge for this: it always allows castling with a piece that moves like a Rook. So in the diagram I currently ignore the 'j'.

sirius628 wrote on Sat, Sep 30, 2017 08:12 PM UTC:

Chess on a Really Big Board uses a Rose, and Golden Age Chess on a Really Big Board uses both Rose and Crooked Bishop. Also, the "j" doesn't work. Writing "jA" or "jD" just gives me a regular leaper.

💡📝H. G. Muller wrote on Wed, Oct 4, 2017 03:31 PM UTC:

Well, that is what I said: j was still ignored. But I implemented it now. (Be sure to refresh your browser cache!) The results are undefined when used on oblique atoms, however (like jN). And on G and H atoms it forces jumping if there is a piece on one or two of the overflown squares. Before stepping atoms (W and F) or their derivatives it means they ignore the first square on their path. So jB and jR are Ski-Bishop and Ski-Rook.

[Edit] The q modifier now also works. It always rotates 45 degrees per step, even for orthogonal or diagonal atoms. There is no way yet to indicate direction of curvature; it always bends in both directions for a given start direction (such as fqW4). The Rose is qN or qNN.

[Edit2] Same for z now. It turns 90 degrees in alteratig directions. Also here the trajectory that starts bending right always occurs together with the one that starts bending left after the same first step.

graphicsDir=/membergraphics/MSelven-chess/ whitePrefix=w blackPrefix=b graphicsType=png squareSize=35 files=15 ranks=15 symmetry=mirror pawn::::a2-o2 jumpingAlfil:A:jAmW:elephant:c1,m1 CrookedBishop:B:zB:crownedbishop:b1 Rose:R:qN:rose:n1 king::::h1

sirius628 wrote on Fri, Oct 6, 2017 02:38 PM UTC:

There's still a few problems. The betza parser incorrectly interperets L as (2,3) and J as (1,3), when it should be the other way around. Second, there's something wrong with my diagram here, because the Knight's initial moves (imafN) aren't darkened. Third, your Four Board Chess and Golden Age Chess don't give en passant rights to the pawn. And finally, I would suggest adding Betza's "o" for cylindrical pieces, in addition to "oo" for toroidal ones.

💡📝H. G. Muller wrote on Fri, Oct 6, 2017 04:10 PM UTC:

Ah, good catch. I always use C and Z, because I can never remember which of L or J is the Camel. Fixed now.

As to the darkening of initial moves: the problem was that the i modifier was listed with the first leg, while it was tested at the destination, after the second leg. The diagram should now remember the i setting from the first leg even for multi-leg moves. I had never used initial multi-leg moves; I would be inclined to write the move as imN2. This does overlap with the normal move, however, generating it twice, with as a result that the move specified last will prevail. So the total move had to be written as imN2N to get the desired effect.

As to o for cyclinder and oo for toroidal: done!

I was aware of the e.p. problem; the imW6 move does not automatically grant e.p. rights. Furthermore, the code currently only uses 2 e.p. squares even when rights are granted, at 3/8 and 5/8 of the multiple push. Here up to 5 squares would have to be tested. So I should completely redesign e.p. testing. Also, the imW6 is not really describing the Pawn, as from 3rd rank it would still have W5 etc. This is really not an 'initial move', but a location-dependent move rule. For which Betza notation isn't really suitable. Unless something is invented to mean: up to half the board. (W* ?).

BTW, the q and z modifiers can now be combined with p and g, to get crooked and circular hoppers.

[Edit]I have redesigned the e.p. testing now. It tests all squares the rights-creating piece has moved through. This will work both for forward orthogonal and for diagonal moves. In addition, an asterisk as range now indicates 'distance to the 'River' (i.e. the line separating the board halves) or 1, whichever is larger. So that fW* can be used to indicate a Pawn that can always move up to River (and fF* a Berolina Pawn with such a range). Such a move will always create e.p. rights.

🕸Fergus Duniho wrote on Mon, Oct 9, 2017 09:04 PM UTC:

I frequently access this site with my Kindle Touch's browser, and I have noticed that using a different color to mark which spaces a piece may move to is not very effective on an e-ink device. To illustrate, here is a grayscaled screenshot of an interactive diagram showing how a Queen moves in Chess and a Half.

💡📝H. G. Muller wrote on Tue, Oct 10, 2017 08:40 AM UTC:

Indeed, this is no good. Part of this is Nicolino's fault, by using too dark shades for the normal board checkering; it seems his light shade is already as dark as what I use (and is default) for dark squares. But especially yellow, used to highlight non-captures, is too bright to show up well in grey scales. I guess color coding is not an ideal method on grey-scale devices, unless you are very careful in selecting the colors.

It seems to be difficult to detect if you are running on a grey-scale device from JavaScript. My e-reader still reports screen.colorDepth 16, as opposed to my laptop, which reports 24. Perhaps I should have the diagram use a darker shade of yellow (or perhaps of every color) when running with colorDepth <= 16, assuming most color displays nowadays have at least 24-bit 'true colors'.

[Edit] I have now modified the script to detect colorDepth (after the initial rendering), and adjust the square shades to pure white and very light grey if this is <= 16, irrespective of what the user defined. A darker shade of yellow is then used for 'move or capture' highlights. Ufortuately I don't know how to test if this is satisfactory; I have an old and cheap model Kobo e-reader, it has a browser, but I do not know how to flush its cache. So it keeps using on the old, cached script...

#FFFFFF: Light squares
#E8E8E8: Dark squares (grey scale)
#E0E0E0: Dark squares (default)
#FFFF00: Move or capture (color)
#F0F000: Move or capture (grey scale)
#FFE000: Jump move or capture
#D0D000: Initial move or capture
#00F000: Move only
#00B000: Initial move only
#00FFFF: Locust capture (destination click to follow)
#FF0000: Capture (only)
#0000FF: Capture own piece
#505050: Forbidden King move

It does help a bit that some colors will only be used on empty squares, others only on occupied square. The move-only and move-or-capture colors will only be used on empty squares. While playing on the diagram (locust) capture will only occur on occupied squares. Unfortunately in the move diagrams capture is also indicated on empty squares; perhaps I should switch to displaying a dummy black piece on the target squares in that case.

[Edit] What also helps is to not use checkering of the board at all when displaying a move diagram. I guess there is no need at all for checkering in that case; the checkering is only useful when you are playing, and want to know if a distant diagonal mover now hits one of your pieces. In a move diagram diagonal moves are highlighted themselves.

Another trick I learned: I can safely use floating style for a diagram in a comment, when I put the whole comment inside a 1x1 table. Then it will ever stick out into the comment below it, not even if you open the legend below the diagram. I tried this in the Wildebeest diagram; I needed the floating style to be able to get the pieceList and board in the same view, so that I could touch the pieces in the list and see their diagram appear, as my e-reader as a portrait-shaped screen, and the diagram and list would not fit side by side.

🕸Fergus Duniho wrote on Tue, Oct 10, 2017 01:20 PM UTC:

Looking at your list of colors on my Kindle, #E8E8E8 and #FFFF00 are hard to distinguish from each other, and #E0E0E0, #F0F000, #FFE000, and #00FFFF are also hard to distinguish from each other. There is very little difference between these and #D0D000. Lastly, #00B000, #FF0000, and #505050 look virtually the same. The most distinct color on the list is so dark I can barely read it on my Kindle. On my desktop, it reads #0000FF.

What I had in mind was switching from the use of colors to using some kind of image or images. I figure if you can put a piece on any space, you could also put a marker on a space. By having different shapes, image markers could remain more distinct on a greyscale screen. The one difficulty is that you might not be able to superimpose a marker on top of a piece. The way I got around this in Game Courier was to mark spaces with a border around a piece or space. This worked by changing the CSS for the piece, and it worked on empty spaces by using a small, resizable, transparent gif as the piece image on empty spaces. Another possibility, which I haven't tried out, would be to give each space a background image instead of a background color and to change this accordingly.

Whatever you use, it would be helpful to include a legend that will tell people what the different colors or markers mean. You may know what they mean, but the average visitor who comes across one of these diagrams will not. For example, I just looked at diagrams for the Rook and the Cannon in Metamachy, and the only difference between them is that one used a lighter shade of grey than the other. If you're turning Betza codes into diagrams, would it also be possible to translate these codes into written descriptions that could appear underneath a diagram?

💡📝H. G. Muller wrote on Tue, Oct 10, 2017 02:47 PM UTC:

On my desktop, it reads #0000FF.

That is the brightest pure blue you can get. I guess lowering the saturation could make it lighter. (But the it would be more like the others...) This color is only used for capturing own pieces (and so far I have never had to use that).

Yeah, colors are not ideal on grey-scale devices. Although my e-reader says it has 16 bit color depth, the grey shads 0xFFFFFF and 0xF0F0F0 were absolutely the same. So it is more like it has only 16 shades of grey! Main purpose of this exercise was to at least show where a piece can go at all, and prevent complete masking of it by the board checkering.

The one difficulty is that you might not be able to superimpose a marker on top of a piece.

Indeed, this is exactly what stopped me from doing this so far. before the "interactive diagram" I had "moves at a glance" images, which were just for showing hard-coded moves in a fixed position. I did highlight those with images (of colored dots, which would defeat the current purpose, but of course that ca be trivially changed), and the markers there obliterated the pieces on the square (which I worked around by having the capture marker bring its own black Rook with it).

The way I got around this in Game Courier was to mark spaces with a border around a piece or space. This worked by changing the CSS for the piece, and it worked on empty spaces by using a small, resizable, transparent gif as the piece image on empty spaces. Another possibility, which I haven't tried out, would be to give each space a background image instead of a background color and to change this accordingly.

I only became aware recently that you can have background images. This solution seems technically the best. There could for instance be various patterns of dotting or (cross)hatching. Note that the color system is rather 'luxurious'; because so many colors were available I made distinctions that were not strictly necessary. E.g. empty squares and occupied squares could use the same markers in other meaning; it would not be too illogical to give locust capture and slider non-captures the same markings, as both are moves after which the piece can continue. Also distinguishing capture of own or enemy pieces need not be distinguished: you can see which color piece you will capture.

Another problem is that images of some pieces could be large, not leaving much free space in the square to recognize a background shape. Perhaps it should be done the other way around, using the piece images as background!? Then the highlights would cover the pieces, and could all be small circles / squares / triagles / stars with transparency around them. That sounds exactly like what is needed.

Disadvantage is that piece graphics of different sizes might need different sets of marker images. Although I suppose that when we center the marker images, the can be suitable for a range of sizes. I mostly use 50x50 for large diagrams (Alfaerie or XBoard50), and 33x33 for smaller ones (Utrecht or XBoard33). But currently the diagram can be used for any size, and it would be a pity to lose that property.

Whatever you use, it would be helpful to include a legend that will tell people what the different colors or markers mean.

Well, on grey scales this is just beyond what color highlightig can do, even with a legend. But with shaped markers that is of course different. My feelings about legends are a bit double. For the experienced user their presence can easily turn into an annoyance. They can be made collapsable, but they should not be hidden too well, or novice users would never fid them. Further more, opening them should not push other valuable stuff out of view, or make the elements the user is acting on jump to other places.

Do you have a suggestion where best to position such a legend relative to the diagram?

If you're turning Betza codes into diagrams, would it also be possible to translate these codes into written descriptions that could appear underneath a diagram?

Interesting idea. For the trivial cases, like BN, this would of course be easy ("Moves as Bishop or Knight"). For the Chu-Shogi Lion it would be a challenge, and what it produces might not be very good. (KNADcaKmcabK: "Moves and captures like King, Knight, Alfil or Dabbaba, or captures as King and then again as King in any direction, or passes a turn"). It also depends on how you far you wat to go explaining things. Is "Moves as Alfil or Dababba" acceptable, or must it say "Makes a (0,2) or a (2,2) jump in every direction"?

P.S.: the submission form just tried to trash this comment, by complaining that I must be signed in after I pressed submit buttom in the preview screen. Fortunately I had guarded against that this time, but this is very, very bad! Especially since it tends to happen after you worked on a comment for a very long time...

🕸Fergus Duniho wrote on Wed, Oct 11, 2017 12:36 AM UTC:

P.S.: the submission form just tried to trash this comment, by complaining that I must be signed in after I pressed submit buttom in the preview screen. Fortunately I had guarded against that this time, but this is very, very bad! Especially since it tends to happen after you worked on a comment for a very long time...

This happened to me earlier today. Let's see if I can catch it. I will logout in another tab while writing this.

🕸Fergus Duniho wrote on Wed, Oct 11, 2017 12:37 AM UTC:

That worked after I fixed the addcomment.php script.

sirius628 wrote on Wed, Oct 11, 2017 03:30 AM UTC:

Didn't the leap color used to be more orange? Now it is almost impossible to distuingish from a slide.

💡📝H. G. Muller wrote on Wed, Oct 11, 2017 11:00 AM UTC:

OK, I made some progress. The pieces of the diagram are now displayed as background image, rather than as cell content. Highlighting can now be done through background color, or an image as cell content. For the board checkering, holes in the board, and from-square/to-square highlights it will always use color. But for the move-target highlights I now made marker images with the names of the color that otherwise is used for highlighting this type of move, like "markerFFC000.png". These will then be displayed on top of the piece images.

A few issues remain:

1) The marker images are now taken from the same directory as the piece graphics. This obviously makes it necessary to put copies of them with each piece set, which is annoying. But has the advantage they can be tailored to the piece set, e.g. to the match the size well. I guess the script could be made smart enough to take them from dedicated directories, switching between them depending on the defined square size.

2) The background images are positioned differently in the cells than the content images. The latter had margins, and to prevent board raks from expanding when you moved a piece to an empty rank, the square size had to be chosen a few pixels larger than the actual piece images (e.g. 53x53 for Alfaerie, which has 50x50 gif images). The background image always starts in the upper-left corner, and the cell is then tiled with as many copies of the image as are needed to cover it completely. This means that a few pixels eear the upper and left edge get repeated near the right and bottom edge. Some pieces are so big that they have visible parts this close to the edge, and then you get ugly artifacts rear the latter edges. This can be prevented by defiing the square size exactly equal to the image size (and perhaps make the marker images a bit smaller, and center those, to prevent their margins would cause cells to expand). But all existing images do not have that.

3) On a color display I like highlighting with background colors better. (I think it is more visible. But perhaps this is because I am now used to this.) With grey scales the colors are a disaster, though. So I am probably going to force marker highlighting automatically on displays with a colorDepth <= 16. For other displays it is now subject to a new diagram parameter useMarkers=1. I set this parameter for now in the two most-recently posted diagrama, the comments to the "Betza notation" and "Wildebeest Chess" articles, so people can judge them. For now useMarkers=1 can only be used with the xboard33 piece set (graphicsDir=/membergraphics/MSelven-chess/), as this is the only place where I uploaded marker images so far.

Please let me know if the new rendering method gives any problems on other browsers, and what you think of the current set of markers on color or grey-scale displays.

🕸Fergus Duniho wrote on Wed, Oct 11, 2017 11:38 AM UTC:

I was just checking out the XBetza Sandbox on my Kindle. Some of the markers seem faint, and in comparison with my desktop monitor, the checker includes some yellow circles that do not even show up on my Kindle. Although using different colors for the markers might work well on a color display, it would be best to make them all black on a greyscale display.

Also, the betza2 does not display any moves on my monitor or on my Kindle.

🕸Fergus Duniho wrote on Wed, Oct 11, 2017 01:10 PM UTC:

2) The background images are positioned differently in the cells than the content images. The latter had margins, and to prevent board raks from expanding when you moved a piece to an empty rank, the square size had to be chosen a few pixels larger than the actual piece images (e.g. 53x53 for Alfaerie, which has 50x50 gif images). The background image always starts in the upper-left corner, and the cell is then tiled with as many copies of the image as are needed to cover it completely. This means that a few pixels eear the upper and left edge get repeated near the right and bottom edge. Some pieces are so big that they have visible parts this close to the edge, and then you get ugly artifacts rear the latter edges. This can be prevented by defiing the square size exactly equal to the image size (and perhaps make the marker images a bit smaller, and center those, to prevent their margins would cause cells to expand). But all existing images do not have that.

CSS has background properties that will let you center a background image without any tiling. For example:

STYLE="background-repeat: no-repeat; background-position: center center;"

You could also use the single background property for multiple values, such as background color, background image, background repeat, and background position.

💡📝H. G. Muller wrote on Wed, Oct 11, 2017 01:18 PM UTC:

OK, the marker images were just a flat color, which was a bad idea. I have now given them all a black outline, and have tried to make the inner colors brighter by mixing in some white for the darker colors red and blue. This should now be recognizable against any background.

As to the betza2 moves: the problem is that this piece is defined as a Grasshopper. So it has no moves on an empty board! Which is what the diagram shows, moves of the piece on an empty board. This is very nice for ordinary leapers and sliders, because you see their complete move potential, without anything being blocked. But for hoppers, which acquire moves only because of obstacles, it is not very satisfactory. That also holds for locust capture, which is not possible without a victim being present, but there (like with ordinary captures) the ShowMoves routine at least shows the location where a victim would have to be. But you still cannot see where the piece would end up if it makes such a locust capture.

I don't have any good ideas for how to solve these problems. For sliding hoppers, rather than making the board empty, the ShowMoves function could dump some platforms in their path. But then you would never know if the hopper could have moved beyond those if they had been absent. You can of course hope that if the platform is located far enough from the piece, the suggestion that it is an infinite-range sliding hop is correct. But in the case of a Dababba that mandatorily jumps (jD), you would have to place an obstacle next to it to enable the move, and you would not be able to see or even suggest that there could also be a on-capture to that adjacent square. For locust capture, a piece could have multiple possible targets (a Checker has two), and statically indicating where the piece ends up after such a capture would not reveal which final destination belongs to which capture target. (Think of the Chu-Shogi Lion, or Ultima pieces.)

How about the following?: When displaying the move diagram of a piece on an empty board, the mouse cursor becomes a 'virtual opponent piece'. If the user hovers it over the board, the diagram would be recalculated as if there was an enemy piece on the square he is hovering over. In particular, if he hovers over a square marked as locust victim, it will show where the piece can land after taking that victim. And if the square is in the path of a hopper, it will show the moves of the hopper with a platform there. (Where capture-only destinations are indicated in red even though the board is currently empty, as it now does for divergent normal pieces.)

When pieces get too complex, i.e. their moves depend on too many conditions in other squares, it is just ot possible to illustrate it in a static diagram. This is the whole idea of providing a diagram where people can move around pieces, rather than just responding to clicking on a piece name. They can then set up situations they wonder about, e.g. for the locust capture, to see what happens if they make it. But it is true that the move diagrams makes the user aware of locust captures, while potential hops remain completely 'silent'. Perhaps there should be a marker symbol (like an inverted white triangle) in the move diagrams to indicate squares where the piece could hop over something. The Grasshopper then would show up as a Queen. Not sure how I should do it for the Pao, which has both real non-captures and potential hops for capturing on the same squares...

CSS has background properties that will let you center a background image without any tiling. For example:

STYLE="background-repeat: no-repeat; background-position: center center;"

That seems to do the trick! Thanks! This is really starting to look good now.

25 comments displayed

⇧Earliest ⇧Earlier ⇧Reverse Order⇩ Later⇧ Latest⇩

Permalink to the exact comments currently displayed.