//sphereapply + //mathapply

[sbrl]

I think it was @Miniontoby on the Minetest Forums who asked for //replacenear.

After seeing WorldEdit's //cubeapply function, I've had a brilliant idea that would effectively allow use to imitate //replacenear (if we assume //replacenear replaces inside a sphere) while simultaneously adding support for all other existing commands that operate using both worldedit pos1 and pos2.

In short, it would work like this:

1. Set pos1 and pos2 to be a box around the original pos1
2. Use VoxelManip as normal to fetch a copy of newly defined area in question
3. Call the command in question (it could even be //multi I guess) and allow it to do it's thing
4. Read a second copy of the defined area with VoxelManip
5. Copy the contents of the first VoxelManip onto the second, masking a spherical area around the original pos1
6. Write the 2nd VoxelManip back to the world
7. See only a spherical area has ultimately been changed

We could even add support for implementing an expression that defines whether we keep or revert edits based on the xyz position (we'd want to normalise x, y, and z to between 0 and 1 on each axis though) - though this would be a separate command. Perhaps MathPlot has an API we can hook into for the expression parsing - then we could add it as a soft dependency? We'd want to be careful to sandbox the expressions themselves.

If not, we might be able to implement a recursive-descent finite-state-automaton parser of some description for this purpose instead, since tokenising should be (fairly?) straight-forward if we force spaces between everything, but then again we could port our Lexer C♯ class over? Hrm......

Anyway, we'd want to implement //sphereapply first before we start thinking about that :P

[sbrl]

Done! We ended up implementing //ellipsoidapply instead, but it all worked out in the end :P

I'm not going to close this issue just yet, because the MathPlot idea is far too good to go uninvestigated.

[sbrl]

Wow, implementing a mathematical expression parser without any existing tooling is wildly complicated. This will take some significant time, as we don't have a tool like bison in vanilla Lua (again, the inability to use require() really hurts our ability utilise other libraries etc without absorbing them along with the extra maintenance cost there).