Course that means some major data transfers in the meanwhile and for the short run; but it's well worth it in retrospect.
I won't otherwise bore you with progress reports...
But I'm skimming through the manual FF inventory when I noticed that VectorC alleged an issue "compiling theta" with one of my early Flowfields. What's wierd, though, is that
1. the field appears exactly as it should in the program and
2. this is a cartesian field with but one callup of "r" within the source declaration (correct term?) itself.
Voici:
=================
Aspc=0
A0="7.85 + trnc(rnd(7.85))"
A1="rnd(.0628) - .0785"
srcX="r + A1 * atan(y * A0)"
srcY="y - A1 * cos(x * A0 + sin(pi))"
Vers=100
=================
Can I chalk this up to the occasional hiccup in the VC engine?
EDIT: Now the console says nothing amiss when I call it up. I had called this FF up manually a few times leading to this message, what with making sure this was the problematic effect; but now...
. maybe it was when I lower-cased the A's in the src's and/or "de-deprecated" trunc()?BTW: I now understand another reason why many of my latest Fields and Waves (all forthcoming via submission soon) didn't initially work in the new one. To wit:
atan2(y,x).
Sweet(!); but can this be logically extrapolated into atan2(theta,r), or even a mix of the two cord types i.e. atan2(y,r)?
looks like a lot of work . Thank you for the new configs you're making too 