Not talking about any specific world manipulation plugin however when editing large areas of the world in bukkit the server would often slow down or even crash altogether I was hoping that sponge would find a way to overcome that and not crash and maby do large world manipulation tasks in stages not all at once and then crash.
The problem was that worldedit was forced to do everything in the main thread. The main thread would lock up, and therefore the whole server would. From what I understand the API will be thread safe. But the underlying minecraft server/forge doesn’t support multithreaded block editing. Maybe if there’s a glowstone implementation of SpongeAPI some day.
This has been done before as a separate plugin known as AsyncWorldEdit. The basic idea is that instead of telling the server to manipulate a section of blocks as fast as possible, The server would modify the area in small chunks. For example you have 10,000 blocks to modify, the server would modify 1,000 blocks wait a second, modify 1,000 blocks, so on. Sponge would not have to implement it unless it has a built in feature similar to WorldEdit or VoxelSniper. Otherwise I would expect that it is the responsibility of the plugin developer to implement this feature.
4 Likes
I love the idea of piece by piece manipulation, but I don’t think it should show the client until it’s done doing the entire query(that shouldnt cause any lag on the server, right? since it’s still breaking down the entire query).
You are right, it is quite hard to work around manipulating blocks outside of the Main thread, if even possible. The possible solution introduced before was to just make the task in the main thread less demanding by breaking it into chunks. Therefore the server was not as taxed, aka higher TPS and less lag.
Ah yes, I used that plugin for a while. But it still locks up the main thread when you try exceptionally large edits or multiple edits in quick succession. (Say a stone sphere brush)
Or at least… that’s when I last used it. which was many months ago. I’m not sure if that problem still exists.
I don’t quite understand what you are saying. Are you suggesting that the client should not render the blocks manipulated until the whole task is finished?
I believe this problem still exists. I think the problem lies in the fact that every job is broken down into smaller chunks, so you have multiple jobs executing at once, rather than a cumulative list to go through. So if you have 5 10,000 block edits. then you are manipulating 5,000 blocks at a time, rather than 1,000. Again i do not know for sure, since I did not see the code for the plugin.
This is something my server would like to see to, large editing that doesnt crash the server when u type the command, but editing blocks in chucks or something
I rewrote a considerable amount of WorldEdit in the past few months (a lot of the code is pretty much the same since MC Alpha) to support completely lag-free block sets executed over several ticks.
I was working on finishing it up…
…but then I needed to update WG for UUID support (and also rewrite a bunch of that). Pretty much finished that and then…
…Bukkit died.
…Now I have Sponge.
19 Likes
And now Sponge will be sporting the best WorldEdit yet! So there’s that.
3 Likes
Sk89q, I’m glad to see you were working on the issue. I look forward to using your newest version of WorldEdit once Sponge comes out.
Also a part of the problem of doing extremely large edits is the amount memory it uses, if you did like 1-2 million blocks that could very quickly exhaust the server of memory. A 10 million block copy uses around 500-700mb of server memory, if you didn’t have the server running with more than 2gb then it would most likely crash on that from a out of memory error. (This is in WE.)
1 Like
I love that you’re working so hard on Sponge but I can’t help worry that you won’t have time to focus on your plugins which all of us love so much 
2 Likes
I rewrote a considerable amount of WorldEdit in the past few months (a lot of the code is pretty much the same since MC Alpha) to support completely lag-free block sets executed over several ticks.
I was working on finishing it up…
…but then I needed to update WG for UUID support (and also rewrite a bunch of that). Pretty much finished that and then…
Yeah, it would of hurt me if I did a revision of ThunderTools and put it on the bukkit dev to only find out that bukkit is falling apart the next day. Luckily I have been holding off to next major version of bukkit. (1.8)
- TangentSpy
What I’m also wondering is if the memory requirements of large edits can be reduced any in the future versions of WE? It can use “a lot” of ram to do a large edit of the server, it’s not hard to crash my server with a 1 million plus block copy/paste.
Being that SK is working on Sponge, this could lead to a more efficient World Edit plugin since he can modify the server to allow him to do stuff that he cannot of done before. Memory issues isn’t the biggest problem here, its making sure that the plugin will work with all these new Mojang features UID’s ect. Although I pretty sure SK has already overcome this new features of Mojang already.
- TangentSpy
There are some ways it can be reduced. The recent large rewrite made it possible to drop in a different history storage driver, but I haven’t gotten a chance to write a new one yet. The current one dates back to 2010.
1 Like
Until Sponge and a new version of WE comes out, use WE fast mode 
I would like an event triggered when a editing action occurs such as /set to large regions etc it will be useful for multiblocks etc