I had a similar problem with the Black Soldiers in the one game I played. I was going to take tomorrow to ask H.G. to take a look at what's up with it.
This appears to be a bug in the betza.js script itself, albeit in something it does only for the benefit of generating GAME code: when it reads the XBetza descripttors it determines whether a piece is symmetric or not, and stores that info in an array. The PTA uses that array to see if it should create different versions of the piece for white and black in the legdefs move table.
The bug was that it would only base this on the last atom in the XBetza descriptor. For the Sergeant this was sW, which is symmetric. So it decided white and black could use the same Sergeant. Which for black of course means it now moves in teh wrong direction. I now changed it such that it pays attention to the symmetry of all atoms in the descriptor, and if one of those is asymmetric, it will create an extra flipped version for black.
After refreshing the browser cache the PTA should now generate the correct GAME code.
This appears to be a bug in the betza.js script itself, albeit in something it does only for the benefit of generating GAME code: when it reads the XBetza descripttors it determines whether a piece is symmetric or not, and stores that info in an array. The PTA uses that array to see if it should create different versions of the piece for white and black in the legdefs move table.
The bug was that it would only base this on the last atom in the XBetza descriptor. For the Sergeant this was sW, which is symmetric. So it decided white and black could use the same Sergeant. Which for black of course means it now moves in teh wrong direction. I now changed it such that it pays attention to the symmetry of all atoms in the descriptor, and if one of those is asymmetric, it will create an extra flipped version for black.
After refreshing the browser cache the PTA should now generate the correct GAME code.