Expose a method to support setting/placing BlockState to a specific Location #10590
Replies: 1 comment
-
I was able to figure out a way of going around it. It forces using reflection. I'll provide details: In a nutshell, it requires exposing in the method both CraftBlockState's "position" and "world" fields. Here's in Java, excuse if it's messy 🦦
|
Beta Was this translation helpful? Give feedback.
-
Is your feature request related to a problem?
There are some cases in which BlockState is provided but it's not "fine". Fine in terms of being able to invoke BlockState#update.
One of such cases are https://jd.papermc.io/paper/1.20/org/bukkit/structure/Structure.html
Structures have a Palette, a BlockState collection with each BlockState having its Location as an offset from an origin.
There's an issue with Structure#place. This is done in a single tick and this affects performance (main thread) as bigger it gets the Structure.
A solution for this would be splitting through multiple ticks, then we are found at the issue that TileState entities cannot copy their data (since with current API we can only set/change Material and BlockData)
It would also allow not having to depend on WorldEdit or schematics since it would rely on the API
Describe the solution you'd like.
It seems to be possible to solve the issue through NMS. I attempted doing it later this afternoon but I still got no results. My approach was adding a fourth BlockState#update method which allows passing a Location parameter, being this location the desired location in which the operation would be done instead of BlockState#getLocation
Another approach might be exposing a method either in RegionAccessor or World API interfaces
Describe alternatives you've considered.
Not relying on TileEntities...
Other
No response
Beta Was this translation helpful? Give feedback.
All reactions