Posts: 4,621
Threads: 113
Joined: Dec 2011
Thanks: 51
Given 55 thank(s) in 409 post(s)
Is there a reason why cChunk isn't exported to the Lua API? Using that plugins could change a chunk directly instead of going through a world object first (kinda like cBlockArea, but you wouldn't have to read it from the world first).
There could be a cWorld:DoWithChunk, and the cChunkStay:OnChunkAvailable callback could have a cChunk object as a 3th parameter.
Thoughts?
Posts: 783
Threads: 12
Joined: Jan 2014
Thanks: 0
Given 4 thank(s) in 61 post(s)
I would support the export of DoWithChunk, and the new method DoWithChunkAt (takes block coords, rather than chunk coords). It would enable us to remove or at least depreciate a few functions that are only in cWorld for the lua API.
Posts: 6,486
Threads: 176
Joined: Jan 2012
Thanks: 40
Given 156 thank(s) in 838 post(s)
We don't want plugins to ever get hold of a cChunk instance, who knows what kind of mayhem they would cause. Despite all the warnings there are still plugins storing entity instances between calls, and with chunks it would be much worse.
You don't actually need to read cBlockArea, you can compose it and directly write it.
What's the big issue about using cBlockArea anyway? It works nicely, it even has more operations than cChunk.
Posts: 4,621
Threads: 113
Joined: Dec 2011
Thanks: 51
Given 55 thank(s) in 409 post(s)
05-10-2015, 03:06 AM
(This post was last modified: 05-10-2015, 11:29 PM by NiLSPACE.)
I think we should assume that the plugins are written correctly without them storing a cChunk object.
I just think some plugins could benefit if they could acces a cChunk object and change stuff from there instead of going through the cWorld first.
