MC-123860World generation at chunk borders causes new chunks to be loaded
This is somewhat of a technical issue, but I feel it should be raised here.
Minecraft is coded to avoid loading extra chunks during world generation. This is because any chunks loaded here will also have world generation run, and this can "cascade" over a large area before stopping. In extreme cases, as can potentially be seen by using the "customised" world gen option with changed parameters, this can cause the game to crash, normally due to a stack overflow.
This reddit post is a good example of the problems that can be caused by cascading world generation.
The issue here was introduced with the observer blocks added to version 1.11.
Observers can be notified of block changes independently of normal block updates.
This is because a new flag was added to World.setBlockState, with a value of 16. If this flag is set, observers will not be notified of changes to blockstates, otherwise they will.
This is different from the usual updates applied to neighbouring blocks, which is controlled by flag 1, occurring only if that flag is set.
The problem arises from the fact that the new flag was implemented as an 'opt-out' - it needs to be set to prevent something from occurring. This means that all existing calls to World.setBlockState in the code notify observers by default.
However, some of these existing calls are coded to explicitly not notify neighbouring blocks, such as those during worldgen. These typically pass a value of 2 as the flags used.
Due to this, previously 'safe' world generation that touches a chunk boundary now spills over to adjacent chunks due to the new check for observer blocks. An example of this is giant jungle trees (see this Forge PR).
Either existing calls to World.setBlockState using non-default values (especially without the flag 1) should be reviewed to see if adding flag 16 is needed, or the behaviour defined by flag 16 should be changed to keep existing pre-observer code correct. This can be achieved by making it a 'modifier' to the value of flag 1, which specifies that observers should have different behaviour to the default "inferred" behaviour.
Created Issue:
World generation at chunk borders causes new chunks to be loaded
This is somewhat of a technical issue, but I feel it should be raised here.
Minecraft is coded to avoid loading extra chunks during world generation. This is because any chunks loaded here will also have world generation run, and this can "cascade" over a large area before stopping. In extreme cases, as can potentially be seen by using the "customised" world gen option with changed parameters, this can cause the game to crash, normally due to a stack overflow.
This reddit post is a good example of the problems that can be caused by cascading world generation.
The issue here was introduced with the observer blocks added to version 1.11.
Observers can be notified of block changes independently of normal block updates.
This is because a new flag was added to World.setBlockState, with a value of 16. If this flag is set, observers will not be notified of changes to blockstates, otherwise they will.
This is different from the usual updates applied to neighbouring blocks, which is controlled by flag 1, occurring only if that flag is set.The problem arises from the fact that the new flag was implemented as an 'opt-out' - it needs to be set to prevent something from occurring. This means that all existing calls to World.setBlockState in the code notify observers by default.
However, some of these existing calls are coded to explicitly not notify neighbouring blocks, such as those during worldgen. These typically pass a value of 2 as the flags used.
Due to this, previously 'safe' world generation that touches a chunk boundary now spills over to adjacent chunks due to the new check for observer blocks. An example of this is giant jungle trees (see this Forge PR).
Either existing calls to World.setBlockState using non-default values (especially without the flag 1) should be reviewed to see if adding flag 16 is needed, or the behaviour defined by flag 16 should be changed to keep existing pre-observer code correct. This can be achieved by making it a 'modifier' to the value of flag 1, which specifes that observers should have different behaviour to the default "inferred" behaviour.
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
This is somewhat of a technical issue, but I feel it should be raised here.
Minecraft is coded to avoid loading extra chunks during world generation. This is because any chunks loaded here will also have world generation run, and this can "cascade" over a large area before stopping. In extreme cases, as can potentially be seen by using the "customised" world gen option with changed parameters, this can cause the game to crash, normally due to a stack overflow.
This reddit post is a good example of the problems that can be caused by cascading world generation.
The issue here was introduced with the observer blocks added to version 1.11.
Observers can be notified of block changes independently of normal block updates.
This is because a new flag was added to World.setBlockState, with a value of 16. If this flag is set, observers will not be notified of changes to blockstates, otherwise they will.
This is different from the usual updates applied to neighbouring blocks, which is controlled by flag 1, occurring only if that flag is set.The problem arises from the fact that the new flag was implemented as an 'opt-out' - it needs to be set to prevent something from occurring. This means that all existing calls to World.setBlockState in the code notify observers by default.
However, some of these existing calls are coded to explicitly not notify neighbouring blocks, such as those during worldgen. These typically pass a value of 2 as the flags used.
Due to this, previously 'safe' world generation that touches a chunk boundary now spills over to adjacent chunks due to the new check for observer blocks. An example of this is giant jungle trees (see this Forge PR).
Either existing calls to World.setBlockState using non-default values (especially without the flag 1) should be reviewed to see if adding flag 16 is needed, or the behaviour defined by flag 16 should be changed to keep existing pre-observer code correct. This can be achieved by making it a 'modifier' to the value of flag 1, which specifies that observers should have different behaviour to the default "inferred" behaviour.
This is somewhat of a technical issue, but I feel it should be raised here.
Minecraft is coded to avoid loading extra chunks during world generation. This is because any chunks loaded here will also have world generation run, and this can "cascade" over a large area before stopping. In extreme cases, as can potentially be seen by using the "customised" world gen option with changed parameters, this can cause the game to crash, normally due to a stack overflow.
This reddit post is a good example of the problems that can be caused by cascading world generation.
The issue here was introduced with the observer blocks added to version 1.11.
Observers can be notified of block changes independently of normal block updates.
This is because a new flag was added to World.setBlockState, with a value of 16. If this flag is set, observers will not be notified of changes to blockstates, otherwise they will.
This is different from the usual updates applied to neighbouring blocks, which is controlled by flag 1, occurring only if that flag is set.The problem arises from the fact that the new flag was implemented as an 'opt-out' - it needs to be set to prevent something from occurring. This means that all existing calls to World.setBlockState in the code notify observers by default.
However, some of these existing calls are coded to explicitly not notify neighbouring blocks, such as those during worldgen. These typically pass a value of 2 as the flags used.
Due to this, previously 'safe' world generation that touches a chunk boundary now spills over to adjacent chunks due to the new check for observer blocks. An example of this is giant jungle trees (see this
Forge PR).Either existing calls to World.setBlockState using non-default values (especially without the flag 1) should be reviewed to see if adding flag 16 is needed, or the behaviour defined by flag 16 should be changed to keep existing pre-observer code correct. This can be achieved by making it a 'modifier' to the value of flag 1, which specifies that observers should have different behaviour to the default "inferred" behaviour.
This is somewhat of a technical issue, but I feel it should be raised here.
Minecraft is coded to avoid loading extra chunks during world generation. This is because any chunks loaded here will also have world generation run, and this can "cascade" over a large area before stopping. In extreme cases, as can potentially be seen by using the "customised" world gen option with changed parameters, this can cause the game to crash, normally due to a stack overflow.
This reddit post is a good example of the problems that can be caused by cascading world generation.
The issue here was introduced with the observer blocks added to version 1.11.
Observers can be notified of block changes independently of normal block updates.
This is because a new flag was added to World.setBlockState, with a value of 16. If this flag is set, observers will not be notified of changes to blockstates, otherwise they will.
This is different from the usual updates applied to neighbouring blocks, which is controlled by flag 1, occurring only if that flag is set.The problem arises from the fact that the new flag was implemented as an 'opt-out' - it needs to be set to prevent something from occurring. This means that all existing calls to World.setBlockState in the code notify observers by default.
However, some of these existing calls are coded to explicitly not notify neighbouring blocks, such as those during worldgen. These typically pass a value of 2 as the flags used.
Due to this, previously 'safe' world generation that touches a chunk boundary now spills over to adjacent chunks due to the new check for observer blocks. An example of this is giant jungle trees (see this Forge PR.
Either existing calls to World.setBlockState using non-default values (especially without the flag 1) should be reviewed to see if adding flag 16 is needed, or the behaviour defined by flag 16 should be changed to keep existing pre-observer code correct. This can be achieved by making it a 'modifier' to the value of flag 1, which specifies that observers should have different behaviour to the default "inferred" behaviour.
This is somewhat of a technical issue, but I feel it should be raised here.
Minecraft is coded to avoid loading extra chunks during world generation. This is because any chunks loaded here will also have world generation run, and this can "cascade" over a large area before stopping. In extreme cases, as can potentially be seen by using the "customised" world gen option with changed parameters, this can cause the game to crash, normally due to a stack overflow.
This reddit post is a good example of the problems that can be caused by cascading world generation.
The issue here was introduced with the observer blocks added to version 1.11.
Observers can be notified of block changes independently of normal block updates.
This is because a new flag was added to World.setBlockState, with a value of 16. If this flag is set, observers will not be notified of changes to blockstates, otherwise they will.
This is different from the usual updates applied to neighbouring blocks, which is controlled by flag 1, occurring only if that flag is set.The problem arises from the fact that the new flag was implemented as an 'opt-out' - it needs to be set to prevent something from occurring. This means that all existing calls to World.setBlockState in the code notify observers by default.
However, some of these existing calls are coded to explicitly not notify neighbouring blocks, such as those during worldgen. These typically pass a value of 2 as the flags used.
Due to this, previously 'safe' world generation that touches a chunk boundary now spills over to adjacent chunks due to the new check for observer blocks. An example of this is giant jungle trees (see this Forge PR).
Either existing calls to World.setBlockState using non-default values (especially without the flag 1) should be reviewed to see if adding flag 16 is needed, or the behaviour defined by flag 16 should be changed to keep existing pre-observer code correct. This can be achieved by making it a 'modifier' to the value of flag 1, which specifies that observers should have different behaviour to the default "inferred" behaviour.
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
Please check if this still applies to 1.15.2.
![[Mod] LateLag](../../../data/avatars/users/92884.png){kind=small}
Can someone please check, if this still applies to 1.15.2 or the latest 1.16 development snapshot (currently that is 20w07a)?