Efficient way for large Block Placement

[Devlrxxh]

Is your feature request related to a problem?

As of now everyone knows bukkit doesn't directly offer any way to do large sized batch-editing. And I have issues trying to do massive block placements since there isn't any way to do it directly except using reflection and NMS.

Describe the solution you'd like.

A way to be able to do batch-editing while it not costing any performance issues, its fine if there are stuff not updating for example ticking tile entities. so a method something like setBlocks(Map<Location, BlockData> blocks); I have made a pr about my solution about this before but its need some discussion

Describe alternatives you've considered.

Using NMS and reflection https://github.com/Devlrxxh/BlockChanger

Other

No response

[OceanTw]

Had issues with setting large amount of blocks, this would be a good feature if it gets added

[electronicboy]

It's generally a discussion over how such a mechanism should look, not a "should we add this". We already know that there has been demand for such a thing over the years, it's the API design issue and considering how much/what control should be given over stuff, because "it's fast but it corrupts game state" is not something we can be overly excited for when it comes to API, especially if we're going to be considering it a first class citizen of the API

[electronicboy]

Majority of the slowdown is in all the extra API fluff that the CB layer adds; maybe we can add a means to skip certain operations and delay them until layer, i.e. letting the light system deal with relighting chunks in the future rather than "right now"; but, busting world state by default without any form of control is just not something that I can personally support

[Devlrxxh]

could I know what is a "must" you need when doing this stuff? so maybe I can work on it

[SirYwell]

WorldEdit has a SideEffect system for stuff like that. An extensive API could be inspired by that. But right now, it is still unclear how sophisticated such an API has to be to make everyone happy.

[electronicboy]

Part of the reason why I said that this should be a discussion is so that we can nail down the details of what this API should look like; corrupting world state is something I'm not fond of, especially not as the default option;

The idea would be to nail down what the overarching API should look like (It CANNOT be a singular method looking like a first class mechanism of modifying the world), and should likely offer some control over what operations are skipped, and, where viable, use already built in/optimised paths for handing stuff; i.e. delaying relighting of chunks until post work so we can just relight the entire chunk if over X blocks, using the servers already existing mechanism for sending out block updates rather than trying to handle that ourselves, etc

[Devlrxxh]

Understood

[zs0mborr]

I ran into problems when trying to set a large number of blocks. It would be great if this feature were added. The only workaround I found was using NMS and reflection, but that method breaks with new updates. So, this would be a highly useful update

[NonSwag]

I would suggest something like editMeta does
A consumer in which you can edit the state of the world without modifying it directly and after you are done the changes are persisted
By doing so it could be possible to say whether block or light updates should happen and then resend the chunk