You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is not a huge performance issue in CubicChunks thanks to changes made by xcube16, but it's still the wrong thing to do. Without these changes, your mod would immediateely crash with StackOverflowError. You are setting blocks at the x=0/z=0 border of the give chunk, which when given "do block updates" flag also notifies neighbors... which causes neighbor chunks to be generated. In vanilla this could cause infinite chain of chunk generation and population that would almost instantly crash. With cubic chunks it "only" causes generating more chunks. In the near future I'm going to add warnings when this happens.
Also it would break if I ever go back to the vanilla way (which isn't that unlikely).
So basically what you are doing:
# - the area you are populating.
The middle chunk is the one you got as CubePos.
+--------+--------+--------+
| | | |
| | | |
+--------+--------+--------+
| |########| |
| |########| |
+--------+--------+--------+
| | | |
| | | |
+--------+--------+--------+
And what you should do (this is also now explained in javadoc):
# - the area you are populating.
The middle chunk is the one you got as CubePos.
+--------+--------+--------+
| | | |
| | ####|#### |
+--------+--------+--------+
| | ####|#### |
| | | |
+--------+--------+--------+
| | | |
| | | |
+--------+--------+--------+
The reason for this is that the vast majoroty of populators need to set blocks outside of the directly populated area, like trees for example. If the middle chunk was to be populated directly, populating this one chunk could affect - in vanilla - 8 neighbor chunks, and - in cubic chunks - 26 neighbor cubes. This means that to make sure that all the chunks that affect the currently populated cube are populated, we would need to populate 27 cubes which would need actually generating a whole 125 of them.
Now we need to populate only 8 of them and actually generate 27.
The text was updated successfully, but these errors were encountered:
it should but then you are doing it at your own risk. It will also potentially confuse other populators a bit, and you may break for example some earlier generated plant in half and it won't destroy the other half. It won't properly update liquids. It won't make sand and gravel fall. Abd potentially a lot of other hard to predict things.
Generally it's easier to just add that offset and not care about all the potential issues.
This is not a huge performance issue in CubicChunks thanks to changes made by xcube16, but it's still the wrong thing to do. Without these changes, your mod would immediateely crash with
StackOverflowError
. You are setting blocks at the x=0/z=0 border of the give chunk, which when given "do block updates" flag also notifies neighbors... which causes neighbor chunks to be generated. In vanilla this could cause infinite chain of chunk generation and population that would almost instantly crash. With cubic chunks it "only" causes generating more chunks. In the near future I'm going to add warnings when this happens.Also it would break if I ever go back to the vanilla way (which isn't that unlikely).
So basically what you are doing:
And what you should do (this is also now explained in javadoc):
The reason for this is that the vast majoroty of populators need to set blocks outside of the directly populated area, like trees for example. If the middle chunk was to be populated directly, populating this one chunk could affect - in vanilla - 8 neighbor chunks, and - in cubic chunks - 26 neighbor cubes. This means that to make sure that all the chunks that affect the currently populated cube are populated, we would need to populate 27 cubes which would need actually generating a whole 125 of them.
Now we need to populate only 8 of them and actually generate 27.
The text was updated successfully, but these errors were encountered: