>"lock and key" nature of the problem/solution
Have had a slight change of thinking. Not sure if it will lead towards a solution, but wanted to share the idea.
Quite a bit of recent work ( >>6057, >>6064 ) has been an attempt to use the animated squares and mod analysis to find appropriate triangle formulas to construct or iterate towards the correct x+n.
Why are we messing with trying to guess the exact x+n?
Especially when there are so many n values that fit into every x+n the larger the square gets.
So the adjustment in thinking about the lock and key:
Lock == 1 + 8T(u), where u is a multiple of (f-1)/8.
Key == nn+2d(n-1)+f-1
The lock is fixed. As in the odd x+n square that contains many potential n values.
And the key turns. As in adjustments within nn+2d(n-1)+f-1 that can generate matches. (i.e. our animated gifs turning within the same square.)
Using c6107 as an example. f=134, the starting u is ((134-1)/8) = 16, and the first few x+n squares are 33, 65, 97, 129, 161.
The first pic attached is a query for the solution n=36 in positive e for just these x+n values. And shows the first occurrence of n=36 at the second square iteration of 65.
The second pic takes this idea a bit further and searches for all n=36 records within each iteration of x+n, and then filters those records where d matches any d value from the factor tree.
This may all be coincidental, however, but certainly interesting how the n and d values line up in the negative e space.
So the theory is to lock the x+n value, and then use the factor tree to narrow the list of potential n matches.