Would replace <source_node_name> with <target_node_name> with a chance of $chance = \frac{distance(pos1, pos\_cur)}{radius} \times (end\_chance - start\_chance) + end\_chance$, which would be a value in the range $start\_chance..end\_chance$, and where $distance()$ is defined by $dist = length(a - b)$.
We could even upgrade to $f(\frac{length(pos1 - pos\_cur)}{radius})$ once we have a math parser, where $f()$ is given function to manage the falloff gradient, e.g. $y = sin(x)$, or $y = log(x)$ for example.
An identical definition, but the centre would be considered at //scentre of a region defined by pos1 and pos2. A function identical to that described above could apply, but instead of euclidian distance, we'd probably want a different distance function to make it square.
A pair of commands that replace blocks in a falloff radius around the given position would be very welcome. For example:
Would replace
<source_node_name>
with<target_node_name>
with a chance of $chance = \frac{distance(pos1, pos\_cur)}{radius} \times (end\_chance - start\_chance) + end\_chance$, which would be a value in the range $start\_chance..end\_chance$, and where $distance()$ is defined by $dist = length(a - b)$.We could even upgrade to $f(\frac{length(pos1 - pos\_cur)}{radius})$ once we have a math parser, where $f()$ is given function to manage the falloff gradient, e.g. $y = sin(x)$, or $y = log(x)$ for example.
For the squared variant:
An identical definition, but the centre would be considered at
//scentre
of a region defined by pos1 and pos2. A function identical to that described above could apply, but instead of euclidian distance, we'd probably want a different distance function to make it square.