Implement API level multipass support
LadyCailinBot opened this issue ยท 0 comments
WORLDEDIT-3387 - Reported by Dark_Arc
With multipass users should be able to edit the world over the course of several ticks as determined by a supervisor.
There are a few challenges with the implementation of this. Namely, there are several blocks which can change state before an edit is completed.
There are two primary approaches, each with their own subset of issues. The first approach being reverse engineering the creation of the structure, so as to place things in such a way, that they will not change state, and cause problems elsewhere in the edit. The second approach being, to attempt to perform the edit without allowing the potentially troublesome blocks from changing state.
The first approach, is incredibly complicated, speaking from a code perspective, in that it requires a large amount of information to be contained within WorldEdit, in regards to how the block behaves. This isn't really practical, as it would require a lot of effort to maintain, especially when we start to consider modded blocks.
The second approach, is fragile, it relies on the platform having proper support for "fast mode."
At the current time, I think we can use both to get a working solution. The solution that we should work towards is to have the default implementation be one such that, there is a whitelist of idle blocks, or in other words, blocks that will not change state in such a way that it will cause problems for the edit in any case. These blocks will be edited in a true multipass fashion. All other blocks will be put into a queue of blocks which must be edited in a single tick.
Then for users who would like to take the risk of relying on a "fast mode" based system, there will be an additional configuration option, to process the queue of single tick blocks using fast mode, and then propagate state updates.
In this way, we can fully optimize for the common case, while maintaining commitment to the quality of our edits.