The Timurid family is a simple case, because they all have the same promotion. Pawn keeps promoting to Queen, even for those variants where a Queen is not in the initial setup.
I suppose that in general you cannot be so lucky. The commonly employed rule is that you can promote to every non-royal in the initial setup. That makes it more difficult to combine variants that merely differ by replacement of a piece. It would be nice to make the prelude sub-model more useful by also building in a device to automatically adapt the promotion choice depending on the selected setup.
Perhaps the prelude routine could automatically create an array with all non-royal piece types that were selected for participation in it. A 'promote' routine that returns this array when a move is found to be a promotion would then fit the requirement. And variants that don't want that would just ignore that array, and return their own, fixed array of possible choices.
Or, with a slightly different approach: the 'promote' routine could get the array it returns from a variable outside itself, existing in thegame-definition object. (The routine returned by cbPiecesFromFEN already does that, in the form of the property promoChoice.) The prelude objects could refer to that array (as they are also instantiated inside the game-definition object), e.g. through a property 'participants', and then change its content As opposed to replacing it by a new array) based on the user's selection. So that the promotion routine will use that adapted content. If this is not desired you simply omit the participants property from the prelude object.
[Edit] Also here the color dichotomy is a pain in the neck. With asymmetric pieces you could not use the same set of promotion pieces for white and black. I guess it is really urgent to fix that problem once and for all.
[Edit2] I suppose we can do without an optional blackTypesOffset. The prelude routine knows whether it is placing black or white pieces, and when it looks up the type for a certain piece ID, it can use the convention that white uses the first such type it encounters in the pieceTypes list, and black the last one.
The Timurid family is a simple case, because they all have the same promotion. Pawn keeps promoting to Queen, even for those variants where a Queen is not in the initial setup.
I suppose that in general you cannot be so lucky. The commonly employed rule is that you can promote to every non-royal in the initial setup. That makes it more difficult to combine variants that merely differ by replacement of a piece. It would be nice to make the prelude sub-model more useful by also building in a device to automatically adapt the promotion choice depending on the selected setup.
Perhaps the prelude routine could automatically create an array with all non-royal piece types that were selected for participation in it. A 'promote' routine that returns this array when a move is found to be a promotion would then fit the requirement. And variants that don't want that would just ignore that array, and return their own, fixed array of possible choices.
Or, with a slightly different approach: the 'promote' routine could get the array it returns from a variable outside itself, existing in thegame-definition object. (The routine returned by cbPiecesFromFEN already does that, in the form of the property promoChoice.) The prelude objects could refer to that array (as they are also instantiated inside the game-definition object), e.g. through a property 'participants', and then change its content As opposed to replacing it by a new array) based on the user's selection. So that the promotion routine will use that adapted content. If this is not desired you simply omit the participants property from the prelude object.
[Edit] Also here the color dichotomy is a pain in the neck. With asymmetric pieces you could not use the same set of promotion pieces for white and black. I guess it is really urgent to fix that problem once and for all.
[Edit2] I suppose we can do without an optional blackTypesOffset. The prelude routine knows whether it is placing black or white pieces, and when it looks up the type for a certain piece ID, it can use the convention that white uses the first such type it encounters in the pieceTypes list, and black the last one.