WorldEdit

[NiLSPACE]

I just had an idea for a WECUI replacement. In Minecraft 1.9 particles will barely lag your computer. This is because they aren't seen as entities anymore. We could try to use these particles as a replacement for WECUI. Of course once WECUI is updated for 1.9 it is favorable to use that.

---

or we could create a separate plugin that would implement this behavior.

[Zee1234]

Just got through looking at your API file. Is there a simple way I am missing to get coordinate points of a cuboid selection, or would I have to use the ExecuteString function? If the latter, does this look correct?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

local playerName = cPlayer:GetName()   local fnString = [[function(a_Player)   local Sel = cRoot:Get():FindAndDoWithPlayer(a_Player,GetPlayerState).selection -- is this syntax even legit? I feel like it should be am not certain   local ret = {}   assert(Sel:IsValid(),"No cuboid selection found!")   ret.X1, ret.X2 = Sel:GetXCoordsSorted()   ret.Y1, ret.Y2 = Sel:GetYCoordsSorted()   ret.Z1, ret.Z2 = Sel:GetZCoordsSorted()   return ret end]]   -- Or can I pass a cPlayer through and skip the FindAndDoWithPlayer? I read that passing objects is weird and unsupported, so I went the above method.   local sel, msg = cRoot:Get():GetPluginManager():CallPlugin("WorldEdit","ExecuteString",fnString,playerName)

[NiLSPACE]

It's pretty easy:

1 2 3 4 5 6

-- Player is a cPlayer object   local SelectedCuboid = cCuboid() cPluginManager:CallPlugin("WorldEdit", "GetPlayerCuboidSelection", Player, SelectedCuboid)   -- Do stuff with the selected cuboid

---

Also, your previous code would've given an error. You're returning a table to a different plugin. You can only pass numbers, booleans, strings and usertypes (cPlayer, cEntity, cCuboid, etc.). This means NO tables, arrays, lists, etc. You could've returned all the other variables.

1 2 3 4 5

-- In your fnString function return Sel:GetXCoordsSorted(), Sel:GetYCoordsSorted(), Sel:GetZCoordsSorted()   -- Get the variables. local MinX, MaxX, MinY, MaxY, MinZ, MaxZ = cRoot:Get():GetPluginManager():CallPlug...

---

And no, the FindAndDoWithPlayer part wouldn't work. The syntax is still valid, but it would crash because you would try to get the selection member of a bool value.
What would've worked is this:

1 2 3 4 5 6

local Sel; cRoot:Get():FindAndDoWithPlayer(a_Player,    function(a_Player)       Sel = GetPlayerState(a_Player).Selection    end )

[Zee1234]

Thanks much. I even said it wouldn't work sending tables, and then I made a table.. lol oops. And good to know about the FindAndDo. TMYK.

What I don't get is how I missed the cCuboid bit. Thanks!

[patsch]

Fun fact: This plugin can crash your minecraft client if you use a region that is too large.

OK! That's why...! :-)

[NiLSPACE]

I thought Mojang fixed it already though.

[PureTryOut]

I just want to say: I'm impressed. While on Spigot, if I made a block of stone of 1.5m blocks, the server would just stop for ~10 seconds.
Using this plugin, it's done within 2 seconds. Keep going like this! This is awesome!

[Seadragon91]

I just want to say: I'm impressed. While on Spigot, if I made a block of stone of 1.5m blocks, the server would just stop for ~10 seconds.
Using this plugin, it's done within 2 seconds. Keep going like this! This is awesome!

The reason why it's that quick is that the content of a schematic file are copied directly into the chunk(s). The class for this is named cBlockArea.

One problem still exists. No content of any block entities are copied and no block entites are created (example a chest, that you can open it). There is a open issue for that on github

[NiLSPACE]

Spigot only stopped for 10 seconds? When I tried to paste the structure in the AsyncWorldEdit demo (that's 2 million blocks) my spigot server froze for a whole minute and then crashed. Cuberite was only blocked for 3.84 seconds.

[PureTryOut]

I'm guessing you were the one commenting there (NiLSPACE), your name sounds Dutch. Altijd mooi landgenoten te vinden op het internet

Anyways the only issue that I had was that //undo did not fully undo the //set command. A part of the block was set in the water, and that part was not undone, so a layer of stone was left behind.