Posts: 4,629
Threads: 115
Joined: Dec 2011
Thanks: 693
Given 494 thank(s) in 423 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: 2
Given 73 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,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1075 thank(s) in 852 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,629
Threads: 115
Joined: Dec 2011
Thanks: 693
Given 494 thank(s) in 423 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.
