Log: https://pastebin.com/mE9HMCQh
SpongeVanilla 1.12.2-7.0.0-BETA-346
Code to reproduce:
@Listener
public void onPlayerJoin(ClientConnectionEvent.Join event, @Getter("getTargetEntity") Player player) {
Location<World> location = player.getLocation();
Vector3i blockPosition = location.getBlockPosition();
Extent destination = location.getExtent().getExtentView(
blockPosition.sub(1000, blockPosition.getY(), 1000),
blockPosition.add(0, 255 - blockPosition.getY(), 0)
);
Task.builder().async().execute(() -> {
destination.getBlockWorker().fill((x, y, z) -> BlockTypes.AIR.getDefaultState());
logger.info("completed");
}).delay(10, TimeUnit.SECONDS).submit(this);
}
You can't make a block worker perform block changes async.... World changes aren't supported async period.
Ah, its impossible to make something like fastasyncworldedit without NMS
access?
It's possible. It's just somewhat complicated. What FAWE (and the original AWE) do is they perform a few block changes each tick (actually, more than a few; the calculation of how many per tick varies). You don't need NMS to do that, although you can't use block workers for it; you'll have to use setBlock() manually.
I feel that I need to write about some definitions and corrections about some words being used here:
For all intents and purposes the following are to be defined:
Sponge.isServerAvailable() && Sponge.getServer().isMainThread() being false, either because Sponge.isServerAvailable() returns false or because we genuinely are not on the server thread that is availableWorld whether it is the changes of BlockStates at a particular position, or the creation and reset of a TileEntity at a location.With all of that said, there is also the well established understanding in the entirety of problem solving: there is always more than one way to solve a problem.
Now that all of that has been said, read, and understood, I can now say this:
Sponge will never support performing block change operations off the server thread until implementation can support such operations. There are always more ways to process bulk changes to the world, even if you're pasting a large schematic. What IS supported is performing bulk edits at once in a plugin listener, task, or command. If you find yourself in a situation where a larger than normal amount of block changes are requested, you the programmer, are able to determine "how many changes" you're about to make, and bulk process them over several ticks. What this means is that if you have 600,000 block changes to make, and you know that performing any amount of block changes in excess of 10,000 will cause server lag, you can divide the entire 600k block changes into smaller chunks to perform in iterations. Be it if you need to perform them bottom to top, chunk by chunk, line by line, etc. you will have less of an impact on server performance if you bulk process these changes yourself in a more supported fashion by utilizing all the tools available to you in the API.
The above suggestion is simply a suggestion. Otherwise, attempting to manipulate/change/modify/mixin/reflection internals to specifically allow yourself to make asynchronous world changes is simply going to get no support from the Sponge implementations, let alone the Sponge Teams.
Most helpful comment
I feel that I need to write about some definitions and corrections about some words being used here:
For all intents and purposes the following are to be defined:
Sponge.isServerAvailable() && Sponge.getServer().isMainThread()beingfalse, either becauseSponge.isServerAvailable()returnsfalseor because we genuinely are not on the server thread that is availableWorldwhether it is the changes ofBlockStates at a particular position, or the creation and reset of aTileEntityat a location.With all of that said, there is also the well established understanding in the entirety of problem solving: there is always more than one way to solve a problem.
Now that all of that has been said, read, and understood, I can now say this:
Sponge will never support performing block change operations off the server thread until implementation can support such operations. There are always more ways to process bulk changes to the world, even if you're pasting a large schematic. What IS supported is performing bulk edits at once in a plugin listener, task, or command. If you find yourself in a situation where a larger than normal amount of block changes are requested, you the programmer, are able to determine "how many changes" you're about to make, and bulk process them over several ticks. What this means is that if you have 600,000 block changes to make, and you know that performing any amount of block changes in excess of 10,000 will cause server lag, you can divide the entire 600k block changes into smaller chunks to perform in iterations. Be it if you need to perform them bottom to top, chunk by chunk, line by line, etc. you will have less of an impact on server performance if you bulk process these changes yourself in a more supported fashion by utilizing all the tools available to you in the API.
The above suggestion is simply a suggestion. Otherwise, attempting to manipulate/change/modify/mixin/reflection internals to specifically allow yourself to make asynchronous world changes is simply going to get no support from the Sponge implementations, let alone the Sponge Teams.