Several Non-Ticking blocks are marked as ticking forcing the growth-algorithm to check chunks needlessly
The bug
Blocktypes in Minecraft are marked as ticking if they can be activated by the random growth algorithm.
Examples would be crops, grass or fire.
However, several other blocks have no ticking-functionality but are still marked as ticking. An example would be the Cake or the Button-Blocks.
This causes problems with the growth-algorithm and chunk-indexing on chunk-loads. Each time a chunk is loaded it will count all ticking blocks. If the count is == 0 the specific chunk has no tickable blocks and will not need to be randomly checked every tick and try to grow something.
Unfortunately this benefit never really occurs if so many blocks are marked as ticking when in fact they cannot tick.
Maybe some additional information as I have some optimizations running for some time now:
- A large amount of ChunkSections will always need to tick as they contain growable blocks like grass or leaves so the optimizations here are limited
- Currently only the ChunkSections contain a counter that indicates if it needs to be ticked, a Chunk itself could contain this too and reduce the lookups at runtime
Affected blocks
Based on 20w07a code using Mojang names.
For the blocks in question randomTicks() is called on the builder when constructing the constants in net.minecraft.world.level.block.Blocks.
List might be incomplete, last updated for 20w07a
| Block (Mojang name) | Comment |
|---|---|
| SoulFireBlock | Does nothing when ticked |
| RedStoneOreBlock | Could be solved by scheduling a block event with random delay |
| CampfireBlock | Does nothing when ticked |
Created Issue:
Serveral Non-Ticking blocks are marked as ticking forcing the growth-algorithm to check chunks needlessly
Hey,
blocktypes in Minecraft are marked as ticking if they can be activated by the random growth algorithm.
Examples would be crops, grass or fire.Several other blocks have no ticking-functionality but are still marked as ticking. An example would be the Cake or the Button-Blocks.
This causes problems with the growth-algorithm and chunk-indexing on chunk-loads. Each time a chunk is loaded it will count all ticking blocks. If the count is == 0 the specific chunk has no tickable blocks and will not need to be randomly checked every tick and try to grow something.
Unfortunately this benefit never really occurs if so many blocks are marked as ticking when in fact they cannot tick.
relates to
Hey,
blocktypes in Minecraft are marked as ticking if they can be activated by the random growth algorithm.
Examples would be crops, grass or fire.Several other blocks have no ticking-functionality but are still marked as ticking. An example would be the Cake or the Button-Blocks.
This causes problems with the growth-algorithm and chunk-indexing on chunk-loads. Each time a chunk is loaded it will count all ticking blocks. If the count is == 0 the specific chunk has no tickable blocks and will not need to be randomly checked every tick and try to grow something.
Unfortunately this benefit never really occurs if so many blocks are marked as ticking when in fact they cannot tick.
Maybe some additional information as I have some optimizations running for some time now:
- A large amount of ChunkSections will always need to tick as they contain growable blocks like grass so the optimizations here are limited
- Currently only the ChunkSections contain a counter that indicates if it needs to be ticked, a Chunk itself could contain this too and reduce the lookups at runtime
- Redstoneores tick just to de-light them after being touched by a player. Disabling this or changing it to a temporary client-side animation drastically reduces the random lookups in lower parts of the world.
- Sand an Gravel are marked as ticking but don't do anything (it was probably intended to randomly tick them so 'flying' sand would fall down at some point).
- Removing Sand, Gravel,Lava,Water and RedsteoneOre from the tickable-blocks will nearly eliminate any need of ticking lower chunksections
Hey,
blocktypes in Minecraft are marked as ticking if they can be activated by the random growth algorithm.
Examples would be crops, grass or fire.
Several other blocks have no ticking-functionality but are still marked as ticking. An example would be the Cake or the Button-Blocks.This causes problems with the growth-algorithm and chunk-indexing on chunk-loads. Each time a chunk is loaded it will count all ticking blocks. If the count is == 0 the specific chunk has no tickable blocks and will not need to be randomly checked every tick and try to grow something.
Unfortunately this benefit never really occurs if so many blocks are marked as ticking when in fact they cannot tick.
Maybe some additional information as I have some optimizations runningfor some time now:
- A large amount of ChunkSections will always need to tick as they contain growable blocks like grass so the optimizations here are limited
Currently only the ChunkSections contain a counter that indicates if itneedstobeticked, a Chunk itself could contain this too and reduce the lookups at runtimeRedstoneores tick just to de-light them after being touched by a player. Disabling this or changing it to a temporary client-side animation drasticallyreducestherandomlookupsin lower parts of the world.- Sand an Gravel are marked as ticking but don't do anything (it was probably intended to randomly tick them so 'flying' sand would fall down at some point).
- Removing Sand, Gravel,Lava,Water and RedsteoneOre from the tickable-blocks will nearly eliminate any need of ticking lower chunksections
The bug
Blocktypes in Minecraft are marked as ticking if they can be activated by the random growth algorithm.
Examples would be crops, grass or fire.However, several other blocks have no ticking-functionality but are still marked as ticking. An example would be the Cake or the Button-Blocks.
This causes problems with the growth-algorithm and chunk-indexing on chunk-loads. Each time a chunk is loaded it will count all ticking blocks. If the count is == 0 the specific chunk has no tickable blocks and will not need to be randomly checked every tick and try to grow something.
Unfortunately this benefit never really occurs if so many blocks are marked as ticking when in fact they cannot tick.
Maybe some additional information as I have some optimizations running for some time now:
- A large amount of ChunkSections will always need to tick as they contain growable blocks like grass or leaves so the optimizations here are limited
- Currently only the ChunkSections contain a counter that indicates if it needs to be ticked, a Chunk itself could contain this too and reduce the lookups at runtime
Affected blocks
Based on 1.11.2 decompiled using MCP 9.35 rc1
List might be incomplete
Block (MCP name) Comment BlockBasePressurePlate (1) Could maybe be solved by scheduling block updates until no entity is on it anymore BlockFlower (2) Just causes the block to break if it is at an invalid position BlockLilyPad 2 BlockDeadBush 2 BlockDoublePlant 2 BlockTallGrass 2 BlockButton Uses 1 already BlockCake - BlockCarpet - BlockLiquid - BlockMagma Schedule block event when neighboor changed and water is above BlockPumpkin - BlockRailDetector Uses 1 already BlockRedstoneOre Schedule a block event with random delay BlockRedstoneTorch Uses 1 already BlockTorch - BlockTripWire Uses 1 already BlockTripWireHook Uses 1 already
The bug
Blocktypes in Minecraft are marked as ticking if they can be activated by the random growth algorithm.
Examples would be crops, grass or fire.However, several other blocks have no ticking-functionality but are still marked as ticking. An example would be the Cake or the Button-Blocks.
This causes problems with the growth-algorithm and chunk-indexing on chunk-loads. Each time a chunk is loaded it will count all ticking blocks. If the count is == 0 the specific chunk has no tickable blocks and will not need to be randomly checked every tick and try to grow something.
Unfortunately this benefit never really occurs if so many blocks are marked as ticking when in fact they cannot tick.
Maybe some additional information as I have some optimizations running for some time now:
- A large amount of ChunkSections will always need to tick as they contain growable blocks like grass or leaves so the optimizations here are limited
- Currently only the ChunkSections contain a counter that indicates if it needs to be ticked, a Chunk itself could contain this too and reduce the lookups at runtime
Affected blocks
Based on 1.11.2 decompiled using MCP 9.35 rc1
List might be incomplete
Block (MCP name) Comment BlockBasePressurePlate (1) Could maybe be solved by scheduling block updates until no entity is on it anymore BlockFlower (2) Just causes the block to break if it is at an invalid position BlockLilyPad 2 BlockDeadBush 2 BlockDoublePlant 2 BlockTallGrass 2 BlockButton Uses 1 already BlockCake - BlockCarpet - BlockLiquid - BlockMagma Schedule block event when neighboor changed and water is above BlockPumpkin - BlockRailDetector Uses 1 already BlockRedstoneOre Schedule a block event with random delay BlockRedstoneTorch Uses 1 already BlockTorch - BlockTripWire Uses 1 already BlockTripWireHook Uses 1 already The bug
Blocktypes in Minecraft are marked as ticking if they can be activated by the random growth algorithm.
Examples would be crops, grass or fire.However, several other blocks have no ticking-functionality but are still marked as ticking. An example would be the Cake or the Button-Blocks.
This causes problems with the growth-algorithm and chunk-indexing on chunk-loads. Each time a chunk is loaded it will count all ticking blocks. If the count is == 0 the specific chunk has no tickable blocks and will not need to be randomly checked every tick and try to grow something.
Unfortunately this benefit never really occurs if so many blocks are marked as ticking when in fact they cannot tick.
Maybe some additional information as I have some optimizations running for some time now:
- A large amount of ChunkSections will always need to tick as they contain growable blocks like grass or leaves so the optimizations here are limited
- Currently only the ChunkSections contain a counter that indicates if it needs to be ticked, a Chunk itself could contain this too and reduce the lookups at runtime
Affected blocks
Based on 1.11.2 decompiled using MCP 9.35 rc1
List might be incomplete
Block (MCP name) Comment BlockBasePressurePlate (1) Could maybe be solved by scheduling block updates until no entity is on it anymore BlockFlower (2) Just causes the block to break if it is at an invalid position BlockLilyPad 2 BlockDeadBush 2 BlockDoublePlant 2 BlockTallGrass 2 BlockButton Uses 1 already BlockCake - BlockCarpet - BlockLiquid - BlockMagma Schedule block event when neighboor changed and water is above BlockPumpkin - BlockRailDetector Uses 1 already BlockRedstoneOre Schedule a block event with random delay BlockRedstoneTorch Uses 1 already BlockSnowBlock See MC-88097BlockTorch - BlockTripWire Uses 1 already BlockTripWireHook Uses 1 already
Serveral Non-Ticking blocks are marked as ticking forcing the growth-algorithm to check chunks needlessly
Can someone please check, if this still applies to 1.15.2 or the latest 1.16 development snapshot (currently that is 20w07a)?
The bug
Blocktypes in Minecraft are marked as ticking if they can be activated by the random growth algorithm.
Examples would be crops, grass or fire.However, several other blocks have no ticking-functionality but are still marked as ticking. An example would be the Cake or the Button-Blocks.
This causes problems with the growth-algorithm and chunk-indexing on chunk-loads. Each time a chunk is loaded it will count all ticking blocks. If the count is == 0 the specific chunk has no tickable blocks and will not need to be randomly checked every tick and try to grow something.
Unfortunately this benefit never really occurs if so many blocks are marked as ticking when in fact they cannot tick.
Maybe some additional information as I have some optimizations running for some time now:
- A large amount of ChunkSections will always need to tick as they contain growable blocks like grass or leaves so the optimizations here are limited
- Currently only the ChunkSections contain a counter that indicates if it needs to be ticked, a Chunk itself could contain this too and reduce the lookups at runtime
Affected blocks
Based on 1.11.2 decompiled using MCP 9.35 rc1
List might be incomplete
Block (MCP name) Comment BlockBasePressurePlate (1) Could maybe be solved by scheduling block updates until no entity is on it anymore BlockFlower (2) Just causes the block to break if it is at an invalid position BlockLilyPad 2 BlockDeadBush 2 BlockDoublePlant 2 BlockTallGrass 2 BlockButton Uses 1 already BlockCake - BlockCarpet - BlockLiquid - BlockMagma Schedule block event when neighboor changed and water is above BlockPumpkin - BlockRailDetector Uses 1 already BlockRedstoneOre Schedule a block event with random delay BlockRedstoneTorch Uses 1 already BlockSnowBlock See MC-88097Block Torch-BlockTripWireUses 1 alreadyBlockTripWireHookUses1 alreadyThe bug
Blocktypes in Minecraft are marked as ticking if they can be activated by the random growth algorithm.
Examples would be crops, grass or fire.However, several other blocks have no ticking-functionality but are still marked as ticking. An example would be the Cake or the Button-Blocks.
This causes problems with the growth-algorithm and chunk-indexing on chunk-loads. Each time a chunk is loaded it will count all ticking blocks. If the count is == 0 the specific chunk has no tickable blocks and will not need to be randomly checked every tick and try to grow something.
Unfortunately this benefit never really occurs if so many blocks are marked as ticking when in fact they cannot tick.
Maybe some additional information as I have some optimizations running for some time now:
- A large amount of ChunkSections will always need to tick as they contain growable blocks like grass or leaves so the optimizations here are limited
- Currently only the ChunkSections contain a counter that indicates if it needs to be ticked, a Chunk itself could contain this too and reduce the lookups at runtime
Affected blocks
Based on 20w07a code using Mojang names.
For the blocks in question randomTicks() is called on the builder when constructing the constants in net.minecraft.world.level.block.Blocks.List might be incomplete, last updated for 20w07a
Block (Mojang name) Comment SoulFireBlock Does nothing when ticked RedStoneOreBlock Could be solved by scheduling a block event with random delay CampfireBlock Does nothing when ticked
Is this still an issue in the latest snapshot 16w44a? If so please update the affected versions.
This is an automated comment on any open or reopened issue with out-of-date affected versions.
Updated report but removed some optimizations which would remove features of the game.
Affects 20w07a, but I didn't check the whole table, and there may be new blocks with this issue.