cCuboid boundary inclusion change - Printable Version +- Cuberite Forum (https://forum.cuberite.org) +-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html) +--- Forum: Development (https://forum.cuberite.org/forum-13.html) +--- Thread: cCuboid boundary inclusion change (/thread-3235.html) |
cCuboid boundary inclusion change - xoft - 08-19-2019 I'd like to change cCuboid's understanding of its boundaries. Right now the class considers both of its boundaries inclusive, meaning that there is no way to represent an empty cCuboid. I'd like to change it so that the lower boundary is inclusive and the upper boundary is exclusive, similar to how STL defines iterators (begin() is inclusive, end() is exclusive). Once we have that, it makes little sense to support "unsorted" cCuboids, so I'd like to enforce sorting as well. In the C++ code there's only one area that uses the cCuboid for bounds checking, and that's the generator (mineshafts and generic piece-based). These should be pretty straightforward to fix. However, on the Lua side there may be a lot more of these. So I'm asking here about what plugins will need changing. This is suggested on GitHub as part of #4363: https://github.com/cuberite/cuberite/issues/4363 RE: cCuboid boundary inclusion change - NiLSPACE - 08-19-2019 According to Github there are 3 plugins of mine that use cCuboid. Also, WorldEdit uses cCuboid quite allot: https://github.com/cuberite/WorldEdit/search?q=cCuboid&unscoped_q=cCuboid RE: cCuboid boundary inclusion change - xoft - 08-19-2019 Yeah, WorldEdit is probably gonna be the biggest of the changes. Especially if we drop the support for un-sorted state, that would mean WE would need to rewrite most of its selection handling. |