roice3
commented
7 years ago I totally understand what is going on now, and unfortunately it will be a bit bigger change than I hoped, requiring me to update the way I record macros. Right now, when I record a macro I only record the "logical" twists that comprise it, e.g. I might save "6:R", which stands for a right-click of the 6th twist. However that 6th twist represents a set of identified twisting circles, not a single twisting circle. When I go to apply the macro, the particular circle that ends up used is the circle (among all identified circles) that is closest to the origin. On orientable puzzles with regular colorings this is all fine, but on non-orientable puzzles it can lead to some completely unintuitive behavior.
To fix, I'm going to need to record either the actual physically clicked locations or the specific twisting circle among the set of identified twisting circles. (It might be enough to just store whether it was a normal or mirrored tile that was clicked, then later make sure to pick a specific twisting circle that matched that. I think that would work for the Klein bottle puzzle, but that might still be less optimal for non-regular colorings.)
A little bit of history on why the one closest to the origin is used. That fixed an issue Nan reported early on where the transformation of a macro could move the macro off of the tiling (at least off of how far I had recursed it). So this change will need to take care to not break that again.
For those following this issue, I'm not sure when I'm going to get this done.
I noticed this doing my Klein Bottle solve, and Melinda reported it as well.
In some cases, this is unavoidable, but I think I've found some cases that should be doing a better job moving to a different location.
One worry is breaking existing log files, but I think that should be ok since the log files enter all the moves verbosely (rather than pointing to the macro), and altering the behavior for transformed macros won't affect the originally defined ones.