This rovides an abstraction to fetch a worldedit command's definition,
regardless of where it was registered.
We would normally expect all commands to be registered in
wea_c.registered_commands, but before we only do a one-off pass to
import commands from worldedit should a new mod we aren't aware of
register a command with worldedit and get loaded after us, we won't
detect it - hencee the need for this function.
We need a way of defining metaballs per-player. Our solution to this is
a custom in-memory per-player storage system. The reason for this is
because just a position (e.g. that provided by pos1/pos2) is not enough
- we need a radius as well.
Improvements oveer //dome:
- Allow customising the direction it points in
- Allow multiple pointing directions at once to give the effect of
creating multiple domes on top of each other in a single command (it's
actually implemented as an implicit union, and doesn't actually call
wea.dome more than once).
First up: test that our initial basic dynamic brushes work as intended
with the //sculptlist [preview] command.
Also on the todo list: document it in the chat command reference!
Eventually, worldedit *will* become an optional dependency. The
rationale for this is that WorldEditAdditions is outgrowing the core
WorldEdit API, and we want to add new features such as toggling
safe_region on and off with a chat command and other such goodies.
Merging the 2 mods is not something that has been discussed (due
mainly because I'm far too nervous to even ask the question in the
first place), but the 2 codebases are fundamentally different (and
for good reason, as WorldEditAdditions splits code over many different
files to improve maintainability and scalability) so this would
be a significant undertaking.
At no point however will WorldEditAdditions become incompatible
with WorldEdit itself. The 2 mods should happily co-exist with
one another (so long as you keep them both updated of course).
