I'm not sure how you intend to merge move rejection, game termination, mandatory promotion, and offering promotion choice, into a single function, unless JS allows you to return a value that could be one of many different types.
This is exactly what JavaScript allows. It is a 'typeless language', where any variable can hold, or any function can return any type of data structure. Move rejection and game termination go through numeric codes (BadZone does that now, 1 for rejection, 0 for allowed, -1 and -2 for termination), forced promotion or a choice request as well (by WeirdPromotion, returning the piece-type number or 1000). It would be easy enough to rearrange the numeric codes such that they do not collide. It is just that when you request promotion choice, it uses the same procedure as when you enter the zone, controlled by promoChoice or promoOffset. Here it would increase flexibility if I allowed returning a character string or (more efficiently, but perhaps less user-friendly) the array that such a string would parse to when given as promoChoice. (Such an array would be indexed by piece type, and contain a non-zero value for each piece type that in principle can be chosen. Where 2 means 'if available in the holdings', and 3 means 'not on last rank'.
I understand that it will never be possible to handle everything by parameters. But the main point is that I don't want to realease on afficial specification for something I would have to change later. That would load the whole project with an obligation to remain backward compatibility for the legacy features. Now in this case it would probably not be so hard to maintain such compatibility: I could switch to a usiversal Custom() function that takes care of everything, only invoked when no parameters (such as morph or captureMatrix) are specified that require use of the standard function, and the user specified a legacy BadZone() or WeirdPromotion(). This Custom() function would then call the latter two, and integrate their return values into the new format. This Custom() could just get the complete move description used by the AI passed as an array.
This is exactly what JavaScript allows. It is a 'typeless language', where any variable can hold, or any function can return any type of data structure. Move rejection and game termination go through numeric codes (BadZone does that now, 1 for rejection, 0 for allowed, -1 and -2 for termination), forced promotion or a choice request as well (by WeirdPromotion, returning the piece-type number or 1000). It would be easy enough to rearrange the numeric codes such that they do not collide. It is just that when you request promotion choice, it uses the same procedure as when you enter the zone, controlled by promoChoice or promoOffset. Here it would increase flexibility if I allowed returning a character string or (more efficiently, but perhaps less user-friendly) the array that such a string would parse to when given as promoChoice. (Such an array would be indexed by piece type, and contain a non-zero value for each piece type that in principle can be chosen. Where 2 means 'if available in the holdings', and 3 means 'not on last rank'.
I understand that it will never be possible to handle everything by parameters. But the main point is that I don't want to realease on afficial specification for something I would have to change later. That would load the whole project with an obligation to remain backward compatibility for the legacy features. Now in this case it would probably not be so hard to maintain such compatibility: I could switch to a usiversal Custom() function that takes care of everything, only invoked when no parameters (such as morph or captureMatrix) are specified that require use of the standard function, and the user specified a legacy BadZone() or WeirdPromotion(). This Custom() function would then call the latter two, and integrate their return values into the new format. This Custom() could just get the complete move description used by the AI passed as an array.