I used the Play-Test Applet, followed by some editing of the html. Specifically, since the queen doesn't appear in the initial setup, I needed to add it to the promotion choices, which subsequently required adding it to the piece list (hence its appearance last, which I didn't remember indicating royalty).
A work-around for such extra piece types could be to place them in the empty area of the board in the initial position. Then they will be put in the piece list, and in the post-editing you only have to delete the list of squares where they should be put.
The Play-Test Applet also produced a more-verbose version of the piece descriptions than necessary, so I pruned those down based on viewing another of your posted diagrams. But then the issue with the knight came up, and it seemed that it needed the explicit id.
I guess the problem with the Knight was that you pruned a bit too much. In particular the ID field for the Knight, which would have be an N if you had left it alone.
The order of the pieces in the promoChoice string should not matter; when a promotable piece reaches the zone the diagram just goes through the piece list, and for every ID tests whether it occurs (as a sub-string) in the promoChoice string. This algorithm failed when the IDs are not single letters, so I later supported a second format where you can specify a comma-separated list of promotion choices. If a comma occurs in the promoChoice it then only considers a piece ID a match if it occurs as a sub-string surrounded by commas.
A work-around for such extra piece types could be to place them in the empty area of the board in the initial position. Then they will be put in the piece list, and in the post-editing you only have to delete the list of squares where they should be put.
I guess the problem with the Knight was that you pruned a bit too much. In particular the ID field for the Knight, which would have be an N if you had left it alone.
The order of the pieces in the promoChoice string should not matter; when a promotable piece reaches the zone the diagram just goes through the piece list, and for every ID tests whether it occurs (as a sub-string) in the promoChoice string. This algorithm failed when the IDs are not single letters, so I later supported a second format where you can specify a comma-separated list of promotion choices. If a comma occurs in the promoChoice it then only considers a piece ID a match if it occurs as a sub-string surrounded by commas.