I found a minor undocumented feature.
This concerns [[...]] and order of evaluation of adjustment when there is randomness in the adjustments.
I'm using 3.0.9(v41) on Mac OS X.
MWE:
startshape S[a -.5]
shape S{
ONE[]
TWO[x 1.5]
THREE[x 3]
}
shape ONE{
SQUARE[b .5]
SQUARE[[x .5 y .5 s .5 sat 1 b 1 ]]
SQUARE[[s .5 x .5 y .5 sat 1 b 1 h 120]]
CIRCLE[[x .5 y .5 s .5 sat 1 b 1 h -120]]
}
shape TWO{
SQUARE[b .5]
SQUARE[[x .5 y .5 s .5 sat 1 b 1 ]]
SQUARE[[s .5 x .5 y .5 sat 1 b 1 h 120]]
CIRCLE[[x .5 y 0.5..0.501 s .5 sat 1 b 1 h -120]]
}
shape THREE{
SQUARE[b .5]
SQUARE[[x .5 y .5 s .5 sat 1 b 1 ]]
SQUARE[[s .5 x .5 y .5 sat 1 b 1 h 120]]
CIRCLE[[x .5 y 0.5..0.5 s .5 sat 1 b 1 h -120]]
}
I found the bug and it is trivial for you to work around until I release a fix. Context Free tracks whether shape adjustments are compile-time evaluated or runtime evaluated. Constants are evaluated at compile-time and the random functions are evaluated at runtime. But CF also performs an optimization when it sees consecutive adjustments x foo y bar. It converts the two adjustments to a single adjustment x foo bar. The bug is that if bar is runtime evaluated, CF drops this information and treats foo bar as if it was compile-time evaluated.
The work-around is simple. Just replace x foo y bar with x foo bar in your cfdg file and the buggy merging code will be bypassed. CF will correctly notice that foo bar is runtime evaluated because bar is runtime evaluated.
Ah OK - I didn't try that. My workaround was to go via another shape. Not the most efficient way to do it, but it works.
... but I'm clearly not into efficiency - I realised after uploading "weather" that I coded degrees-to-degrees conversion into all my calls to "atan" via atan(...)/atan(1)*45. I've got to get better at RTFM.