Uploaded image for project: 'Minecraft: Java Edition'
  1. Minecraft: Java Edition
  2. MC-123860

World generation at chunk borders causes new chunks to be loaded



    • Confirmation Status:
      Community Consensus
    • Category:


      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.




            • Assignee:
              quadraxis Ben Staddon
            • Votes:
              2 Vote for this issue
              2 Start watching this issue


              • Created: