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
When registering a pair of custom oxidizable blocks created from a Vanilla Block implementation (such as WeatheringCopperFullBlock (mojmap)). These blocks override the isRandomlyTicking method, and check the field WeatheringCopper.NEXT_BY_BLOCK to see if they can oxidize further. This field is updated by OxidizableBlocksRegistry.registerOxidizableBlockPair, so it would work if it wasn't for BlockState caching the return value of isRandomlyTicking at the moment the Block is created. Hence, upon the time of caching this value, the block pair isn't registered yet and the block will not be randomly ticked.
// WeatheringCopperFullBlock.java (mojmap!)@OverrideprotectedbooleanisRandomlyTicking(BlockStatestate) {
// Here it accesses the WeatheringCopper.NEXT_BY_BLOCK registry, updated by OxidizableBlocksRegistry// This is called and cached before we get the chance to call OxidizableBlocksRegistry!returnWeatheringCopper.getNext(state.getBlock()).isPresent();
}
It's not actually possible to override this by setting Block.Properties.randomTicks(), since the Block implementations completely override that. The only workaround is to extend the vanilla block logic and override isRandomlyTicking to check for the weathering state instead of looking in the registry.
The cause lays somewhere with the Fabric Registry Sync API initializing the block states early. The problem could potentially be fixed if OxidizableBlocksRegistry.registerOxidizableBlockPair re-caches the isRandomlyTicking for all the block states of the registered blocks. The only reason it does work for Vanilla blocks is because the Vanilla blocks are hardcoded into the registry in the WeatheringCopper interface.
The text was updated successfully, but these errors were encountered:
When registering a pair of custom oxidizable blocks created from a Vanilla
Block
implementation (such asWeatheringCopperFullBlock
(mojmap)). These blocks override theisRandomlyTicking
method, and check the fieldWeatheringCopper.NEXT_BY_BLOCK
to see if they can oxidize further. This field is updated byOxidizableBlocksRegistry.registerOxidizableBlockPair
, so it would work if it wasn't forBlockState
caching the return value ofisRandomlyTicking
at the moment theBlock
is created. Hence, upon the time of caching this value, the block pair isn't registered yet and the block will not be randomly ticked.It's not actually possible to override this by setting
Block.Properties.randomTicks()
, since theBlock
implementations completely override that. The only workaround is to extend the vanilla block logic and overrideisRandomlyTicking
to check for the weathering state instead of looking in the registry.The cause lays somewhere with the Fabric Registry Sync API initializing the block states early. The problem could potentially be fixed if
OxidizableBlocksRegistry.registerOxidizableBlockPair
re-caches theisRandomlyTicking
for all the block states of the registered blocks. The only reason it does work for Vanilla blocks is because the Vanilla blocks are hardcoded into the registry in theWeatheringCopper
interface.The text was updated successfully, but these errors were encountered: