💡📝H. G. Muller wrote on Fri, Feb 3, 2023 04:35 PM UTC:
To make life easier for those who want to extend the Interactive Diagram with custom JavaSCript, I added a second argument to xxxTinker(): this gets passed the distance to last rank, corrected for piece color. Almost every WeirdPromotion() function I have ever written required calculation of that.
I added functions in the standard script to aid with other tasks: AddVictim(move, x, y) adds a locust square (x, y) to the specified move. And VetChoice(promoPiece, d) tests whether chess-like promotion to promoPiece would be allowed (as per promoZone and promoChoice) when you are d steps removed from last rank. You might want to fake a d within the zone in cases where the user script requests a promotion outside the zone.
The moving piece will always be stored in move[-6]. As an example, when you want to allow piece type 2 to promote when it arrives on last rank from the fore-last one, but not from a larger distance, you could use
function xxxTinker(m, d) {
if(d != 0) return 0; // not to last rank
if((m[-6] & 511) != 2) return 0; // not piece type 2
if(m[3] != m[1] + 1 && m[3] != m[1] - 1) return 0; // not a single step
if(!m[-1]) return 4; // choice not yet made, request one
return VetChoice(m[-1], 0); // return whether choice is forbidden (1) or not (0)
}
If under the same conditions a shogi-like promotion to piece type 12 (different from what promoOffset would specify) should take place, things are simpler:
function xxxTinker(m, d) {
if(d != 0) return 0; // not to last rank
if((m[-6] & 511) != 2) return 0; // not piece type 2
if(m[3] != m[1] + 1 && m[3] != m[1] - 1) return 0; // not a single step
m[-1] = 12 | m[-6] & 1024; // specify promoted type (adding color)
return 3; // request choice between this and deferral
}
Scripts like this are only needed to make the promotion dependent on the move; if it is just dependent on the square you move to, or what you capture there, the standard parameters morph and captureMatrix take care of the promotion for you. The way I have implemented it now these would have precedence over the user-supplied scripts. That is, when these specify a promotion, ban or game termination, this will be applied without question, and the xxxTinker() script will only be invoked when they don't specify anything special. So the script only has to handle the non-standard cases.
Although the script could now add as many locust victims to a move as it wants, and wherever it wants those, the trick to request burning or atomic capture through promotion code 512 will still work, and the standard script will add the locust squares in that case.
To make life easier for those who want to extend the Interactive Diagram with custom JavaSCript, I added a second argument to xxxTinker(): this gets passed the distance to last rank, corrected for piece color. Almost every WeirdPromotion() function I have ever written required calculation of that.
I added functions in the standard script to aid with other tasks: AddVictim(move, x, y) adds a locust square (x, y) to the specified move. And VetChoice(promoPiece, d) tests whether chess-like promotion to promoPiece would be allowed (as per promoZone and promoChoice) when you are d steps removed from last rank. You might want to fake a d within the zone in cases where the user script requests a promotion outside the zone.
The moving piece will always be stored in move[-6]. As an example, when you want to allow piece type 2 to promote when it arrives on last rank from the fore-last one, but not from a larger distance, you could use
function xxxTinker(m, d) { if(d != 0) return 0; // not to last rank if((m[-6] & 511) != 2) return 0; // not piece type 2 if(m[3] != m[1] + 1 && m[3] != m[1] - 1) return 0; // not a single step if(!m[-1]) return 4; // choice not yet made, request one return VetChoice(m[-1], 0); // return whether choice is forbidden (1) or not (0) }If under the same conditions a shogi-like promotion to piece type 12 (different from what promoOffset would specify) should take place, things are simpler:
function xxxTinker(m, d) { if(d != 0) return 0; // not to last rank if((m[-6] & 511) != 2) return 0; // not piece type 2 if(m[3] != m[1] + 1 && m[3] != m[1] - 1) return 0; // not a single step m[-1] = 12 | m[-6] & 1024; // specify promoted type (adding color) return 3; // request choice between this and deferral }Scripts like this are only needed to make the promotion dependent on the move; if it is just dependent on the square you move to, or what you capture there, the standard parameters morph and captureMatrix take care of the promotion for you. The way I have implemented it now these would have precedence over the user-supplied scripts. That is, when these specify a promotion, ban or game termination, this will be applied without question, and the xxxTinker() script will only be invoked when they don't specify anything special. So the script only has to handle the non-standard cases.
Although the script could now add as many locust victims to a move as it wants, and wherever it wants those, the trick to request burning or atomic capture through promotion code 512 will still work, and the standard script will add the locust squares in that case.