H. G. Muller wrote on Thu, Feb 13, 2020 07:52 AM UTC:
OK, I can get it too now. It only appears to add the spurious Rook moves in two directions, and only when the mount is on an F square. In fact the piece behaves like a bifurcator, going to the second leg not at the mount, but one step in front of it. It is apparently the yafscpF contribution that does this.
And it seems to be caused by the 'original' use of 'p' in the final leg. When I use 'p' in the new meaning of ending on an occupied square for a non-final leg, as in yafscpafF, everything works fine. Which is surprising, as the Betza parser should convert p to paf on any final leg, on reading the description, so that they really should be the same thing. This is apparently what goes wrong.
This is definitely a bug in the Interactive Diagram code. I will look into it. Thank you for reporting it!
[Edit] OK, I have fixed it. The problem was that the Betza parser turned the old-style 'p' on final legs to a multi leg move, by making it into a non-final leg with 'p' mode, and adding an extra leg for the part of the trajectory after the mount. In the internal representation each leg lists how many legs still follow, so that they can be skipped whenever an earlier leg cannot be completed. The existing parser did not increase this skip count on legs before the leg with the old-style 'p', so that when they were blocked the newly added leg for after the mount was not skipped, but was considered another independent move. So when the first F step in yafscpF could not be made because of a blocker, it would transplant the path that should have come after the mount in the second leg to the piece itself.
I also fixed another problem: finite-range hoppers were not working properly. E.g. pR5 would not be an R5 that had to pass over exactly one obstacle, but would be a pR that could only land on the first 5 squares behind the mount. I think in original Betza notation the range should apply to total range, and changed the code accordingly. Downside is that it is not easily possible now to describe hoppers with a fixed finite range after the hop. (Unless that range is 1, in which case the range-toggling 'g' modifier can be used.) I suppose an 'Extended Grasshopper' that could land (precisely) 2 squares behind its mount can still be described as gafafQ (where gafQ would be an alternative notation for gQ, the normal Grasshopper).
Note that caching on this website is broken, so that you might not be able to benefit from the fixed diagram code I uploaded until the site maintainer takes manual action to make the changes visible!
OK, I can get it too now. It only appears to add the spurious Rook moves in two directions, and only when the mount is on an F square. In fact the piece behaves like a bifurcator, going to the second leg not at the mount, but one step in front of it. It is apparently the yafscpF contribution that does this.
And it seems to be caused by the 'original' use of 'p' in the final leg. When I use 'p' in the new meaning of ending on an occupied square for a non-final leg, as in yafscpafF, everything works fine. Which is surprising, as the Betza parser should convert p to paf on any final leg, on reading the description, so that they really should be the same thing. This is apparently what goes wrong.
This is definitely a bug in the Interactive Diagram code. I will look into it. Thank you for reporting it!
[Edit] OK, I have fixed it. The problem was that the Betza parser turned the old-style 'p' on final legs to a multi leg move, by making it into a non-final leg with 'p' mode, and adding an extra leg for the part of the trajectory after the mount. In the internal representation each leg lists how many legs still follow, so that they can be skipped whenever an earlier leg cannot be completed. The existing parser did not increase this skip count on legs before the leg with the old-style 'p', so that when they were blocked the newly added leg for after the mount was not skipped, but was considered another independent move. So when the first F step in yafscpF could not be made because of a blocker, it would transplant the path that should have come after the mount in the second leg to the piece itself.
I also fixed another problem: finite-range hoppers were not working properly. E.g. pR5 would not be an R5 that had to pass over exactly one obstacle, but would be a pR that could only land on the first 5 squares behind the mount. I think in original Betza notation the range should apply to total range, and changed the code accordingly. Downside is that it is not easily possible now to describe hoppers with a fixed finite range after the hop. (Unless that range is 1, in which case the range-toggling 'g' modifier can be used.) I suppose an 'Extended Grasshopper' that could land (precisely) 2 squares behind its mount can still be described as gafafQ (where gafQ would be an alternative notation for gQ, the normal Grasshopper).
Note that caching on this website is broken, so that you might not be able to benefit from the fixed diagram code I uploaded until the site maintainer takes manual action to make the changes visible!