Not a bug… by moving point A (and thus the whole block) there apparently is no longer an intersection… the other option is the program crashing. I’m sure there’s probably a 1000 other locations you could move point A and get the same result. In other words there is no issue in moving point A to 0,0, but rather by doing so it’s breaking a dependency in your pattern, so the only known constant point 0,0 is used as a place holder. The same thing can happen if applying a measurement in a formula that forces an intersection point out of range.
But the fact that it doesn’t acknowledge the intersection is a bug? The arc starts at 0°, ends at 360°, has A as its axis, & when I move A to 0,0 suddenly a 135° ray with A also as its axis doesn’t intersect the arc making a full circle around it? (Same story with the 45° & 270° [ETA: & presumably all] intersections.) If there really are a bunch of other locations this could occur this is very definitely something needing fixed.
It’s not what I thought was happening. It appears it may have something to do within the BuildRay() routine… where it expects some value greater than 0. Seems the .0, .0 origin is throwing it off. If there’s no ray, there’s no intersect. If you move A to 0.0, 0.00001 it works. It’s like Fuzzy math in reverse. LOL I may have to run this through the debugger to track the values in real time to see what it’s doing or not doing.