Hoppers don't fill Composters like in vanilla
Klemms opened this issue ยท 8 comments
Version Information
canary-mc1.19.2-0.1.3.jar
Running in forge 1.19.2 43.1.52
Expected Behavior
Like in Vanilla, you can fill composters using hoppers
Actual Behavior
Hoppers don't fill composters (was using poppies to test this)
Reproduction Steps
Try to fill a Poppy to a composter using a hopper
Making this config change emptied all vanilla/quark chests in my world. Using ATM8 modpack, v1.0.2. Here's a relevant-seeming entry from the logs:
[25Nov2022 19:06:28.200] [Server thread/ERROR] [net.minecraft.world.level.block.entity.BlockEntity/]: Failed to load data for block entity minecraft:chest java.lang.ClassCastException: class net.minecraft.world.level.block.entity.ChestBlockEntity cannot be cast to class com.abdelaziz.canary.api.inventory.CanaryInventory (net.minecraft.world.level.block.entity.ChestBlockEntity is in module [email protected] of loader 'TRANSFORMER' @4fbb1144; com.abdelaziz.canary.api.inventory.CanaryInventory is in module [email protected] of loader 'TRANSFORMER' @4fbb1144) at net.minecraft.world.level.block.entity.BaseContainerBlockEntity.invalidateChangeListening(BaseContainerBlockEntity.java:1062) ~[server-1.19.2-20220805.130853-srg.jar%23384!/:?] at net.minecraft.world.level.block.entity.BaseContainerBlockEntity.emitStackListReplaced(BaseContainerBlockEntity.java:1041) ~[server-1.19.2-20220805.130853-srg.jar%23384!/:?] at net.minecraft.world.level.block.entity.BaseContainerBlockEntity.handler$bbk000$readNbtStackListReplacement(BaseContainerBlockEntity.java:1530) ~[server-1.19.2-20220805.130853-srg.jar%23384!/:?] at net.minecraft.world.level.block.entity.BaseContainerBlockEntity.m_142466_(BaseContainerBlockEntity.java:33) ~[server-1.19.2-20220805.130853-srg.jar%23384!/:?] at net.minecraft.world.level.block.entity.ChestBlockEntity.m_142466_(ChestBlockEntity.java:70) ~[server-1.19.2-20220805.130853-srg.jar%23384!/:?] at net.minecraft.world.level.block.entity.BlockEntity.m_155246_(BlockEntity.java:122) ~[server-1.19.2-20220805.130853-srg.jar%23384!/:?] at java.util.Optional.map(Unknown Source) ~[?:?] at net.minecraft.world.level.block.entity.BlockEntity.m_155241_(BlockEntity.java:120) ~[server-1.19.2-20220805.130853-srg.jar%23384!/:?] at net.minecraft.world.level.chunk.storage.ChunkSerializer.m_196900_(ChunkSerializer.java:422) ~[server-1.19.2-20220805.130853-srg.jar%23384!/:?] at net.minecraft.world.level.chunk.LevelChunk.m_62952_(LevelChunk.java:429) ~[server-1.19.2-20220805.130853-srg.jar%23384!/:?] at net.minecraft.server.level.ChunkMap.m_214854_(ChunkMap.java:691) ~[server-1.19.2-20220805.130853-srg.jar%23384!/:?] at com.mojang.datafixers.util.Either.lambda$mapLeft$0(Either.java:162) ~[datafixerupper-5.0.28.jar%2375!/:?] at com.mojang.datafixers.util.Either$Left.map(Either.java:38) ~[datafixerupper-5.0.28.jar%2375!/:?] at com.mojang.datafixers.util.Either.mapLeft(Either.java:162) ~[datafixerupper-5.0.28.jar%2375!/:?] at net.minecraft.server.level.ChunkMap.m_214851_(ChunkMap.java:675) ~[server-1.19.2-20220805.130853-srg.jar%23384!/:?] at java.util.concurrent.CompletableFuture$UniApply.tryFire(Unknown Source) ~[?:?] at java.util.concurrent.CompletableFuture$Completion.run(Unknown Source) ~[?:?] at net.minecraft.server.level.ChunkTaskPriorityQueueSorter.m_143188_(ChunkTaskPriorityQueueSorter.java:62) ~[server-1.19.2-20220805.130853-srg.jar%23384!/:?] at net.minecraft.util.thread.BlockableEventLoop.m_6367_(BlockableEventLoop.java:157) ~[server-1.19.2-20220805.130853-srg.jar%23384!/:?] at net.minecraft.server.level.ServerChunkCache$MainThreadExecutor.m_6367_(ServerChunkCache.java:535) ~[server-1.19.2-20220805.130853-srg.jar%23384!/:?] at net.minecraft.util.thread.BlockableEventLoop.m_7245_(BlockableEventLoop.java:131) ~[server-1.19.2-20220805.130853-srg.jar%23384!/:?] at net.minecraft.server.level.ServerChunkCache$MainThreadExecutor.m_7245_(ServerChunkCache.java:543) ~[server-1.19.2-20220805.130853-srg.jar%23384!/:?] at net.minecraft.server.level.ServerChunkCache.m_8466_(ServerChunkCache.java:267) ~[server-1.19.2-20220805.130853-srg.jar%23384!/:?] at net.minecraft.server.MinecraftServer.m_129961_(MinecraftServer.java:751) ~[server-1.19.2-20220805.130853-srg.jar%23384!/:?] at net.minecraft.server.MinecraftServer.m_7245_(MinecraftServer.java:740) ~[server-1.19.2-20220805.130853-srg.jar%23384!/:?] at net.minecraft.util.thread.BlockableEventLoop.m_18699_(BlockableEventLoop.java:116) ~[server-1.19.2-20220805.130853-srg.jar%23384!/:?] at net.minecraft.server.MinecraftServer.m_130012_(MinecraftServer.java:725) ~[server-1.19.2-20220805.130853-srg.jar%23384!/:?] at net.minecraft.server.MinecraftServer.m_130011_(MinecraftServer.java:658) ~[server-1.19.2-20220805.130853-srg.jar%23384!/:?] at net.minecraft.server.MinecraftServer.m_206580_(MinecraftServer.java:244) ~[server-1.19.2-20220805.130853-srg.jar%23384!/:?] at java.lang.Thread.run(Unknown Source) [?:?]
debug-2.log.gz
which Canary version is in ATM8 modpack? if it old try to update it to 0.1.3.
Duplicate of #60 please make sure the report is not duplicate, This is not issue at all, this is a regular feature from canary for more information press here. you can disable this feature by adding mixin.block.hopper=false in canary.properties.
If it breaks an intended vanilla mechanic, then yes, it is an issue.
Please mention in the changelog when it is fixed so we know which version has the patch. Thank-you
I'd like to quote the ReadMe:
What makes Canary different?
One of the most important design goals in Canary is correctness. Unlike other mods which apply optimizations to the game, Canary does not sacrifice vanilla functionality or behavior in the name of raw speed. It's a no compromises solution for those wanting to speed up their game, and as such, installing Canary should be completely transparent to the player.
This is a clear example of sacrificing vanilla functionality, and is completely opaque to the player. Please consider addressing this issue, as this change is inconsistent with your stated goals for the project.