It would be less confusing for someone creating a preset if there was no discrepancy between how the board displays in Edit mode and how it displays while playing the game. ...
Well, the logical problem here is that the Applet does not know the association of piece labels and images used by the set, and doesn't know what set is going to be used in the preset. It only knows the piece IDs and image names used in the Diagram that is being converted, or coming from the ID assignment in the piece table if the user has been setting up the position from scratch. This is all a legacy from the time there were hardly any automatic sets, so people were mostly using sets with 1-letter piece labels, which, to cram as many images as possible in a single set, were often very unnatural, and not at all what the converted Diagram had been using. And the assignment would differ from set to set.
What we need is a set that contains all piece images an Interactive Diagram could possibly contain, and then require that the presets to be automated this way use this set and none other. Currently the GAME code generated by the Applet uses the piece IDs defined in the Diagram as piece labels. But it could just as easily be made to use the 'root name' of the image files as labels, converting to upper/lower case as necessary. Since the Applet's piece table uses the alfaeriePNG directory as a basis for what pieces to offer, the auto alfaeriePNG set would be suitable.
This approach relies on automatic sets being available for every theme that could have been used in the Diagram to be converted. It would not be a problem that we have no unity in image naming between themes, as long as people would use the auto set for the theme that was used in the Diagram they were converting.
A minor flaw is that the Diagram now allows the use of 'extraneous' pieces, i.e. with images from another directory than graphicsDir, and possibly of anothe image type, which are specified as an arbitrary filename / URL. The auto sets would not provide these pieces, which would drive people to using other sets, nagging editors to create those for them. Which then often would use names for the other pieces different from the full name in the auto set where most of the pieces were coming from.
One way around this would be to stop creating such dedicated piece sets, but instead service the request for a set with pieces not provided in the automatic set for that theme by expanding that automatic set with the requested 'non-automatic' piece.
I still think this is all a consequence of Game Courier not being able to directly associate piece labels with arbitrary image filenames (other than through GAME code, which causes the problems we are now dealing with), but uses this cumbersome indirect method of a (by now huge) number of package deals in the form of the sets.
If piece labels could be arbitrary URLs we could have a 'direct set', which is sort of a universal automatic set, which would not be limited to fetching the images from a fixed directory, but would derive the directory from the label on a piece-by-piece basis. But I suppose URLs contain characters not acceptable in piece labels. We could nevertheless define an escape convention for those. So that the set could serve any piece image on the website, without editor intervention.
Well, the logical problem here is that the Applet does not know the association of piece labels and images used by the set, and doesn't know what set is going to be used in the preset. It only knows the piece IDs and image names used in the Diagram that is being converted, or coming from the ID assignment in the piece table if the user has been setting up the position from scratch. This is all a legacy from the time there were hardly any automatic sets, so people were mostly using sets with 1-letter piece labels, which, to cram as many images as possible in a single set, were often very unnatural, and not at all what the converted Diagram had been using. And the assignment would differ from set to set.
What we need is a set that contains all piece images an Interactive Diagram could possibly contain, and then require that the presets to be automated this way use this set and none other. Currently the GAME code generated by the Applet uses the piece IDs defined in the Diagram as piece labels. But it could just as easily be made to use the 'root name' of the image files as labels, converting to upper/lower case as necessary. Since the Applet's piece table uses the alfaeriePNG directory as a basis for what pieces to offer, the auto alfaeriePNG set would be suitable.
This approach relies on automatic sets being available for every theme that could have been used in the Diagram to be converted. It would not be a problem that we have no unity in image naming between themes, as long as people would use the auto set for the theme that was used in the Diagram they were converting.
A minor flaw is that the Diagram now allows the use of 'extraneous' pieces, i.e. with images from another directory than graphicsDir, and possibly of anothe image type, which are specified as an arbitrary filename / URL. The auto sets would not provide these pieces, which would drive people to using other sets, nagging editors to create those for them. Which then often would use names for the other pieces different from the full name in the auto set where most of the pieces were coming from.
One way around this would be to stop creating such dedicated piece sets, but instead service the request for a set with pieces not provided in the automatic set for that theme by expanding that automatic set with the requested 'non-automatic' piece.
I still think this is all a consequence of Game Courier not being able to directly associate piece labels with arbitrary image filenames (other than through GAME code, which causes the problems we are now dealing with), but uses this cumbersome indirect method of a (by now huge) number of package deals in the form of the sets.
If piece labels could be arbitrary URLs we could have a 'direct set', which is sort of a universal automatic set, which would not be limited to fetching the images from a fixed directory, but would derive the directory from the label on a piece-by-piece basis. But I suppose URLs contain characters not acceptable in piece labels. We could nevertheless define an escape convention for those. So that the set could serve any piece image on the website, without editor intervention.