Solved Setting blocks fast

I have found out how to generate a circle and i am pretty happy about that the only problem is is that when i do .setType(Material.WHATEVER); it will cause a lot of lagg, does someone know how to set blocks fast without lagg?

 

put the blocks in a runnable and then use that to place them 1 by 1. (look at builder for citezins 2)

it dosnt completely reduce lag but it would be reduced rather then all at once

 

For one of my plugins I create farily big structures by placing the blocks all at once in a cuboid region and, yes it causes lag but only for a second or two at most. The biggest region I set at once is 25x42x23. I wouldn't suggest using a runnable to create your circle if you want it done fast as if you were to say place a block a tick then that could still cause a lot of lag and it would greatly extend the amount of time that the lag would be happening on. If you were to set blocks less often then that would keep reducing lag but it would end up taking a much longer time to build the circle. If you don't really care about speed then go for it though. Some of the lag is probably being caused by your circle equation, if your circle is a specific size then you could hardcode the positions of the blocks in a cuboid reason so that you don't have to cycle through each block checking it's location against your circle equation.

 

I would talk to desht . Although I am still not quite sure of his method because I was missing some of his code and could not implement it, I would say he has the most effiicient method of placing a lot of blocks quickly without a lot of lag.

 

I am not sure I completely understand this, but why not try a Thread.sleep(1000);
1000 = 1 seconds.

 

Trevor1134 As long as it's not on the main thread. Another note is that it would take long as hell(depending on the selection) for it to set every block with 1 second apart.

 

Could you show us your code? Jogy34 has a good point about your circle calculations, which usually contain roots in mathematics but are very expensive regarding computing power.

Personally, I would try to place X blocks per tick with a scheduled repeating syncronous task. X has to be the highest number that is possible to not cause recognizeable lag. Because it is syncronous players can still do whatever they want because the program returns to the main thread every tick.

 

You could take a look at the WorldEdit source code, they use some NMS calls to set the blocks without recalculating the light levels, making it much faster.

 

If you want to do this with Bukkit, then AmShaegar 's method is the recommended way; break the task up over several ticks.

Using NMS code, you could take a look at how I do it here: https://github.com/desht/dhutils/bl...desht/dhutils/block/CraftMassBlockUpdate.java - note that I use an NMS abstraction layer for version independence; e.g. for CB 1.6.1, the implementation is in https://github.com/desht/dhutils/bl.../me/desht/dhutils/nms/v1_6_R1/NMSHandler.java.

Basically, I'm using the NMS chunk.a(int, int, int, int, byte) method to insert id/data directly into the chunk. That's very very fast (~1,000,000 blocks per sec), but no relighting or client updates will be done. Once all of the chunks have been updated directly, the notifyClients() method calls world.refreshChunk() (Bukkit method) on all affected chunks, which sends client updates out.

My CraftMassBlockUpdate class offers three lighting modes: IMMEDIATE: relight blocks as soon as they're updated, NEVER: do no relighting at all, and DEFERRED: carry out relighting over multiple ticks, with a configurable max time per tick to spend relighting.

This being Minecraft, lighting is the trickiest part. If you do no relighting at all, things will look fine in the daytime, but placing e.g. glowstone at night time will appear dark from a distance. However, if you get close enough, the client takes over and does some lighting for you. Since relighting is easily the slowest part of this whole operation, that may be a tempting option. Danger is, that behaviour is highly implementation-defined, so results will be unpredictable (we have zero control over the client). Immediate relighting is OK if the update isn't too huge, but will risk some lag, and deferred lighting is useful for really huge updates (tens or hundreds of thousands of blocks, or even millions).

Anyhow, the code is all LGPL'd, and completely free for anyone to copy from or use directly. It is somewhat complex due to the NMS abstraction stuff, though - you can't just copy CraftMassBlockUpdate in isolation.

It's not an option at all, since you shouldn't be making any block updates from a thread other than the main thread, and you must absolutely never call Thread.sleep() from the main thread.

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

desht Who said it was ever an option to call Thread.sleep() on the main thread?

 

Trevor1134 did - http://forums.bukkit.org/threads/setting-blocks-fast.157772/#post-1738885

 

desht You should've replied to him, so he would've gotten the message of it not being an option, not me(I know he will get it now since you tagged him).

 

desht GodzOfMadness oh oh oh :\ I forgot to mention you couldn't... Sh*t, my bad mate.

GodzOfMadness told me you can't sleep in main thread, so I should of remembered. My bad desht.

 

Your reply implied that another thread could be used (quote: "as long as it's not on the main thread"), which is not the case. You can't safely make block updates from a different thread. That's why I replied to you.

 

desht Who said I didn't know it was completely 'safe'? I like it rough sometimes, 'ya know?
Jokes aside, in some cases, it's okay to use Thread.sleep() in a thread. They can be useful with countdown timer for example.

 

NoLiver92 Jogy34 Tooner101 Trevor1134 GodzOfMadness desht Thank you all for your suggestions, i found out how to do it