For clarity: the Play-Test Applet does not allow the user to exploit every feature of the Interactive Diagram, and the automatic GAME-code generation by it does not support every feature you can use through the Play-Test Applet. This doesn't have to be a major obstacle when you want to create HTML or GAME code for use elsewhere, as these are both texts, which can be easily modified afterwards for 'filling in the blanks'.
Now the original Play-Test Applet did not have an interface for specifying morph boards, and the GAME code that would be generated by it also knew nothing about morphing. This, however, happens to be exactly what I am working on to correct, by creating a new version of the Play-Test Applet. I modified the include file used by the Applet-generated code earlier already, for performing morphing when instructions to do this are included in the Applet-generated code. And the new Applet includes an interface for defining morphing.
Defining two versions of each piece doesn't really need a special interface, as the whole point of this is that they would be considered different pieces (so they can have different moves). If you want them to have identical images this would be a problem, though, for there only is e.g. a single Knight image in the table. So to create a Diagram that has two different Knights, one for in the bulls eye, and one for outside it, you would have to pick an alternative image for in the bulls eye. But you can always correct that afterwards, by editing the piece line in the Diagram for the bulls-eye Knight, replacing the image name (say you used a Unicorn) by 'knight'. You would of course have to assign the desired bulls-eye move to the Unicorn. The Diagram would allow you to also use the same piece ID. (It is smart enough to understand that a piece should never morph into itself, so if you specify N as the result, it would take it to mean the other N.) But Game-Courier presets would not like that a bit, for those all pieces need to have a different 'label'. So if the goal is to create GAME code, you should make sure every defined piece has a unique ID.
It is possible to change the ID even after pasting an existing Diagram into the Applet. In fact, if you paste a Diagram where the duplicats use the same image that immediately solves the problem of the duplicat images, as pasting a Diagram replaces the piece table as well as the board position. The new table would then contain two images of every kind. You would only have to give them different piece IDs. You could not specify new morph boards in that case, though, as the new piece table would not specify you hold any pieces 'in hand' that you could drop on the morph board for specifying promotions.
For clarity: the Play-Test Applet does not allow the user to exploit every feature of the Interactive Diagram, and the automatic GAME-code generation by it does not support every feature you can use through the Play-Test Applet. This doesn't have to be a major obstacle when you want to create HTML or GAME code for use elsewhere, as these are both texts, which can be easily modified afterwards for 'filling in the blanks'.
Now the original Play-Test Applet did not have an interface for specifying morph boards, and the GAME code that would be generated by it also knew nothing about morphing. This, however, happens to be exactly what I am working on to correct, by creating a new version of the Play-Test Applet. I modified the include file used by the Applet-generated code earlier already, for performing morphing when instructions to do this are included in the Applet-generated code. And the new Applet includes an interface for defining morphing.
Defining two versions of each piece doesn't really need a special interface, as the whole point of this is that they would be considered different pieces (so they can have different moves). If you want them to have identical images this would be a problem, though, for there only is e.g. a single Knight image in the table. So to create a Diagram that has two different Knights, one for in the bulls eye, and one for outside it, you would have to pick an alternative image for in the bulls eye. But you can always correct that afterwards, by editing the piece line in the Diagram for the bulls-eye Knight, replacing the image name (say you used a Unicorn) by 'knight'. You would of course have to assign the desired bulls-eye move to the Unicorn. The Diagram would allow you to also use the same piece ID. (It is smart enough to understand that a piece should never morph into itself, so if you specify N as the result, it would take it to mean the other N.) But Game-Courier presets would not like that a bit, for those all pieces need to have a different 'label'. So if the goal is to create GAME code, you should make sure every defined piece has a unique ID.
It is possible to change the ID even after pasting an existing Diagram into the Applet. In fact, if you paste a Diagram where the duplicats use the same image that immediately solves the problem of the duplicat images, as pasting a Diagram replaces the piece table as well as the board position. The new table would then contain two images of every kind. You would only have to give them different piece IDs. You could not specify new morph boards in that case, though, as the new piece table would not specify you hold any pieces 'in hand' that you could drop on the morph board for specifying promotions.